Ask HN: Technical solutions to connect securely over known MitM'ed connection?

5 points by iamsohungry ↗ HN
Is there a way to implement secure HTTPS on top of MitM'ed HTTPS? Or changes to HTTPS that would make this possible?

My first thoughts are:

1. Connecting via HTTPS, detecting an invalid cert, and then requesting a valid cert from the target website over the MitM'ed connection, and just passing the rest of the traffic over the MitM'ed connection encrypted w/ the valid cert. The problem with this is that any standardized way of requesting the cert could be blocked by the MitM attacker.

2. Preload a large database of certs and connect via HTTPS, detect an invalid cert, and send data over the MitM'ed connection encrypted with the cert from your database, then have the server when they receive an encrypted request, decrypt it with their private key, and if it's still not valid, decrypt it again with their private key. This is harder to detect and block by the MitM because encrypted data, which is essentially random, could look like valid data, but it's also hard to detect on the server because actually random data could be used to DDOS the server (send it random data and it infinite loops).

Are there other approaches, or ways to fix the problems I see with these approaches?

6 comments

[ 3.4 ms ] story [ 23.5 ms ] thread
Cert PIN-ing should prevent MITM'ed ssl from working.
I am not sure that works. Putting the MITM certificate in the trusted certificate store will make Chrome allow the interception.
I haven't thoroughly researched cert pinning, but it seems like basically the same as the SSH message you get when you SSH into a new server. If my understanding is correct, it does nothing to solve this problem.

1. It only prevents you from connecting over a MitM'ed connection if the cert is already pinned, i.e. if you've visited the site before.

2. If your connection is MitM'ed, you have no way to securely access the site you want except connecting over another channel.

#1 wouldn't work because the attacker could just intercept your request and send you a new fake certificate.
If it's possible, it seems like you need to add a second channel for your handshake protocol. SMS is pretty difficult to MitM for non-state-sponsored attackers.
Encapsulate Ethernet over HTTPS - then they'll only decrypt the first HTTPS layer and get to see your Ethernet traffic, but if you're using this Ethernet "link" to tunnel all your traffic, you would end up using HTTPS inside it, effectively having HTTPS over Ethernet over HTTPS :)

We are currently working on a SaaS offering to solve this issue and unlock many other scenarios; e.g. intercloud or onprem<->cloud seamless networking. We should be ready for our beta around Christmas.