If TLS communication uses ciphers that does not support forward secrecy[FS] (like RSA key exchange ciphers), confidentiality of the past communication is compromised if the private key is compromised. But will the integrity also gets compromised in this scenario? I got this doubt after seeing the CVSS scoring in this link. Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N - The severity of integrity compromise is given as Low. Could anyone explain how integrity is getting affected in the absence of FS?

2 Answers 2


Generally, the integrity wouldn't be impacted. Usually it can't be, really, since the communication was presumably recorded some time ago. However, the symmetric key used for integrity (HMACs or AEAD modes) is exposed, and that could be a meaningful impact in some specific cases.

  1. The attacker has a man-in-the-middle position on an ongoing TLS channel, and compromised the private key after the TLS handshake but recorded the handshake and encrypted traffic. In this case, the attacker can now modify or forge messages that the recipient (client or server) will think are genuine.
  2. Attacker has recorded a TLS session and then (without the victim's knowledge) compromised the private key. The attacker can decrypt and modify the recording, and re-encrypt with patched integrity codes. This recording could then be offered to the victim (or any other party with access to either the private key or the ephemeral symmetric key), with the attacker claiming that it is genuine ("after all, if I changed anything the integrity codes wouldn't verify") in order to "prove" something was/wasn't sent. (As a side note: since the "legitimate" traffic thus "recorded" would effectively be authenticated by the certificate used in the key exchange, it would effectively prevent repudiation by the server, if the server owner were compelled to produce the key. This generally isn't a consideration of TLS, but could be relevant in some cases.)
  • I don't think non repudiation is relevant here. It is not something MAC or AE is supposed to offer anyway. If I compromise the private key unbeknownst to the legitimate server, I can perform MITM attack. If known and changed, I can still create a whole "communication history" all by myself out of thin air. If you are talking about compromising ephemeral DH private key (and the session key), and not necessarily the signing key, I can create alternative communication from past session, but I need to provide them the key to "prove" anything, revealing that I have the key, thus proving nothing. May 26, 2021 at 12:17
  • The context is explicitly methods that don't provide forward secrecy. The idea of case 2 is that the attacker pretends they just recorded traffic and then (perhaps via court order) compels the owner of the private key to decrypt the key exchange and therefore the entire exchange. Normally, somebody executing such an order would believe the traffic thus decrypted to be genuine, because the attacker couldn't have modified it. If the attacker stole the private key first, though, they could (thus violating integrity).
    – CBHacking
    May 26, 2021 at 22:50
  • Oh.. I was thinking about the case with forward-secrecy enabled, and thus my second scenario. My bad. May 27, 2021 at 5:45

The core idea here is that with RSA key transport the client generates a session key, encrypts it for the server using the server's RSA public key, and sends it. If an attacker gets a copy of the server's RSA private key, then they can passively sniff future traffic, decrypt any TLS handshake and extract the session key.

With DHE or ECDHE cipher suites, the server generates a one-time-use DH or ECDH key (that's the 'E' for 'ephemeral' in DHE / ECHDE), it signs that ephemeral DH key with its RSA key, and sends it to the client. The client verifies the signature using the server's public key (aka certificate) to know that it came from the authentic server. The client also generates themself a DH / ECDH key, completes the key exchange to get a session key, and sends its ephemeral DH key to the server so it can do the same. An attacker who has the server's RSA private key could still do active man-in-the-middle attacks where it impersonates the server (by signing DHE keys that the attacker generated), but it's not possible to extract session keys from the wire.

If you want to dive deeper on how the TLS handshake works, I love this website:

PS technically 's/session key/pre-master secret' whatever.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .