Solution 1:

The issues you're seeing are the same that prevent the use of multiple certificates on a single IP address/port (without using Server Name Indication).

In plain HTTP, your transparent proxy can tell which host the client wants to connect to by looking into the Host header.

When the HTTPS MITM transparent proxy gets the request, it can't know which host name the client was requesting in the first place. (I'm not even sure it can get the IP address with these rules, which might at least have allowed it to make a guess using a reverse DNS lookup, even though it's unlikely to work in the general case.)

  • In order to get the expected host name, the MITM proxy would have to read the Host header in the HTTP message, which can only occur after a successful handshake.
  • In order to have a successful handshake, the MITM proxy needs to generate a spoof certificate matching the expected hostname.

As a result, the MITM proxy can't know which certificate to generate before the handshake.

This can work with a non-transparent MITM proxy, because you would at least get the intended host name via the HTTP CONNECT method.

Solution 2:

Just some basic info about this topic.

There are only a few devices that I know of that can succesfully pull off this action. However they are not really available to the common public. I myself am using a Fortinet Fortigate with SSL Offloading.

What it basically does is; it intercepts the SSL Connection made to the host and decrypts the connection in hardware, then inspects where you want to go and makes a firewalling decision based on that information.

Afterwards it sets up it's own connection to that host to retrieve the data and re-signs the original request to the client using a CA provided by the user. To make this work smoothly it is required to have the CA in the trusted root CA on the client.

These kind of setups are used in organisations to enforce company policies regarding internet usage. Since using an Active Directory it is easy to install your company CA in clients this forms no issue for large organisations.

This is the ONLY way you can do it without creating a manual proxy, since SSL traffic IS encrypted. It basically is a MITM so it is important to have any legal issues covered.