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