Search squid archive

Re: Does squid support TLS ticket based SSL session reuse?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux