[squid-users] peek/splice working with lynx but not with firefox or chrome

[Amos Jeffries]

On 11/03/2015 3:28 a.m., Roel van Meer wrote:
> Amos Jeffries writes:
> 
>> > The relevant portions of squid.conf:
>> >
>> >  https_port 192.168.13.1:3130 intercept ssl-bump options=ALL
>> > cert=/etc/ssl/certs/server.pem
>>
>> With "options=ALL" you have enabled all features in the OpenSSL library
>> including features which can cause the popular modern browsers to view
>> Squid as a dangerously insecure server.
> 
> I also tried it without options=ALL. The reason I enabled it was that
> the documentation says:
> 
>  Enable various bug workarounds suggested as "harmless" by OpenSSL
>  Be warned that this reduces SSL/TLS strength to some attacks.
> 
> This seemed useful to me.
> 
>> >  acl step1 at_step SslBump1
>> >  acl step2 at_step SslBump2
>> >  acl step3 at_step SslBump3
>> >
>> >  ssl_bump peek step1
>> >  ssl_bump peek step2
>> >  ssl_bump splice all
>> >
>>
>> Theres nothing in the above which uses SNI. All that does is cause Squid
>> to expolicitly look at the TLS handshake that is going on. Then to
>> splice the two connections together a if it weren't there.
> 
> Yes, I know. I would use something like this for that:
> 
>  external_acl_type sg1t %URI %SRC %METHOD %ssl::>sni /tmp/test.sh
>  acl sg1 external sg1t
>  ssl_bump terminate step3 sg1
> 
> which does work. In the test script, I can either allow or reject a
> connection based on the SNI that is passed in (if one is).
> I have no trouble there, only with the peek/splice stuff.

see Nathan Hoads thread just the other day about a setup same as yours
NOT working.

There are two patches that need applying. One already in the 3.5 series
snapshots to fix SNI on some traffic cases, one still in QA review for
adding an ACL "server_name" that can match SNI without the helper.

> 
> I'm trying to get peek/splice to work on all intercepted https
> connections. As soon as that works, I can do fancy stuff with SNI. But
> when I enable peek/splice as in the config above, I can no longer
> connect to https sites from Chrome and Firefox, so that is what I need
> to solve first. Sorry if I was unclear.
> 
>> >  sslproxy_cert_error allow all
>> >  sslproxy_flags DONT_VERIFY_PEER
>>
>> Then you are explicily disabling the checks to ensure the connections
>> Squid uses to send the clients private data to servers are secure.
> 
> Yes, I am, but since I'm only splicing the connection, the browser
> itself should be able to get the original certificate sent by the
> server, and handle it appropriately. Or am I mistaken there?

That is correct. But also they get it through the filter of your OpenSSL
version parsing and re-packing capabilities for the underlying TLS/SSL
protocol syntax.

Those errors hint at things like the SSLv2/SSLv3 syntax being offered
and rejected, ALPN being mangled, or some advanced timing-based feature
being screwed up by the peek operation.


> 
>> > I'm using squid 3.5.2 built with openssl 0.9.8zc on Slackware 13.1.
>> > Traffic is redirected from port 443 top 3130 with iptables.
>>
>> ... and with an older version of OpenSSL missing many of the last few
>> years worth of TLS crypto features. IIRC the library releases are now up
>> to 1.1.* or something. Its best to keep that kind of thing operating the
>> latest versions.
> 
> I know it missing the latest features, but security patches are
> backported. And I know it is old, but it's what I have to work with
> now.Do you think it might be the cause of the problem I'm having with
> peek/splice, or was it a general recommendation?

Its a potential source of problems. Chrome is very much on the front
line of the arms race attempting to stop things like SSL-Bump working.
Firefox implement their own crypto library which tracks the latest TLS
features at a similar speed of development.
OpenSSL will be perpetually behind both of them, but at least the latest
one(s) have better chances not to be advertising features they reject in
"considered harmful" grounds.

> 
>> It may sound silly but, do all those browsers even support SNI on your
>> OS with the crypto libraries they use?
> 
> Ah, I should have said, chrome and FF are on a Windows 7.

Oay. They should then.


Amos