[squid-users] Splicing a connection if server cert cannot be verified

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/12/2014 8:11 a.m., Soren Madsen (DREIJER) wrote:
> Hi all,
> 
> By default, I want to bump all connections through my Squid
> instance. However, while testing I've discovered lots of sites that
> use SSLv3


Offering SSLv3 from a server is suicide these days. Those sites should
be on the fast decline, or at very least shunned like plague victims.
Lookup POODLE if you dont know why already.


> or self-signed certificates,

Nothing wrong with self-signed though. Much *more* secure than CA
validated certs when used in DANE protocol.

> in which case I'd like to fall back to TLS passthrough mode and let
> the client decide whether it wants to trust the server or not. In
> other words, if Squid cannot successfully bump a connection, I
> don't want to fail the connection, but rather step out of the way
> and let the client decide what to do.
> 
> The ideal solution, I think, would be to optimistically attempt to 
> bump the connection, but if it fails due to e.g. a bad server cert,
> a new connection can be established with the original client
> hello.
> 
> I was hoping the new peek and splice functionality would be able
> to help me in this regard: 
> http://wiki.squid-cache.org/Features/SslPeekAndSplice
> 
> As far as I can tell, the 'stare' action is what I'm interested in 
> here although it appears it's not a focus of the current 
> implementation, and the 'peek' action has the following limitation 
> note about 'Peeking at the server often precludes bumping': "We
> could teach Squid to abandon the current server connection and then
> bump a newly open one. This is something we do not want to do as it
> is likely to create an even worse operational problems with Squids
> being auto-blocked for opening and closing connections in vein."
> 
> I'm confused about this. Couldn't Squid just cache the information 
> about whether it has previously refrained from bumping a
> connection due to a bad server cert (or other errors) and only
> check with the server once the cache expires? That should avoid
> triggering any alarms on the server.

Happy eyeballs clients open multiple connections in parallel, causing
Squid to be seen opening just as many. Adding the above behaviour
would make the number of connections hammering the server multiply by
*at least* 2.

Also, with modern HTTPS load balancers every since connection is
potentially going to a different real backend server, with different
TLS settings even if the domain, IP, and port details are exactly
identical. Things could also change with no notice as admin fix
transient problems.

If you are going to bypass bumping based on vague-ish criteria then
you might as well just not bump. That gets you away from all those
technical probems, and a host of legal issues as well.


AIUI, the basic problem that "precludes bumping" is that in order to
peek at the serverHello some clientHello has to already have been
sent. Squid is already locked into using the features advertised in
that clientHello or dying - with no middle ground. Most times the
client and Squid do not actually have identical capabilities so
peeking the serverHello then either bump or splice actions will break
depending on which clientHello Squid sent.


> 
> Maybe I'm misreading the document. I was hoping somebody here on
> the list could explain to me if I can achieve the above behavior.
> 

I suspect you actually need the certificate mimic behaviour. Where
Squid generates a server cert as close as possible to the original,
including errors so the client can decide how to handle them.


HTH
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUj0A6AAoJELJo5wb/XPRjBFgH/3G1mlMG/qMMcPH772Txy53I
iW7vi6is+V015UTKOxYs8cygB4eSFCtL8gXc2+y8ezOsZbSYX9kxCNqChul8clRE
fR8Bo+IldSP7ZcK8lBdoQdPVWz061P+OeyXnvz39ehajXaiXjOrstmT/G4HPWK79
vknA4aznvEnOZN/7qjcF9Arf2BbOQh7JzoO1hLD0XO2jKhS5E+/LbdJgw4i5tH+k
d8ZdxGSmFO/A7J1IZM9tH1bpuXQa3GSGHgEEDnPz7bMKw2mIKCoDV+BxNpqa9gsu
uWjNwEmA4/KAx5JzA/fYOGWDZDh3vsnUXcovRWxlEOB2N24EINz6I4bkTvdqLsY=
=1lCG
-----END PGP SIGNATURE-----