[squid-users] Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

[Amos Jeffries]

On 31/01/19 7:47 am, Bill Bernsen wrote:
> Amos, thank you for the quick response. My original question could use
> an example to clarify.
> 
> client ------> example.com (HTTPS squid proxy)
> ------> instance.example.com (HTTPS server)
> 

Sadly this does not by itself actually clarify the issue. Are those
domains the machine hostnames or the HTTP(S) message URL domains?
 (The description later does that, so this comment is more an FYI.)


> The HTTPS squid proxy on example.com has a trusted

... definition of that "on" and thus its implications for traffic syntax
and the resulting behaviour limitations is the key point(s) I am trying
to understand here.


> wildcard certificate for *.example.com
> The HTTPS server on instance.example.com 
> has an untrusted certificate for instance.example.com
> 
> So without MITM, the client issues a CONNECT to squid running on
> example.com <http://example.com> which does its TLS, authenticates,
> connects to upstream then goes into tunneling mode. The client does the
> TLS handshake with instance.example.com <http://instance.example.com>,
> receives its untrusted certificate, and isn't happy.


In this case the client is fully aware that the proxy exists.

=> The proxy did *not* get a request to contact instance.example.com -
therefore it did not connect to instance.example.com.

==> The proxy was asked for a tunnel to "example.com" and all security
validation done by the proxy will be comparing the *exact* FQDN
"example.com" against values in that traffic.

The client *separately* (inside the tunneled opaque bytes) contacts the
server and negotiates use of the "instance.example.com" virtual host.

=> The proxy has zero involvement and zero knowledge of this.

==> all security validation done by the client itself and will be
comparing the negotiated FQDN "instance.example.com" against values in
that traffic.

PS. Note there are no wildcards other than the cert field(s). The things
tested against that wildcard has always an exact actual value.


> 
> I'm looking for a MITM mode that, instead of requiring a CA that can
> dynamically create trusted certs on the fly, will return a wildcard
> certificate for all requests (or even better, for any requests matching
> hosts in its subdomain). Is that something that exists?

MITM mode the client does not connect to the proxy. The client connects
to an origin.

 The network NAT or whatever doing the *intercept* part is delivering
the traffic to the proxy.

 Squid is _itself_ generating the CONNECT which shows up (to simplify
processing and failure handling). What data is available determines what
can be done:

SSL-Bump step-1 : only TCP SYN packet details are available.
   ==> raw-IP:port and nothing else.

SSL-Bump step-2 : TLS SNI (maybe)
   ==> exact FQDN value "instance.example.com"

Notice that at no point yet is the MITM ever aware that "example.com"
plays a part and no reason to even suspect a wildcard existence.

At step-3 things get a little bit easier since the server X.509
certificate is available. That cert is the only place the wildcard can
come from, and is in a certificate field where free-form text is allowed
and *often* used. One sub-domain may also sit on a separate server not
using this same cert with wildcard. So care needs to be taken to avoid
issues from that data source.


> 
> I hacked up my own version of ssl_crtd to serve a static cert and ran

Fine. Though you should be able to use generate-host-certificates=off
and place your static cert into the cert= parameter. If that is not
working it is a Squid bug to be fixed.

I have PRs already underway to make the generate option take the CA cert
and leave cert= for the static certs like your case needs. No ETA on
when that will be completed though.


> into another wrinkle. Is there a version of squid that supports ssl-bump
> with https_port?

All versions of Squid-3.2 and later support SSL-Bump on https_port.

Though since forward-proxy and MITM have mutually exclusive X.509
certificate requirements currently the only way to do SSL-Bump on
https_port is to use "intercept" or "tproxy" traffic modes - leaving
explicit TLS proxy with the forward-proxy mode.


Amos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190131/384c4d85/attachment-0001.sig>