[squid-users] squid callout sequence
squid3 at treenet.co.nz
Mon Jun 25 23:35:30 UTC 2018
On 26/06/18 01:56, Gordon Hsiao wrote:
> 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 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
> > 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
> > 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)
Using the correct terms helps understanding. see RFC 7230
'peek' and 'bump' are actions the SSL-Bump feature does.
* SSL-Bump 'peek' action gives the TLS SNI. Which is *only* a domain
name / FQDN
- so an authority-form URI (FQDN:port) is known for the server.
* SSL-Bump 'bump' action exposes the encrypted requests which contain
their own URI-scheme, domain, port, path, query etc.
- so the full absolute-form URI is known for each decrypted message.
- these may not match the authority-form URI from the CONNECT message.
>, still the proxy will have to do
> aes-decrypt-and-encrypt for the same TCP stream when peek+bump is used,
To get full-URL (ie path and query parts).
> 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.
Though to complicate things the presence of a proxy at all splits the
stream into "two parts" to get that peek ability. It's just that splice
action afterwards avoids the decrypt+encrypt CPU cycles.
More information about the squid-users