Get info encrypted across a MITM proxy

Question

All current protocols seem to only fail when MITMed. For example, SSL displays a huge red warning when somebody tries to MITM using a different certificate.

Is there any protocol that can actually work securely despite best efforts to MITM it? Obviously the TCP connection can always simply be blocked, but is there any protocol designed to be resilient to MITM in the sense that the attacker will think he succeeded in breaking the protocol but actually the data is still encrypted?

Clearly SSL-over-SSL-over-SSL-...-over-SSL works most of the time for corporate firewalls and the like, but it relies on security by obscurity and the handshake would take forever.

Answer 1

The failure is not in the protocol, it is in the people. Or, arguably, in the tools, who should handle matters that are too technical for human users to do correctly.

The SSL protocol states how things go, and that the connection will be secure, notably against Man-in-the-Middle attacks:

-  The negotiation of a shared secret is secure: the negotiated

   secret is unavailable to eavesdroppers, and for any authenticated
   connection the secret cannot be obtained, even by an attacker who
   can place himself in the middle of the connection.

But this holds only if the protocol is really followed to its full extent, and, in particular, if the validation of the server public key is not "shortcut".

Thus, there is nothing to change in the protocol. When tools don't implement the protocol properly, then the fault usually lies in the tools, not the protocol.

We could argue that if browsers still allow for bypassing the "bad certificate" warning (though that warning has increased in reddish scariness over the years), then this might be an indication that the protocol assumptions are not realistically tenable. Namely, requiring that all Web servers have a SSL certificate that client browsers can validate might be a bit too much to ask for. But, honestly, security has to start somewhere. Cryptography does not create trust, it transfers trust. You cannot have a protocol which guarantees that the client will always talk to the "right" server without having, at least, a definite notion of what "right" means in that context.

---

If phishing or MitM attacks with a fake server certificate, clicked through by the user, become too prevalent, I expect browser vendors to actually remove the bypass altogether, and enforce strict X.509 validation. We'll see in a few years.

Answer 2

MitM can occur in a few ways. In the scenario you are talking about, you are describing where the MitM is making two connections, one to the client and one to the server. He is not decrypting or breaking TLS. The certificate warning allows you to know the information is not coming directly from the server.

At the same time, if one knows the encryption keys or can later learn them and have saved the traffic, one can decrypt the message. If you can fully imitate the sender in real time you can just decrypt traffic, make new traffic, and re-encrypt as if you are the legitimate sender. The goal of MitM may be to eavesdrop or it may be to manipulate.

In corporate environments, sys admins can often "break" TLS or other encryption becuase they control the client PCs and can install the proper certificates on the client to have them trust the corporate TLS-decrypting firewall/SIEM/etc. In this case, the end-user on the client would not know their traffic is being decrypted.

The eavsdroping and manipulation of data can also be performed not on the network, but at the sender or receiver using malware or man-in-the-browser techniques.

Unless you use a honeypot/honeynet system to inject fake traffic or purposefully use a poor encryption, I am not sure how one could make the attacker think they succeeded when they really did not. They will either have garbage data or they will have data they can process. For example, with HTTPs, you either decrypt it and you have something that is intelligible to a human and a piece of software, or you have gibberish that cannot be processed. While possible, it is highly unlikely the encrypted message would be decrypted into a format that looks intelligible, but is not true without knowing the real system.

If you know what keys the attacker already has and the techniques they are using it may be possible to inject traffic onto the network which they would be able to intercept and decrypt to think they got the message, but they would probably wonder about all the other traffic they are not decrypting and that is using different keys.

Answer 3

The user is always the weakest link. If you have the best, most awesomely secure protocol ever but the attacker convinces the user to send them a check instead, it doesn't mean there is a problem with the protocol, it means there is a problem with users. The user has to get information from somewhere to tell them that the server is who they say they are or they have no way to trust the connection. SSL does it's best to warn the user not to trust the connection, but still gives the option. In theory a client could simply not allow the user to accept an untrusted certificate, but this would frustrate the user in to trying other means like using a non https connection.

There is no magic way for you to figure out information about the legitimate server (unless you have prior knowledge) that can't be attacked by a man in the middle changing the information that claims to be the legitimate server. This is why the most secure systems require physical handling of prior knowledge keys that are transported under armed guard. The initial establishment of trust is the Achilles heel of trusted communication. If the user actively chooses to trust the wrong people, that's their problem, not an issue that can be solved by technological measures.

As far as something where the attacker could think they succeeded but actually hadn't, you are talking about the realm of deniable encryption there and it would be pretty hard or impossible to do with a stream cypher due to the way the data is stored. You would need data that could be decrypted with 2 different keys and that one decryption would give the real result while the other gives something fake.

The problem is two fold, however, when trying to apply this to a stream cipher. First, you have a generally 1 to 1 relationship between ciphertext and plaintext. Most deniable encryption requires a much larger volume of data some of which appears to be garbage (but is actually a signal for the other key). Since a 1 to 1 relationship would be expected, the excess data would throw up flags.

The second issue is key disclosure. Strong protective measures against MITM require that the key exchange itself be protected. Most MITM attacks therefore attack against the key exchange and prevent the key exchange with the actual intended server. Thus, there wouldn't be a way to give the real server the correct key while giving the MITM the diversionary key.