[squid-users] [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

[Amos Jeffries]

> On Mon, 2017-01-23 at 19:54 -0700, Alex Rousskov wrote:
>> On 01/23/2017 04:28 PM, David Touzeau wrote:
>>>
>>> ssl_bump peek ssl_step1
>>> ssl_bump splice all
>>>
>>> sslproxy_flags DONT_VERIFY_PEER
>>> sslproxy_cert_error allow all
>>
>>>
>>> When connecting to mozilla.org using transparent, we receive this
>>> error:
>>>
>>> * About to connect() to www.mozilla.org port 443 (#0)
>>> *   Trying 104.16.41.2...
>>> * connected
>>> * Connected to www.mozilla.org (104.16.41.2) port 443 (#0)
>>> * successfully set certificate verify locations:
>>> *   CAfile: none
>>>   CApath: /etc/ssl/certs
>>> * SSLv3, TLS handshake, Client hello (1):
>>> * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
>>> protocol
>>> * Closing connection #0
>>> curl: (35) error:140770FC:SSL
>>> routines:SSL23_GET_SERVER_HELLO:unknown
>>> protocol
>>>
>>>
>>> And squid access.log
>>>
>>> 1485110919.564      3 192.168.1.236 TAG_NONE/403 6263 CONNECT
>>> 104.16.41.2:443 - HIER_NONE/- text/html
>> Amos, please note that the above failing test is done using curl, not
>> some fancy/non-HTTP/websocket traffic from a "browser".

Doh! Thats why its weird. The error is coming from curls OpenSSL
library, not Squid's one.


>>
>> David, you need to figure out why Squid is denying the intercepted
>> connection attempt (the /403 part in your access.log). Check your
>> http_access rules to start with. They were applied to the denied fake
>> CONNECT request shown above.
>>
>> AFAICT, Squid denies the [fake] CONNECT without bumping the client
>> connection to serve a secure error message. That is _not_ what I
>> would
>> expect because usually Squid bumps to serve errors, even when dealing
>> with non-bumping ssl_bump rules. However, I may be misinterpreting
>> the
>> "unknown protocol" part; perhaps OpenSSL can use that phrase for an
>> unsupported TLS version as well? Or perhaps Squid failed to bump the
>> client for some reason?
>>
>> Capture packets to see what Squid is sending to curl.
>>


On 24/01/2017 4:15 p.m., James Lay wrote:
> Seems like pretty standard stuff:
> Jan 23 20:09:04 (squid): 192.168.1.109 - - [23/Jan/2017:20:09:04 -0700]
> "CONNECT 104.16.40.2:443 HTTP/1.1" www.mozilla.org - 200 916167
> TCP_TUNNEL:ORIGINAL_DST
> TLSv12	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	secp256r1
> James

This is a different log trace from David's.

Here Squid is setting up a TUNNEL to the clients original dst-IP,
successfully. Any TLS funky stuff going on for this transaction is done
directly between server and client. Squid's only involvement is to peek
at the Hello messages and record them for its log.

But some of those details (ie the agreed cipher) come from the
ServerHello on successful TLS setup. So I think no errors happened in
that log entries transaction.

Amos