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?
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.
- 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.
- 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.)
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.