Ssl – Squid ssl_bump server_first

httpsPROXYsquidssl

I am trying to test the ssl_bump server_first Squid directive, but I did not understand how it works.
As far as I understood the ssl_bump directive has three working modes:

  • None: HTTPS traffic is not intercepted, the client connects directly with the remote server, squid only forwards the traffic.
  • Client first: The client connects to Squid via SSL (so at the first connection the user has to accept the SSL certificate of Squid), and Squid connects to the server, automatically accepting its SSL certificate. (Or are there options to accept only some certificates and refuse others?)
  • Server first: Squid connects to the server, it accepts the SSL certificate, then…? Squid documentation says:

Establish a secure connection with the server first, then establish a secure connection with the client, using a mimicked server certificate.

What does 'mimicked server certificate' mean? Squid produces a fake certificate copying (?) the one received from the remote server?
I tried to set up a ssl_bump server_first Squid, but every time that I connect to an HTTPS site the browser warns me that the certificates are mismatching, and if I examine the certificate I see that is always the same one, created during Squid installation…I don't see any difference with the "Client first" behaviour then…

I know that SSL intercepting is not a safe procedure, but I am explorying this feature because I might be forced to use it…

Thank you in advance.

Best Answer

The difference is between server-first and client-first is what error message the user ends up seeing (or not seeing)

With client-first SSL bump, there's three problems:

  1. The SSL certificate presented mismatches the destination; e.g. The client sees that the SSL certificate is issued to proxy.yourdomain.com, but the user is trying to visit www.securewebsite.com. Their browser will warn them about this. (bad)
  2. The SSL certificate is from an untrusted certificate authority. Their browser will warn them about this too. (bad)
  3. If there's a problem with the server SSL certificate, there's no good way to let the client know. By the time Squid finds out there's an error (maybe it's expired, not trustworthy, for the wrong site, etc.) the client already has a "good" SSL certificate and thinks it's about to receive the real traffic. Their browser can't warn them about this. (also bad)

Server-first SSL bump eliminates the first and third problems. The second remains. Here's a decent resource on the reasoning for using server-first ssl bumping. It was apparently written when the feature was still being developed, so don't let the future tense confuse you.

Since you generated the certificate yourself, and anyone can generate a certificate themselves, merely having a certificate doesn't mean the communication is safe. The certificate has to be from an issuer you trust. Browsers come by default with a list of trusted certificate authorities. Those CAs vouch for the certificates they sell, and that's how your computer knows to trust certificates.

The solution to this problem is that you have to tell your computer to trust the certificate you're using for ssl-bumping. The procedure is different for different OSes. For windows clients you can push something out via GPO, for mobile you can push it out with MDM, etc.

Just for testing (in windows), you can right click the certificate and choose install. Walk through the wizard. Instead of letting windows choose where to put the certificate, browse and select Trusted Root Certification Authorities. Once you've done this, your computer will trust any certificate generated by your squid ssl-bump server.

Related Topic