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

[David Hogan]

Hi Alex,

Thank you for your response.

On 17 May 2017 at 21:01, Alex Rousskov <rousskov at measurement-factory.com> wrote:
> 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.

I found that applying a blacklist at step3 resulted in too many false positives
caused by subjectAltName matches. For example, the certificate for
www.bing.com also lists hosts related to their ad network, which meant that
applying an ad blocklist at step3 would also block www.bing.com. I realise
that blocking at step2 is flawed as bypassing the blacklist is as simple as
not including SNI in the request, however I am hoping separately to figure
out how to match missing SNI and terminate, either by acl config or a patch.

I just tested that sending a fake SNI causes certificate verification error,
which is great.

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

Or are you saying that the OpenSSL validation code could be used directly,
rather than having OpenSSL think it's doing a real handshake?

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

Sorry, i've attached an updated patch for any future discussion.

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

We set up a server with both ChaCha20 and a self signed cert, with my
patch, no validation was performed and the connection was spliced.

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

I tried the Fedora 26 alpha with Squid 4.0.11 and OpenSSL 1.1.0e, but had
the same unknown cipher issue.

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

Certificate validation is a killer feature and given that it almost works all of
the time, I think i'll try and come up with a patch that ignores the unknown
cipher whilst still validating the certificate.

Thanks for your help,
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: squid-3.5.20-unknown-cipher-ignore.patch
Type: application/octet-stream
Size: 3637 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20170517/71b56b51/attachment-0001.obj>