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