<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 6:17 AM <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-11-02 07:49, Grant Taylor wrote:<br>
> On 11/1/22 11:33 AM, squid3 wrote:<br>
>> That is not true as a blanket statement.<br>
> <br>
> Please clarify which statement / who you are addressing.<br>
> <br>
> It seems as if you're addressing mingheng (copied below for <br>
> convenience):<br>
> <br>
<br>
Yes I was addressing mingheng's statement.<br>
<br>
<br>
> On 10/31/22 7:32 PM, mingheng wang wrote:<br>
>> I delved into the configuration the last few days, and found that <br>
>> Squid doesn't officially support cache_peer when ssl_bump is in use.<br>
> <br>
> But you may be addressing my statement (...):<br>
> <br>
> On 11/1/22 10:44 AM, Grant Taylor wrote:<br>
>> That surprises me. I wonder if it's a technical limitation or an <br>
>> oversight.<br>
> <br>
> <br>
> On 11/1/22 11:33 AM, <a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a> wrote:<br>
>> What Squid officially *does not* support is decrypting traffic then <br>
>> sending the un-encrypted form to a HTTP-only cache_peer.<br>
</blockquote><div>Oh sorry, I was meant to say that. I tested setting a sslstrip proxy as cache_peer</div><div>when ssl_bump was in use, and it didn't work. I was too focused on my setup and</div><div>forgot the case of regular proxies.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>
> Please elaborate. I'm trying to develop a mental model of what is and <br>
> is not supported with regard to client / proxy / server communications. <br>
> I'm unclear on how this applies to the two potential HTTPS streams; <br>
> client-to-proxy and proxy-to-server.<br>
<br>
Okay, some info that may help with that mental model...<br>
<br>
The first thing you need to do is avoid that "HTTPS" term. It has <br>
multiple meanings and they cause confusion. Instead decompose it into <br>
its TLS and HTTP layers.<br>
<br>
* A client can use TCP or TLS to connect to a proxy.<br>
- this is configured with http_port vs https_port<br>
<br>
* Independently of the connection type the client can request http:// or <br>
https:// URLs or CONNECT tunnels.<br>
<br>
* Independent of what the client is doing/requesting, a cache_peer may <br>
be connected to using TCP or TLS.<br>
- this is configured with cache_peer tls options (or their absence)<br>
<br>
* Independent of anything else, a cache_peer MAY be asked to open a <br>
CONNECT tunnel for opaque uses.<br>
- this is automatically decided by Squid based on various criteria.<br>
<br>
<br>
TCP is the foundation layer. On top of that can be HTTP transfer or TLS <br>
transfer. Transfer layers can be nested infinitely deep in any order.<br>
<br>
So "HTTPS" can mean any one of things like:<br>
1) HTTP-over-TLS (how Browsers handle https:// URLs)<br>
2) HTTP-over-TLS (sending http:// URLs over a secure connection)<br>
3) HTTP-over-TLS-over-TLS (relay (1) through a secure cache_peer)<br>
4) HTTP-over-TLS-over-HTTP (relay (1), (2) or (3) through an insecure <br>
cache_peer via CONNECT tunnel)<br>
<br>
Each agent along the chain can add or remove any number of transfer <br>
layers to the protocol X-over-Y stack. Although for efficiency most <br>
prefer to minimize the layering depth.<br>
<br>
A typical web request may flow across the Internet through a chain of <br>
proxies like this:<br>
<br>
client -(1)-> S1 =(4)=> S2 =(1)=> S3 -(2)-> O<br>
<br>
C = origin client<br>
S1 = forward-proxy<br>
S2 = insecure relay proxy<br>
S3 = TLS terminating reverse-proxy<br>
O = origin server<br>
<br>
<br>
> Or if this is more applicable to TLS-Bump on implicit / network <br>
> transparent / intercepting proxies where the client thinks that it's <br>
> talking HTTPS to the origin server and the proxy would really be <br>
> downgrading security by stripping TLS.<br>
> <br>
<br>
It's *more* important with SSL-Bump 'bump' due to the interception <br>
nature of that operation. But also applies to other cases.<br>
<br>
SSL-Bump implies interception of TLS<br>
* intercept may happen at network level (port 443 redirect or NAT)<br>
* intercept may be entirely within Squid (CONNECT tunnel unwrapped)<br>
<br>
Decryption is independent of interception.<br>
a) SSL-Bump 'bump' action performs decrypt (the others do not)<br>
b) a TLS forward/explicit-proxy performs decrypt<br>
c) a TLS reverse-proxy performs decrypt<br>
<br>
Traffic from (a) case requires re-encrypt before sending, even if its <br>
URL indicates insecure protocols.<br></blockquote><div> I don't understand. According to the wiki on Squid that I read, there are several</div><div>steps involving "peek", "bump" or "slice" etc, we can already choose to bump or</div><div>slice through SNI at step2. So why does HTTP have to be encrypted too?</div><div><br></div><div> Anyway, essentially what I need is like splitting Squid into two parts: the client</div><div>side part communicate with a client over a connection with dynamically generated </div><div>certificates in order to fool the client when dealing with HSTS; while forwarding traffic</div><div>unencrypted to the "other part" of Squid somewhere, which in turn establishes a</div><div>new connection with the original server to do the bump thing and so on.</div><div><br></div><div> Since Squid doesn't support this, I'll stop fiddling with it. I think HTTP isn't a very</div><div>complicated protocol, and most HTTP libraries can handle TLS as well. Perhaps it </div><div>won't be hard to write a simple proxy for personal use and Squid even has a tool </div><div>called security_file_certgen, maybe I can make use of it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Traffic from (b) MUST be re-encrypted when it is for a secure protocol <br>
eg https://, otherwise optional.<br>
Traffic from (c) SHOULD be encrypted on sending, but always optional.<br>
<br>
The "re-encrypt" may take the form of TLS to the secure peer, or a <br>
CONNECT tunnel through any peer with TLS to whatever is at the other end <br>
of the tunnel.<br>
<br>
<br>
> Here is my mental model based on my current understanding. Is the <br>
> following diagram accurate?<br>
> <br>
> +-------------+-----------+<br>
> | P2S-HTTP | P2S-HTTPS |<br>
> +-----------+-------------+-----------+<br>
> | C2P-HTTP | supported | supported |<br>
> +-----------+-------------+-----------+<br>
> | C2P-HTTPS | unsupported | supported |<br>
> +-----------+-------------+-----------+<br>
> C2P = Client to Proxy communication<br>
> P2S = Proxy to server communication<br>
> <br>
<br>
Vaguely yes. There are three dimensions to the matrix, you only have two <br>
shown here.<br>
The box showing "unsupported" has "supported" in its other dimension.<br>
<br>
<br>
>> All other permutations of inbound TCP/TLS, http:// or https:// URL, <br>
>> and outbound TCP/TLS should currently work to some degree. The more <br>
>> recent your Squid version the better it is.<br>
> <br>
> ACK<br>
> <br>
> <br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Like a Fool,I'm very foolish.<br></div></div></div>