[squid-users] squid callout sequence

[Amos Jeffries]

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
>     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>
>     > <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)

Using the correct terms helps understanding. see RFC 7230
<https://tools.ietf.org/html/rfc7230#section-5.3>

'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.

Yes.

> 
> 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.

Close yes.

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.

Amos