Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Eliezer Croitoru]

Hey Alex,

By saying that I didn't found it only means that *I* couldn't find it with
my rusted email search and found for something.
It doesn't state at all that it was not documented or someone didn't
presented enough details.
A search and lookup can end up more then once in a state of lost mind.
This is one of the reasons I do not like google and couple other search
backends.
For some minds "The search ends in google" literally means that if it was
not found there then there is no other way to find something.
For me the next step would be to ask somebody else with fresh mind and grasp
on the concept\idea\subject but in many cases I am starting with my
surroundings rather then emailing someone.
In this specific case I cannot ask anyone near me since not many even knows
HTTP not to talk about Squid.

So I can only say:
Thanks for bearing with me :D


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
Sent: Monday, July 18, 2016 9:07 PM
To: squid-dev@lists.squid-cache.org
Cc: Eliezer Croitoru
Subject: Re: [RFC] "Splicing" bumped requests to resolve\workaround
WebSockets issues.

On 07/17/2016 02:34 PM, Eliezer Croitoru wrote:
> I remember something's vaguely and this is why I didn't quote anything.
> I tried searching for something in the squid-dev list or irc but I 
> couldn't found it.

For the future, I hope you will document your vague memories without saying
that somebody else did not present enough details.


On 07/18/2016 12:13 AM, Amos Jeffries wrote:
> that would be nice to have. But is not one of the things holding
> Squid-4 in beta.

Agreed on both counts.

Alex.


___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Alex Rousskov]

On 07/17/2016 02:34 PM, Eliezer Croitoru wrote:
> I remember something's vaguely and this is why I didn't quote anything.
> I tried searching for something in the squid-dev list or irc but I couldn't
> found it.

For the future, I hope you will document your vague memories without
saying that somebody else did not present enough details.


On 07/18/2016 12:13 AM, Amos Jeffries wrote:
> that would be nice to have. But is not one of the things holding
> Squid-4 in beta.

Agreed on both counts.

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Eliezer Croitoru]

Alex thanks for clearing things out.
I remember something's vaguely and this is why I didn't quote anything.
I tried searching for something in the squid-dev list or irc but I couldn't
found it.

"tunnel after bump" is indeed the right term and despite to what some think
in many cases the issue is not certificate pinning but...
A specially crafted binary protocol that cannot be intercepted by an HTTP
proxy.

About the on_unsupported_protocol , I am assuming it's part of the:
http://wiki.squid-cache.org/Squid-4?highlight=%28on_unsupported_protocol%29

The test cases I can think about are couple:
- CONNECT of a pinned certificate based connection(MS, SKYPE)
- CONNECT of a non TLS based connection(SKYPE)
- CONNECT of a http websocket connection(WHATSAPP?)
- CONNECT of a HTTPS based connection, non websocket(a simple banking site)
- CONNECT of a HTTPS based websocket connection(the CentOS\Fedora cockpit
have these, other suggections are welcome)
- intercepted connection for each of the cases above

I think that when we could test each and every one of these
cases(successfully) then we can move forward from beta to the next release.
(only for the bump, splice, tunnel, on_unsupported_protocol aspect of squid)

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
Sent: Sunday, July 17, 2016 10:39 PM
To: Eliezer Croitoru; squid-dev@lists.squid-cache.org
Subject: Re: [RFC] "Splicing" bumped requests to resolve\workaround
WebSockets issues.

On 07/15/2016 04:29 AM, Eliezer Croitoru wrote:
> The issue:
> 
> Clients are issuing secured connections which contains WebSockets
> internally and squid HTTP parsing breaks these connections.

> Another related issue which deserves attention:
> 
> Certificate pinning and connection breakage.
> 
> Currently we cannot determine for many connections what is the "issue",
> is it the bumping itself of the breakage of a WebSocket http connection.



> An acceptable solution:
> 
> Alex mentioned the option to splice a bumped connection.  
> 
> I do not know exactly what Alex meant since not much details were
presented.

I do not know exactly what Alex meant either since you provided no
source for that alleged Alex' opinion.


> As I understand, it would not be possible  to do this kind of splice
> without bumping first.

I recommend avoiding "splice after bump" terminology because, in SslBump
context implied by the word "bump", that combination makes no sense: It
is not possible to splice bumped connections.

I suggest using "tunnel after bump" instead. Please note that "tunnel"
(not "splice") is one of the on_unsupported_protocol actions.


HTH,

Alex.


___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Alex Rousskov]

On 07/15/2016 04:29 AM, Eliezer Croitoru wrote:
> The issue:
> 
> Clients are issuing secured connections which contains WebSockets
> internally and squid HTTP parsing breaks these connections.

> Another related issue which deserves attention:
> 
> Certificate pinning and connection breakage.
> 
> Currently we cannot determine for many connections what is the "issue",
> is it the bumping itself of the breakage of a WebSocket http connection.



> An acceptable solution:
> 
> Alex mentioned the option to splice a bumped connection.  
> 
> I do not know exactly what Alex meant since not much details were presented.

I do not know exactly what Alex meant either since you provided no
source for that alleged Alex' opinion.


> As I understand, it would not be possible  to do this kind of splice
> without bumping first.

I recommend avoiding "splice after bump" terminology because, in SslBump
context implied by the word "bump", that combination makes no sense: It
is not possible to splice bumped connections.

I suggest using "tunnel after bump" instead. Please note that "tunnel"
(not "splice") is one of the on_unsupported_protocol actions.


HTH,

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Eliezer Croitoru]

I want to understand the way a WebSocket Splice would work.

The issue:

Clients are issuing secured connections which contains WebSockets internally
and squid HTTP parsing breaks these connections.

>From a security aspect of things, many companies would not like the idea of
the options to "smuggle" data using http through a proxy.

 

Another related issue which deserves attention:

Certificate pinning and connection breakage.

Currently we cannot determine for many connections what is the "issue", is
it the bumping itself of the breakage of a WebSocket http connection.

 

An acceptable solution:

Alex mentioned the option to splice a bumped connection.

 

I do not know exactly what Alex meant since not much details were presented.

How complex would it be to add an option to "splice"(maybe already done) a
bumped http connection?
For WebSockets to be supported we just need to dump the request headers into
the wire and "splice" everything back.

I was thinking about maybe adding if not there already a "Connection: close"
to try and verify that in some level the connection would be closed properly
by a civil server.

It's not "Secure" for many places but I think it could be pretty straight
forward to workaround this administrative issue.

I assume that the same solution can be applied to both regular
sockets\connections and secured.

 

As I understand, it would not be possible  to do this kind of splice without
bumping first.

 

Another related subject is CONNECT based TCP connections smuggling.

The scenario is that a client tries to issue a TCP connection using a
CONNECT method while these can be a wrapped HTTP ones.

 

I only would like to get feedback to make sure that my understanding of the
complexity of the subject is in the right direction.

 

Thanks,

Eliezer

 



Eliezer Croitoru  
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev