On Thu, Jun 20, 2013 at 4:15 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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@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. > 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
