[squid-users] squid 5.0.4 cache_peer bug on https outgoing

[Amos Jeffries]

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