3 ms·

Note that in most browser to web server communications that both sides don't usually sign the conversation during authentication, only the server does. This mea

Note that in most browser to web server communications that both sides don't usually sign the conversation during authentication, only the server does. This means the client knows it's the right server but the server doesn't know who the client is, which is why you have to use a username/password in some crappy web form for authentication.

ivanr 9y ago
Right. As you say, on most web sites the client is anonymous as far as TLS is concerned, and the server proves its right to respond to the requested hostname with a CA-backed certificate (and proof that it holds the private key that corresponds to the public key embedded in the certificate). To drill deeper in the the handshake, however, both client and server do sign the initial handshake (with the final negotiated session secret, effectively). The idea is that you need to ensure that the handshake hasn't been tampered with. An active network attacker could have changed the original TLS connection request (ClientHello) to force usage of a particular cryptographic component they know how to break. For example, SSL v2 had no handshake protection which is why someone in control of the network could always enforce the weakest encryption (only 40 bits).