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

[Soren Madsen (DREIJER)]

Thanks for the quick reply, Amos.

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

That's correct. That's why I don't want to bump such connections and instead fall back to splicing. In other words, if I can't trust the server, I want to get out of the way and defer the decision to the client.

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

Yes, but Squid has no way of trusting a self-signed cert. When Squid mints a server cert on the fly and sends it to the client, the client won't have any idea that the cert was originally self-signed. Like the previous scenario, I'd want to step out of the way and defer the decision to the client.

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

I don't think I see the big problem here. If you hit a web server with 10 connections, but Squid decides to splice the connection after all and therefore closes the connections and create 10 new ones, that's hardly going to cause any alarms to go off. After that point, Squid will cache the fact that connections to that hostname shouldn't be bumped and subsequent attempts at hitting that hostname (based on the SNI, for instance) won't be bumped again until the cache expires.

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

Sure, and that's the point of the cache I mentioned above. If there happens to be a transient problem with the server, it's okay that Squid doesn't bump the connection for, say, an hour until it checks the host again. I see this as optimistic bumping, i.e. bump if you can but under no circumstances break the connectivity between the user and the server.

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

I don't follow what you're saying here. How is looking at a server cert and determining that Squid cannot trust it "vague-ish" criteria? And a host of legal issues?

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

I don't see why that is a problem if you just recreate the connection to the server. That is, you first try bumping the connection by sending a new clientHello to the server, and if the server cert cannot be verified, a new connection is established and the original clientHello is sent to the server.

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

How would you propose supporting self-signed certs in this scenario? 
This also means that in order to allow the client to use SSLv3, I'm going to have to allow Squid to bump SSLv3 connections, which I'm not keen on for the reason you mentioned yourself above.

Thanks,
Soren