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
