[squid-users] Peeking on TLS traffic: unknown cipher returned

[Alex Rousskov]

On 10/19/2016 10:12 PM, Jason Haar wrote:

> This is a complex situation for most people (myself included), can you
> tell us how to "peek and make a decision based on SNI"?

I have (long time ago) in the "Peek at SNI and Bump" and other examples
at http://wiki.squid-cache.org/Features/SslPeekAndSplice

Since then, that page have been significantly improved, mostly by others
(thanks, Marcus!) so you may find better examples there.

In short, if you want to do everything based on SNI, then do not let
Squid to get to SslBump step3. Make all final (splice, bump, or
terminate) decisions during step2 (or earlier). That implies that your
ssl_bump rules have to be shaped without step2 and step3 ACLs.


> I'm probably like the original poster in that I simply want to be able
> to do transparent proxy of TCP/443 so as to better log HTTPS
> transactions. I wouldn't even bother with the "terminate" bit - if I
> wanted to blacklist some HTTPS sites, I'd rather rely on the normal
> non-bumping ACLs, the SNI-learnt domain names -  and "deny" - I don't
> care if a cleartext blob is sent through to a client who thinks it's TLS
> - it will break and that's all that matters.

Squid does not work that way. If you tell Squid to "deny" something,
Squid will most likely try to bump the client connection to serve the
corresponding error page. The early developers, reviewers, and users all
thought that serving a plain text error response to an SSL client is
pointless. If you want to avoid bumping at all costs, then "ssl_bump
terminate" is your best option.

Virtually all errors, including certificate validation and OpenSSL
failures are treated similar to access denials and result in bumping.
This is often the right default, but it would be good to add a knob for
fine-tuning that behavior, similar to how the recently added
on_unsupported_protocol fine-tunes treatment of parsing errors.


HTH,

Alex.