|
|
|
|
|
by hedora
2084 days ago
|
|
I wish the world would adopt tcpcrypt. SSL provides two services, encryption, and authentication. tcpcrypt just does the encryption part. Once the connection is established, userspace on both sides can invoke an ioctl that provides a session nonce. If the nonce matches on both sides, the connection is not man-in-the-middled. It’s easy to confirm the nonce matches: Both sides sign it and send it to the other party. This has two big advantages: (1) operating systems can opportunistically encrypt traffic for unmodified legacy applications and network protocols, allowing the endpoints to detect mass surveillance without requiring any certificates. (2) Like newer versions of SSL, it encrypts the information currently sent in cleartext in the SNI, preventing the type of censorship in the article. |
|
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.