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

[Alex Rousskov]

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

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.


HTH,

Alex.