Re: [squid-users] Does squid support TLS ticket based SSL session reuse?

On 20/06/2013 9:06 p.m., Ahmed Talha Khan wrote:
> Let us break down the two cases:
>
>
> On Thu, Jun 20, 2013 at 12:58 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 20/06/2013 6:11 p.m., Ahmed Talha Khan wrote:
>>> Ok lets assume that my library does support tickets. The end-server
>>> also does that. Now how will squid manage those tickets? Will it
>>> simply relay the ticket coming from the origin server side to the
>>> client and vice-versa?
>>
>> Depends on whether we are talking about SSL through CONNECT tunnels, or to
>> an https_port. The CONNECT tunnel relays everything end-to-end from cleint
>> to server and back again.
> 1) SSL is working through CONNECT tunnels and SSL_BUMP is configured
> on it. Now squid is acting as if a direct connection was made to the
> https_port. What would be the behaviour of SSL session re-use?

CONNECT tunnel is from client and transparently relayed through Squid to
the server. The SSL relationship is between client and origin. Squid has
no participation.

With SSL-bump things get really, really, complex. Starting with *what
type* of SSL-bump are you performing? there are three bumping modes.

* "none" bumping behaves as a normal CONNECT tunnel.
* "client-first" bumping acts as case (2) below.
* "server-first" bumping ties the client and server connections together
and tries to behave like a CONNECT tunnel would (without the
multiplexing performance gain and both cnnections close if one does),
but with full processing of the internal HTTPS requests as in (2) below
and the connections are still independent at the SSL level as in (2) below.

Is it *always* succeeding in the bump or are failovers happening?

* "none" bumping has no failover.
* "client-first" bumping acts as if the failures came from the origin on
a CONNECT tunnel. Usually causing somewhat unpredictable knock-on
effects in the client state.
* "server-first" bumping failover terminates both client and server
connections.

>
>> The https_port terminates the client SSL at Squid
>> - it is fully independent from the server connections. Remember the server
>> connection in Squid may not even be HTTPS ...
> 2) SSL is working directly to https_port i.e squid is terminating
> HTTPS. Also my servers are guaranteed to have HTTPS backend. What will
> be the behaviour of SSL session reuse in this case?

There is no crossover of SSL session information between client-side and
server-side connections. Squid terminates the client connections to
receive the requests, and uses a completely independent server connection.
Squid will optimize usage of the connections to your servers,
multiplexing inbound client requests into as few connections as
possible. Squid is *the* client to your servers....

> I am asking for both the conditions because I use squid in both
> CONNECT and transparent mode.
>
>> Squid supports Gopher, WAIS,
>> FTP, HTTP, and HTTPS backends.
>> And HTTP multipexing means any two requests
>> arriving from the client may use different server connections and/or backend
>> services.
> Use of different connections to the same server should not effect the
> SSL reuse behaviour. That is the whole point of it. Isnt it? Also,
> two requests originally for the same server will always go to that
> same server. Multiplexing could only change the connection to that
> server and I pointed out earlier that it should not effect SSL session
> re-use?

If you are looking at all Squid connections to the server using the same
"SSL session" then no multiplexing will not affect that, and it means
*all* clients accessing that server through Squid will share the same
session on the server side of Squid. There will only be *one* SSL
session used by Squid for its outgoing HTTPS.

Amos
Received on Thu Jun 20 2013 - 11:16:11 MDT