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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
