[squid-users] squid callout sequence
capcoding at gmail.com
Mon Jun 25 13:56:08 UTC 2018
> On 25/06/18 14:59, Gordon Hsiao wrote:
> > On 25/06/18 05:15, Gordon Hsiao wrote:
> > > at https://wiki.squid-cache.org/SquidFaq/OrderIsImportant I
> > > redirectors are way ahead of ssl-bump in the callout order, in a
> > > https-ssl-bump case
> > There is not really any "https-ssl-bump" case.
> > There is SSL-Bump (decrypting a TLS stream - or not), and there is
> > (HTTP messages inside TLS).
> > > you will need ssl-bump to run (so you can get full
> > > URL for example), then you can run redirector based on the result
> > > ssl-bump, correct?
> > No. SSL-Bump is an operation applied to a CONNECT message, when
> > up the TLS tunnel. There are maybe also *multiple* CONNECT messages
> > SSL-Bump gets involved - which the FAQ text following that sequence
> > describes.
> > HTTP is stateless protocol. So the CONNECT message(s) are
> independent of
> > both each other, and anything decrypted from inside the tunnel. Each
> > every message Squid handles gets its own cycle through the callout
> > sequence.
> > > why is redirector run before ssl-bump?
> > Because Squid needs to know _where_ it is going before it can connect
> > there. SSL-Bump is part of tunnel/connection setup.
> > Amos
> > will SSL-Bump(not 'peek+splice', but the 'peek+bump' mode) decrypt all
> > the tcp packets? For example I connect to youtube.com/myvideo
> > <http://youtube.com/myvideo>, will peek+bump only decrypt the pseudo
> > CONNECT messages(I'm doing transparent proxy), or will it decrypt all
> > the video streams too? if it's the latter case the proxy will be cpu
> > intensive.
> Sorry if I wasn't clear. The ssl_bump (directive and CONNECT handling)
> part is the TLS handshake at the beginning of TLS connections. Once the
> decrypt or splice is setup it just continues indefinitely. Whatever is
> being decrypted from within that TLS is completely separate from the
> bumping itself.
> So, peek+bump itself will only deal with TLS handshake part(e.g. to get
FQDN/full-URL for redirectors) , still the proxy will have to do
aes-decrypt-and-encrypt for the same TCP stream when peek+bump is used,
which could be very cpu intensive, correct? Because once peek+bump is used,
the proxy split the ssl stream into two segments and will have to deal with
everything for both ends.
peek+splice is totally different and it will not need the
aes-decrypt-and-encrypt, basically just probe for SNI then tunnel the whole
connection, so proxy's cpu should not be overloaded at all.
Thanks a lot for the explanations,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squid-users