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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
