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

On Thu, Jun 20, 2013 at 4:15 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> 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.
>

The release I am using only has client-first method. "Server-first"
was only introduced in 3.3 and I am using an older version. My
question in the lower portion

> 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....
>
>

 Ok so there is no cross over I get that. But will squid issue new ssl
session tickets towards client side? so that
the client can use this ticket next time to do an abbreviated
ssl-handshake as the purpose of tickets suggests?

>
>> 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

--
Regards,
-Ahmed Talha Khan