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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
