Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

Bill Bernsen
Hi,

I have squid running as an explicit forward proxy on the host example.com controlling access to all hosts in *.example.com. All the hosts in *.example.com have self-signed certificates that I want to appear as trusted to user browsers. I don't have the option of obtaining a trusted CA. I do, however, have a trusted wildcard certificate for *.example.com available. Is there a way that I can tell squid to present this static wildcard certificate to clients in lieu of all upstream server certificates?

Thank you,
Bill

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

Amos Jeffries
Administrator
On 26/01/19 5:51 am, Bill Bernsen wrote:

> Hi,
>
> I have squid running as an explicit forward proxy on the
> host example.com <http://example.com/> controlling access to all hosts
> in *.example.com <http://example.com/>. All the hosts in *.example.com
> <http://example.com/> have self-signed certificates that I want to
> appear as trusted to user browsers. I don't have the option of obtaining
> a trusted CA. I do, however, have a trusted wildcard certificate for
> *.example.com <http://example.com/> available. Is there a way that I can
> tell squid to present this static wildcard certificate to clients in
> lieu of all upstream server certificates?


As a forward proxy clients are *not* connecting to any of the
*.example.com domains. They are connecting to your proxy hostname - and
telling it to take care of the origin connections. So all clients need
is trust for the CA which signed the proxy's certificate.

The proxy is the only agent in the path which needs to trust the
wildcard *.example.com certificate.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

Bill Bernsen
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)

The HTTPS squid proxy on example.com has a trusted 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 which does its TLS, authenticates, connects to upstream then goes into tunneling mode. The client does the TLS handshake with instance.example.com, receives its untrusted certificate, and isn't happy.

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?

I hacked up my own version of ssl_crtd to serve a static cert and ran into another wrinkle. Is there a version of squid that supports ssl-bump with https_port?

On Fri, Jan 25, 2019 at 9:42 PM Amos Jeffries <[hidden email]> wrote:
On 26/01/19 5:51 am, Bill Bernsen wrote:
> Hi,
>
> I have squid running as an explicit forward proxy on the
> host example.com <http://example.com/> controlling access to all hosts
> in *.example.com <http://example.com/>. All the hosts in *.example.com
> <http://example.com/> have self-signed certificates that I want to
> appear as trusted to user browsers. I don't have the option of obtaining
> a trusted CA. I do, however, have a trusted wildcard certificate for
> *.example.com <http://example.com/> available. Is there a way that I can
> tell squid to present this static wildcard certificate to clients in
> lieu of all upstream server certificates?


As a forward proxy clients are *not* connecting to any of the
*.example.com domains. They are connecting to your proxy hostname - and
telling it to take care of the origin connections. So all clients need
is trust for the CA which signed the proxy's certificate.

The proxy is the only agent in the path which needs to trust the
wildcard *.example.com certificate.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a static wildcard certificate with ssl-bump in explicit forward proxy mode

Amos Jeffries
Administrator
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


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (849 bytes) Download Attachment