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