[squid-users] ALPN, HTTP/2 and sslbump

[Amos Jeffries]

On 04/01/18 11:30, brianbergstrom wrote:
> I am using Squid 3.5.27 and recently started having issues when I upgraded
> from openssl 1.0.1 to 1.0.2 which I believe introduced support for h2/ALPN.
> I have narrowed down the issue to a request that fails but succeeds with
> curl's --no-alpn flag.
> 
> Here is the error message from Squid for the failure, though the request
> ends up timing out with an EOF error.
> Handshake with SSL server failed: error:140920E3:SSL
> routines:ssl3_get_server_hello:parse tlsext
> 
> A tcpdump of the failure when curl sends ALPN which contains http/1.1 and h2
> as its client protocols, of which the Server Hello replies and chooses h2.
> 
> A tcpdump of successful request with the --no-alpn flag verifies that no
> ALPN TLS extension data is present.
> 
> If I understand the docs and this thread correctly, Squid should be removing
> h2 from the ALPN in the Client Hello since Squid does not support it.  But
> it appears to be passing it through and failing when the server chooses it.

Sort of, but not quite.

What you have configured is 'splice' - so Squid is constrained to 
delivering both the TLS handshake and the encrypted data from the client 
exactly as-is to the server. The APLN removal happens when Squid is able 
to alter the handshake - eg for the 'bump' action.

The existence of things like ALPN should not matter to Squid when 
splicing as the HTTP inside the encryption is never even looked at.

However, for the 'peek' action to succeed your OpenSSL library on the 
Squid machine does need to support the TLS features being used by both 
client and server endpoints. In this case it appears that the TLS 
extension message in TLS itself is not being parsed correctly by the 
library.


Your best options (in order of preference) are:

* update to an even more recent OpsenSSL version (1.1 etc) in hopes that 
the ALPN support is more correct than the 1.0.2 code, and/or

* move your squid.conf "ssl_bump splice ..." above the "ssl_bump peek 
.." lines so the splicing happens earlier if the client SNI details are 
sufficient to make the decision, and/or

* try an upgrade to Squid-4. We have redesigned the handshake parsing in 
that version not to depend so much on OpenSSL.

If even the latest Squid with latest OpenSSL library have the issue 
please file a bug report. It will need a copy of your config settings, 
and the tcpdump full-packet trace of the server handshake which is failing.


Amos