Does SSL/TLS contain any form of identification in the initial handshake, so an attacker cannot simply waive the certificate around claiming they are someone else? Wikipedia did not say that it did, but I was wondering if the public key on the server cert is sometimes used for this. Or is this assumed since the the attacker cannot complete the handshake without the private key(and thus cannot complete the key-exchange and generate the symmetric key for authentication like HMAC)?
Asked
Active
Viewed 181 times
1
-
How would "the attacker cannot complete the handshake without the private key" not constitute a "form of identification in the initial handshake"? – Jul 19 '15 at 03:58
1 Answers
2
There is no way to perform identification before the cert is sent, because the whole point of the cert is to establish identity. So if you could establish identity of the server before receiving the cert, what would be the point of validating the cert against the server? This is actually another point, a cert is for a domain, so a client should always check that the domain in the cert matches the domain that it is connecting to. So technically if I try to connect to evil.com over HTTPS and you give me the cert for google.com I shouldn't validate the cert (Though implementations have been known to omit this check!!). And like you said, you could send a cert that is not your own, and the if the client (incorrectly) validates this cert the client then sends a secret encrypted under the public key contained within that cert to the attacker. The attacker is unable to decrypt this data since it does not have the private key. At this point the attacker is unable to derive any symmetric keys from the secret the client sent it (since it cannot decrypt the secret), and as a result is unable to decrypt any traffic sent from the client.
puzzlepalace
- 681
- 3
- 11
-
@puzzzlepalace so that public key on the cert is solely used for key-agreement/verification of a session key? – dylan7 Jul 19 '15 at 16:23