[squid-users] can't get bump to work anymore on 3.5.7?

[Jason Haar]

On 19/08/15 16:07, Alex Rousskov wrote:
> Your interpretation is correct: Your configuration tells Squid to peek
> at steps #1 and #2 and then try to bump at step #3. Unfortunately, the
> last two actions (peeking at step #2 and then bumping at step #3) are
> usually not compatible. Please see the Limitations section at
> http://wiki.squid-cache.org/Features/SslPeekAndSplice


Ah! I used to use "external_acl_type" to run a script that would check
the SSL status of the host:port and that would allow squid to decide
whether to bump or splice. I'd turned it off for whatever reason - I
guess that's why it was working before. (in all of this I am speaking in
the context of transparent TLS - I realize for the formal proxy scenario
you typically have the SNI name/hostname via the CONNECT method). Sure
enough, once I deleted the peeks, it started bumping

So is there no way to get the SNI field from the client without breaking
the opportunity for bump? It's just that my testing has already shown
everyone using CloudFlare for HTTPS is now protected by their WAF
technology - which rejects SSL sessions that don't contain SNI. So if
you are wanting to (transparently) bump HTTPS, you can't use peek - but
you need peek in order to discover the SNI hostname, because if you
don't have that then  acls using ssl::server_name_regex and/or
"external_acl_type" will basically get rejected talking to vast numbers
of https servers in the world. This is a bit of a catch-22

My packet sniffer implies the SNI details is in the first TLS packet
sent from the client (ie pre-encryption). So couldn't squid just make a
note of that detail? Sort of a "pre-peek" I guess? I read about how
there are so many SSL extensions/etc that squid will always be running
afoul of issues if it tries to be too smart, but can't we look at this as

1. client->server (3-way TCP handshake)
2. client sends first TLS packet (contains extensions data - including
SNI). Gets to squid server
3. squid can extract that data, and make decisions immediately just on
that one packet. It can compare with acls and decide to bump or splice
4. if bump, squid forms the client->squid TLS channel and a separate
squid->server TLS channel
5. if splice, squid now forms a TCP channel to the server, then forwards
that first TLS packet, then "joins the two ends"
6. waits for next client packet


If all HTTPS transactions contained the hostname (because of CONNECT or
SNI), then squid could be set to default to bump, but to splice known
"un-bumpable" sites  - due to pinning or because they are not actually
HTTPS sites (eg Skype). It just seems like it's currently limited to
default splice, with bumping explicit things? (which I can't believe is
useful)

-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1