Timeline for How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 15, 2020 at 19:34 | comment | added | Babu Srinivasan | Maxim, in TLS_(EC)DHE_RSA_WITH_AES (ephemeral diffie hellman), the server, in addition to presenting certificate that contains its RSA public key, it also signs its ephemeral DH parameters with its RSA private key and sends it to client. Client uses server's RSA public key to verify the signature on the DH parameters. If signature check succeeds, authentication succeeds and client sends its ephemeral DH parameters to server. Both parties use the DH parameters to compute the same pre-master secret. As both parties contribute material to compute the pre-master secret, this is called key exchange | |
| Apr 15, 2020 at 19:34 | comment | added | Babu Srinivasan | Maxim, there is only one step and not 2 steps. This is why I said "The client authenticates the server indirectly". A bogus server will not be able to decrypt the encrypted pre-master secret and so authentication fails. Only the legitimate server has the RSA private key, the fact that it can decrypt and get the pre-master secret and compute same symmetric keys to encrypt/decrypt traffic is proof that the server is who it claimed to be in the certificate. As only one party (the client) generates the pre-master secret, this is called key-transport and not key exchange. This is TLS_RSA_WITH_AES. | |
| Apr 15, 2020 at 17:47 | comment | added | Maxim Masiutin | Of course the client encrypts the pre-master secret and sends it to the server, not the other way around, thank you for spotting that wrong order of words in the comment. | |
| Apr 15, 2020 at 17:45 | comment | added | Maxim Masiutin | Thank you for the explanation. I've got what you mean. By authentication you've meant that by verifying server’s certificate, the client uses the server’s public key from that certificate to authenticate the server. The client later uses the same public key for key transport or key agreement (in old non-ephemeral mode) or to verify ephemeral key sent by the server. The RFCs on various version of TLS in this context contain phrases like “If RSA is being used for key agreement and authentication”…. | |
| Apr 15, 2020 at 17:33 | comment | added | Maxim Masiutin | You wrote that RSA is used for “1 (authentication)”. What do you mean here by “authentication” in terms of using the RSA key data from the server’s certificate? There is only one operation where this key is used, not two as you wrote. In “TLS_RSA_WITH_AES_...” it is only used for “key transport” (the client encrypts, and the server decrypts the “premaster secret”), while in “TLS_(EC)DHE_RSA_WITH_AES_...” it is only used to sign by the server (and verify by the client) the ephemeral key, as you correctly pointed out. | |
| Apr 14, 2020 at 23:01 | comment | added | Babu Srinivasan | Maxim, the client encrypts the pre-master secret and sends it to the server, not the other way around. | |
| Apr 14, 2020 at 22:56 | comment | added | Babu Srinivasan | Maxim, by authentication, I mean that the client authenticates the server. Note that the server only presents a certificate, not proof that it has the corresponding private key. The client authenticates the server indirectly --- it generates a random pre-master-secret, encrypts it with server's RSA public key and sends it to server. Both the client and server can compute the master secret using the pre-master secret. Only the legitimate server will have the RSA private key to decrypt the encrypted pre-master secret and compute the same master secret. Refer to Section 7.4.7.1 of RFC 5246 | |
| Mar 9, 2014 at 4:34 | history | answered | Babu Srinivasan | CC BY-SA 3.0 |