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

[Roel van Meer]

Amos Jeffries writes:

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

That's very useful for the SNI matching indeed. Thanks!

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

It seems so.

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

I'll have a go then at trying with a newer openssl and the patches from the  
thread you mentioned.

Thanks a lot so far,

Roel