Hacker News Reader

You could encrypt the handshake that you recieved with the server's certificate and send it back. Then if it doesn't match what the server thought it sent it aborts the handshake. As long as the server's cert isn't broken this would detect a munged handshake, and if the server's cert is broken you have no root of trust to start the connection in the first place.

View on HN

How do you agree a protocol to encrypt the message to agree the protocol?

This is the message that returns a list of supported ciphers and key exchange protocols. There’s no data in this first packet.

Alice: I’d like to connect Bob: Sure here is a list of protocols we could use:

You modify bob’s message so that bob only suggests insecure protocols.

You might be proposing that Alice asks Trent for Bob’s public key … But that’s not how TLS works.

Bob's list of supported protocols is an input into the (authenticated) final handshake message, and that authentication failing will prevent the connection from being considered successfully established.

If the "negotiated" cipher suite is weak enough to allow real-time impersonation of Bob, though, pre-1.3 versions are still vulnerable; that's another reason not to keep insecure cipher suites around in a TLS config.

The fine man in the middle could still intercept that.

Reply on news.ycombinator.com