I must say that the answer has confused me more. >> >> Does squid support SSL session reuse? If so then is it based on the >> older ssl session_identifiers or the TLS ticket scheme? > > > Maybe, and Unknown. > What do you mean when you say unknown? Do you mean that if the origin server supports ssl session re-use using ticket, squid will only relay that ticket to the client?Or it will supply a new ticket? > >> The next question is that if it does support the session reuse, how is >> the session cache maintained by squid? > > > Squid does not maintain SSL session cache. Squid simply relays details to > and from OpenSSL. What happens in there is up to yoru OpenSSL lirary > configuration. > > Squid ss_crtd and validator features maintains a cache of *certificates* > which have been generated or seen in the current traffic. > My question was not related to certificates. I wanted to ask about ssl sessions reuse. > >> Also will the session reuse functionality be available both between >> client-squid and squid-orginserver. > > > No. client-squid and squid-origin traffic is unrelated. HTTP/1.1 contains > multiplexing which means any request may arrive in any client connection and > go out any suitable server connection. > What I meant to ask was whether squid offers the ssl session re-use capability on the client side? > > >> I am looking at forward proxy mode > > > In normal forward-proxy mode there are two ways Squid handles SSL. > A) CONNECT method. An opaque binary stream of data between the client and > server. Squid does not touch this in any way**. > > B) SSL connection direct to the proxy. The SSL is decrypted using the > confugured serve cert and the result is plaintext HTTP requests for https:// > URLs, handled normally inside the proxy. > > > ** except when SSL-bumping - in which case it unwraps the CONNECT and > decrypts the SSL exactly as if it has been received on an https_port - the > handling of (B) then applies. > > Amos -- Regards, -Ahmed Talha Khan
