2 ms·
That would still rely on A) some kind of secret that only the server knows that the client can verify in order to ensure it's not trading nonces with the MITM.
by PowerBar 6y ago
That would still rely on
A) some kind of secret that only the server knows that the client can verify in order to ensure it's not trading nonces with the MITM.
B) A way for the client to ensure that the nonce isn't being passed through a second tcpcrypt session between the MITM and the server with the connection being in cleartext between the 2 tcpcrypt streams.
Currently the best supported method of implementing both A and B is certificates, which means you may as well use TLS.
- Dylan16807 6y ago> which means you may as well use TLS Even if you don't authenticate at all, it makes it much more expensive to intercept all these connections. And TLS lacks a way to automatically apply it to all connections. Also I don't understand what scenario you're outlining with B.
- Spivak 6y agoClient <-> Evil Middlebox <-> Real Web Server Client establishes a tcpcrypt session with what it thinks is Real Web Server but is actually Evil Middlebox replaying the request to the server and the response back to the client.
- Dylan16807 6y agoOh so A and B are describing the same scenario, okay.
- Spivak 6y agoYeah, I'm not sure what the parent was getting at separating them out since from the clients perspective they're the same. I guess they mean that getting a tcpcrypt connection on your server isn't a guarantee that there isn't a middlebox either.
- PowerBar 6y agoThey were alternative ways to prevent a MITM, but they both have solutions solved by existing TLS.