[squid-dev] Introduction / SslBump prototype patch to ignore unknown ciphers

[David Hogan]

Hi all,

I am new to the Squid source and I am hoping for some advice about the
SslBump peek and splice code in PeerConnector.cc . I have about a
decade of commercial C++ experience although for the last 8 years or so
I've been using higher level languages. I have a reasonable amount of
experience related to network code and concepts.

Sorry for the essay length message .. thanks in advance to anyone who
reads it :)

BACKGROUND:

I been trying to set up a reliable transparent squid blacklist
enforcing proxy using an operating system vendor supplied version of
Squid, without decrypting client traffic. The Ubuntu squid package
isn’t linked against OpenSSL so I am playing with CentOS 7, which
provides Squid 3.5.20 with a few backported fixes.

I have a config that blocks based on matching SNI at SslBump step 2
and then splices at step3 having validated the server certificate. I
am currently assuming that when the server certificate is validated,
squid checks that the SNI server name received in step2 is actually
present in the certificate.

ssl_bump peek       step1
ssl_bump peek       step2 whitelist
ssl_bump terminate  step2 blacklist
ssl_bump peek       step2
ssl_bump splice     step3

This setup appeared to work, however when connecting to wikipedia.org
with Chrome I would sometimes see the following error:

kid1| Error negotiating SSL on FD 13: error:140920F8:SSL
routines:SSL3_GET_SERVER_HELLO:unknown cipher returned (1/-1/0)

This is due to CHACHA20_POLY1305 being negotiated, which openssl on
CentOS 7 doesn’t recognise. This error prevents squid from further
validating the certificate or splicing the connection, even though use
of the cipher within squid isn't actually necessary for splicing.

As an experiment, I developed a patch for the Centos 7 Squid 3.5.20
source (attached) that prevents the usual error handling from
occurring when OpenSSL returns a SSL_R_UNKNOWN_CIPHER_RETURNED error.
This works in the sense that the splice is then successful, however
according to my tests it bypasses the usual server certificate
validation against certificate authorities.

MY QUESTIONS:

1. What is the impact of calling checkForPeekAndSplice() from
Ssl::PeerConnector::handleNegotiateError()? Particularly, in the case
that an ssl error of SSL_R_UNKNOWN_CIPHER_RETURNED is detected? I
found that by simply returning without calling this, the connection
stalled. I will admit that I don't know yet what
checkForPeekAndSplice() is doing or why it works.

2. Can anyone offer any advice on how server certificate validation
could proceed as normal after detecting (and ignoring) an unknown
cipher?

I have read elsewhere that this issue can be overcome by linking squid
against LibreSSL instead of OpenSSL, however I would much rather put
together a solution that doesn’t stray too far from the supported
packages of an operating system vendor. I would also prefer to not
have to periodically deal with this each time a new cipher appears.

Cheers,
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: squid-3.5.20-unknown-cipher-ignore.patch
Type: application/octet-stream
Size: 516 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20170517/11ede0ad/attachment.obj>