On 28/09/20 6:41 pm, openwrt wrote: > Yes, I've tried all of these combinations. > > ### 0x00 cache_peer no ssl > >> ssl_bump allow all "allow" is not a SSL-Bump action type for any version of Squid. <https://wiki.squid-cache.org/Features/SslPeekAndSplice#Actions> AFAIK, SSL-Bump falls back to default "bump all" as the action performed. >> cache_peer 127.0.0.1 parent 3129 0 【no ssl】 > > curl http://google.com <https://google.com/> -x > http://admin:squid@localhost:3128 -v -k 【it is ok】 > This does HTTP(-over-TCP) to Squid asking for HTTP to origin. A non-TLS/SSL peer is perfectly capable of fetching that. > curl https://google.com <https://google.com/> -x > https://admin:squid@localhost:3128 -v -k 【Get 502】 This does HTTP(-over-TL)S to Squid which told to accept HTTP(-over-TCP). Expect 502 generated by the frontend Squid. > curl https://google.com <https://google.com/> -x > http://admin:squid@localhost:3128 -v -k 【Get 502】 > This does HTTP(-over-TCP) to Squid asking for CONNECT tunnel containing HTTP-over-TLS to origin. Expect that the tunnel be accepted fro decryption by the frontend Squid (200 status), then another CONNECT tunnel generated to fetch the decrypted traffic via the insecure peer. > > log json: > > { "clientip": "127.0.0.1", "ident": "-", "uname": "admin", "timestamp": > "2020-09-28T04:16:28+0000", "verb": "CONNECT", "request": > "google.com:443 <http://google.com:443>", "httpversion": "HTTP/1.1", > "response": 200, "bytes": 0, "referer": "-", "agent": "curl/7.47.0", > "request_status": "HIER_NONE", "hierarchy_status": "HIER_NONE"} > CONNECT tunnel received and decrypted. This says that you actually received a 200 status to at least one of your tests. I expect it was for that third one. > { "clientip": "127.0.0.1", "ident": "-", "uname": "admin", "timestamp": > "2020-09-28T04:16:28+0000", "verb": "GET", "request": > "https://google.com/";, "httpversion": "HTTP/1.1", "response": 502, > "bytes": 117, "referer": "-", "agent": "curl/7.47.0", "request_status": > "HIER_NONE", "hierarchy_status": "HIER_NONE"} > Decrypted request was not able to be sent anywhere. This is your main problem - made worse by the ssl_bump misconfiguration. The 502 message contains a brief description about what went wrong. cache.log may contain more details - if not, increase the verbosity for troubleshooting with "debug_options ALL,2 83,7" > > ### 0x01 cache_peer with ssl > >> ssl_bump allow all >> cache_peer 127.0.0.1 parent 3129 0 ssk > > curl http://google.com <https://google.com/> -x > http://admin:squid@localhost:3128 -v -k 【Get 502】 > curl https://google.com <https://google.com/> -x > https://admin:squid@localhost:3128 -v -k 【Get 502】 > > < HTTP/1.1 503 Service Unavailable > This is 503, not the 502 you mention above. * Which of the two different test commands produced it? * It says that there is a TLS protocol syntax problem talking TLS/SSL to the server or peer. > > < X-Squid-Error: ERR_SECURE_CONNECT_FAIL 71 > > > <p>The system returned:</p> > > <blockquote id="data"> > > <pre>(71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)</pre> > > <p>Handshake with SSL server failed: [No Error]</p> > > </blockquote> > > > ### 0x02 how to outgoing https request by cache_peer (on squid > 5.0.4/Chains proxy) > > Similar features to Charles OR Fiddler. ( open http(s) proxy on 8080, > then capture the request , outgoing on another http(s)/socks4/5 proxy.) > > 1. Fiddler > gateway: https://docs.telerik.com/fiddler-everywhere/user-guide/settings/gateway > > curl https://google.com -x http://squid:3128 --> outgoing(cache_peer: > like Fiddler gateway) --> google.com:443 <http://google.com:443> > > The cache_peer should be ignore ssl VERIFY. !!! like other software. > No. There is no use using TLS if you are going to disable *all* the security. What Squid should actually happen is that you configure Squid to know what CA signed the peer SSL certificate (with cache_peer tls-cafile= option). So that connections properly going to that peer will verify successfully. The default you have with just the "ssl "flag (FYI: that should be "tls" nowdays) uses the operating systems default Global Trusted CA's to verify. Allowing interception attacks and transfer corruption on the peer traffic to be identified if/when any happen is the entire purpose of using TLS/SSL on peer connections. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
