[squid-users] Behavior of Squid with SSL Bump and server persistent connections

[Alex Rousskov]

On 07/03/2018 12:02 PM, Vishali Somaskanthan wrote:

> Consider C1 and S1 connections were created for a HTTPs connection
> using ssl-bump. C1 has been served and closed from the client side.

Please note that C1/S1 could serve many requests before C1 got closed.
However, let's focus on the cross-client reuse you are asking about.

There are two different cases to consider:

* ssl_bump stare step2:  In my previous email, I was talking about the
(more typical) case of staring at the client and server before bumping
the connection. In that case, Squid can keep S1 open after closing C1
only if Squid can re-mimic S1 TLS properties when C2 comes. If Squid
cannot, Squid should close S1 as non-reusable. I am not sure, but I
suspect that Squid cannot mimic properties of an already open connection
(yet). If that suspicion is accurate, then Squid should close S1.

* ssl_bump bump step2: In your configuration, clients are bumped without
mimicking server details. In that case, one can view S1 as totally
independent from C1. When C1 is closed, S1 can remain open.


> Now, the client initiates another HTTPS connection, C2. Since,
> persistent connection is enabled, expectation is to see that S1 gets
> re-used.

Same two cases as above:

* ssl_bump stare step2: The TLS properties negotiated on the C2
connection depend on the server connection properties and, if S2 is
established, may end up being different than the TLS properties of C1
(which depends on S1). To honor its configuration, when C1 comes, Squid
should either open a new S2 connection or mimic the properties of the S1
connection. Again, I suspect that Squid does not know how to do the
latter so it opens S2.

* ssl_bump bump step2: In your configuration, clients are bumped without
mimicking server details. In that case, one can view S1 as totally
independent from C1. When C2 comes, S1 can be reused.


> Behaviour seen now is that S2 gets created and a handshake ensues
> between squid and server.


> After ~30seconds, S1 is re-used to serve the request C2.

If there are no other in-progress requests for S, then the combination
of the two seems like a bug to me: Squid (in your configuration) should
either reuse S1 right away or never reuse S1.

I am not sure which connections you capture represents, but it seems to
be missing packets for the second (client port 46550) TCP stream (no SYN
packet, for example). Without you publishing the keys for these
connections, it is not possible to see what happens at HTTP level.
Posting dedicated Squid debugging logs may be a better strategy.


HTH,

Alex.



> On Mon, Jul 2, 2018 at 4:57 PM, Alex Rousskov wrote:
> 
>     On 07/02/2018 05:34 PM, Vishali Somaskanthan wrote:
> 
>     > I am trying out SSL Bump for my connections from Squid to server and
>     > trying to put along server persistent connections as well. I would like
>     > to know how squid behaves with both of these turned on??
> 
>     In modern Squids, all(*) bumped SSL client HTTP requests (from client
>     connection C) should use the corresponding bumped connection to the
>     server (S). After the first HTTP request, if more requests arrive on
>     connection C, and they are all regular/basic requests, then they can all
>     go through connection S. Once HTTP rules, timeouts, or other factors
>     prohibit connection S or connection C reuse, Squid should close both
>     connections.
> 
>     Please note that I do not know whether Squid correctly forces all(*)
>     HTTP requests on connection C to connection S, but it should. If it does
>     not, file a bug report. Same for closing connection C when connection S
>     becomes unusable.
> 
> 
>     > I see info in the squid wiki page that SSL Bump creates fake CONNECT
>     > requests and Peeking at Step1 creates another CONNECT request. 
> 
>     Peeking or staring may indeed produce internal fake CONNECT requests,
>     but they are unrelated to your question. They are used internally to
>     handle the client TLS connection and for giving adaptation services a
>     say in the matter. Persistency is an HTTP term that is applied to what
>     happens _after_ the TLS connections is bumped.
> 
>     (Also, peeking is a part of the SslBump feature -- they are not two
>     different actions or stages as "and" in your summary implies).
> 
> 
>     HTH,
> 
>     Alex.
>     P.S. (*) "all" should be interpreted as "all that need a server
>     connection" here -- pure cache hits, adaptation-satisfied requests, and
>     probably some erroneous requests (e.g., those blocked by http_access
>     rules?) do not use the server connection.
> 
> 
> 
> 
> -- 
> Regards,
> Vishali Somaskanthan
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>