[squid-users] Does Squid support client ssl termination?

Wed Nov 2 00:58:25 UTC 2022

On Wed, Nov 2, 2022 at 6:17 AM <squid3 at treenet.co.nz> 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 at treenet.co.nz 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>

-- 
Like a Fool,I'm very foolish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20221102/d2c4e2d9/attachment.htm>