[squid-users] squid callout sequence

[Gordon Hsiao]

>
> 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
> noticed
> >     > 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
> HTTPS
> >     (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
> of
> >     > ssl-bump, correct?
> >
> >     No. SSL-Bump is an operation applied to a CONNECT message, when
> setting
> >     up the TLS tunnel. There are maybe also *multiple* CONNECT messages
> when
> >     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
> and
> >     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.
>
> Amos
>
>
> 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,

Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180625/4fb2def7/attachment.html>