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

[Alex Rousskov]

On 05/17/2017 12:09 PM, David Hogan wrote:
> ssl_bump peek       step1
> ssl_bump peek       step2 whitelist
> ssl_bump terminate  step2 blacklist
> ssl_bump peek       step2
> ssl_bump splice     step3

The above configuration looks strange but this is squid-dev not
squid-users, so I trust you have good reasons for terminating only at
step2 but also validating certificates (at step3). If not, you may want
to discuss your needs on squid-users.


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

That is correct. You are hitting a known limitation of the current
implementation -- step3 requires OpenSSL wire-level participation even
when splicing the connections. Squid v4 got rid of OpenSSL when
peeking/splicing during step2 (trunk r14670), but the same kind of
changes for splicing during step3 has not been sponsored.


> As an experiment, I developed a patch for the Centos 7 Squid 3.5.20
> source (attached) 

FYI: Please use "universal" diff patches (diff options -U 30 and
--show-c-function). The Squid wiki has more instructions for developers.


> 1. What is the impact of calling checkForPeekAndSplice() from
> Ssl::PeerConnector::handleNegotiateError()? 

IIRC, Ssl::PeerConnector::checkForPeekAndSplice() is the start of
SslBump step3. If your step2 action is not final, then you have to do
step3 or the transaction will stall.


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

I am not sure I understand the question, but

* pure certificate validation is unrelated to ciphers

* actual validation code (in Squid or the validation helper) may look at
ciphers as well (e.g., to reject weak ciphers [for some sites])


> I have read elsewhere that this issue can be overcome by linking squid
> against LibreSSL instead of OpenSSL,

Squid does not support LibreSSL (well). You might be able to resolve the
issue by linking with a newer OpenSSL version, but I have not checked
whether that is actually true.


> however I would much rather put
> together a solution that doesn’t stray too far from the supported
> packages of an operating system vendor.

Your vendor is probably not fast enough compared with the rate of
SslBump changes (unfortunately).


> I would also prefer to not
> have to periodically deal with this each time a new cipher appears.

... or some other aspect of TLS communication changes.

Do you need Squid to validate certificates? If yes, you can probably
hack your personal Squid along the lines of your initial patch OR
sponsor/wait for OpenSSL wire-level removal from the splicing pathway.
If not, you may be able to solve your problem by adjusting your Squid
configuration.


HTH,

Alex.