Do non-MiTM Reverse SSL Proxies exist? Or do all proxies that do SSL-SSL mappings decode and then re-encode HTTPS traffic?

If this is the case and I want to map https://mypublicdomain.com -> https://myprivatedomain.com how do I go about building a network where only the server at myprivatedomain.com can decrypt the HTTPS request.


There are two fundamental facts to know about SSL/HTTPS:

  • HTTPS is HTTP-within-SSL. In particular, URL don't exist at the SSL level. From the outside, without decrypting the contents, one can see that "this is SSL" and also that "this is for host www.example.com", but not "this is for URL https://www.example.com/foobar/index.html". The "foobar/index.html" can be discovered only by the SSL end, where decryption occurs.

    In your case, this means that any redirect will have to be all-or-nothing: the complete site hierarchy, not a subtree thereof.

  • The HTTPS client (the Web browser) insists on finding in the server certificate the server name it expects, i.e. the one from the URL.

    In your case, since you want the client to see a URL starting with https://mypublicdomain.com then the server certificate will need to contain mypublicdomain.com. Since you want the decryption to occur on the private server, then this means that the private server must use a certificate with the name of the public server in it. And since you want the decryption to occur only on the private server, then the corresponding private key must not be known to the public server.

    The bottom-line is that the private server owns and controls a certificate with the name of another server, and that other server does not control the corresponding private key. Usually, Certification Authority call that "fraud" and try real hard not to let that happen. So you should be able to do that only if you own and control both servers, and the separation you try to enforce is some security-related isolation, not an ownership difference.

So what you seek to do may happen only if you:

  1. Accept that the proxying occurs for a complete site, and do the proxying down to the level of IP packets or TCP connections. In fact, when this occurs, we normally say that this is virtual hosting, not proxying (this can work with SSL, e.g. see this, provided that the client supports the Server Name Indication TLS extension).

  2. Somehow find a way to have a certificate with the public name in it, but the private key is known only to the private server. If you own both, then that's easy and up to you. If the public server is some hosting provider of whom you are only a customer, then this may be difficult.


You are talking about the difference between a transparent socket proxy and a non-transparent protocol proxy.

As domain names (that SSL checks) operate at a different level than IPs (that transparent sockets proxy use), you can proxy an entire host (for a given port). But as Thomas mentions, you can not proxy a specific URL subset as this wrapped within the SSL layer.

You could nest (tunnel) SSL layers, with each layer redirecting/reverse proxying to different servers - but normal browsers don't support this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.