What Happens to TLS Keys When a Server Is Compromised?

TLS protects network traffic by generating secrets during each connection. Those secrets include ephemeral private values used for key exchange, a shared secret established between the client and server, handshake keys, and application traffic keys used to encrypt and authenticate data. In a conventional software implementation, these values are created, processed, or stored within the server’s operating system and application memory while a TLS connection is active.

TLS 1.3 normally uses ephemeral Diffie-Hellman key exchange. The client and server each create a temporary private value and exchange the corresponding public value. Each side combines its own private value with the other party’s public value to derive the same shared secret. That shared secret is used by the TLS key schedule to derive separate handshake and application traffic secrets. TLS then derives the symmetric encryption keys and initialization values used to protect records sent in each direction.

A server also uses a long-term authentication key, usually the private key corresponding to its TLS certificate. This key is used to sign the handshake and prove that the server controls the identity presented in its certificate. In a standard TLS 1.3 connection, the certificate private key authenticates the handshake; it is not normally the input used to derive the session’s ephemeral traffic keys.

A compromise can expose different TLS materials with different consequences. Access to a live connection’s application traffic secrets can allow an attacker to decrypt traffic protected by those secrets while they remain valid. Access to a session’s ephemeral private value or shared secret can allow derivation of the session’s keys, depending on the point at which the material is obtained and which values are available. Access to a server’s long-term certificate private key can allow an attacker to impersonate the server in new connections, subject to certificate validity, key type, server configuration, and the attacker’s ability to redirect or intercept clients. NIST identifies the protection of server private keys and TLS session keys as a core key-management requirement.

TLS 1.3 provides forward secrecy for normal ephemeral key-exchange handshakes. If an attacker records encrypted traffic and later obtains the server’s long-term certificate private key, that key alone should not allow the attacker to decrypt earlier TLS 1.3 sessions. The session keys were derived from temporary key-exchange material rather than from the certificate private key. This protection depends on using ephemeral key exchange correctly and deleting session material when it is no longer needed.

Forward secrecy does not protect a connection whose active session secrets are extracted while the connection is running. An attacker with control of the host may be able to inspect process memory, attach debugging tools, alter a TLS library, read application-level key logs, or capture key material before it is erased. If an attacker obtains the active traffic secrets, recorded ciphertext from the affected session can be decrypted. NIST’s TLS visibility guidance describes architectures in which exported session keys are deliberately collected to enable real-time or retrospective decryption, illustrating that possession of session keys is sufficient to recover protected traffic.

TLS 1.3 maintains separate client-to-server and server-to-client traffic secrets. It also distinguishes handshake secrets from application traffic secrets. This separation limits the role of each key, but it does not prevent an attacker who obtains the relevant active secret from decrypting the traffic protected by that secret. RFC 8446 recommends erasing secrets once their derived values are no longer needed.

TLS 1.3 supports a KeyUpdate mechanism that derives new traffic secrets during an active connection. After a key update, an implementation should delete the previous generation of traffic secret and its associated keys. A later compromise of the new traffic key should not reveal data encrypted under the deleted earlier traffic key. A standard KeyUpdate, however, derives the next key from existing secret material; it does not perform a new ephemeral key exchange and does not by itself provide full post-compromise security.

TLS session resumption requires separate consideration. A resumed TLS 1.3 session may use a pre-shared key derived from an earlier connection or provisioned separately. Resumption using a pre-shared key without a fresh Diffie-Hellman exchange does not provide forward secrecy with respect to that pre-shared key. Resumption that includes fresh ephemeral Diffie-Hellman key exchange provides stronger separation from prior session material. TLS 1.3 early data, commonly called 0-RTT data, also has weaker security properties: it is not forward secret and does not have built-in replay protection.