Legacy in Handshake: Understanding TLS 1.2 Prevalence and Its Operational Risks

Although TLS 1.3 has become the modern standard, TLS 1.2 still accounts for nearly 50–60% of encrypted network traffic, depending on the source and service type. It remains widely supported—and in some cases, still preferred—due to its broad compatibility with older systems and applications.

While TLS 1.2 can be deployed securely, it’s sometimes configured in ways that undermine forward secrecy—most commonly by using static RSA key exchange (TLS_RSA*). In these configurations, if an attacker obtains the server’s private key, they can decrypt any recorded session—past, present, or future.

In theory, an attacker could also recover a private key by factoring the RSA modulus to obtain its primes p and q. In practice, this only works if the key was generated with poorly chosen or non-random primes—a rarity in modern TLS stacks, where secure libraries choose strong primes automatically. The only realistic scenarios where this happens are:

• Keys generated with outdated or broken cryptographic libraries
• Keys where p and q were chosen manually or generated with weak/randomness issues
• Keys reused from old systems affected by known prime factorization failures

This means the attack path we demonstrate depends entirely on misconfigured or flawed key generation—not on breaking strong RSA in the general case.

Given its ongoing prevalence, it’s important to understand how TLS 1.2 can be targeted by adversaries. In this post, we’ll demonstrate how encrypted traffic using TLS 1.2 can be decrypted under realistic conditions—particularly when weak configurations or RSA-based handshakes are involved.

To do this, we’ll analyze a packet capture (PCAP) containing a full TLS 1.2 handshake and encrypted session. We’ll walk through identifying key exchange details, reconstructing the necessary decryption materials, and importing them into Wireshark to reveal the plaintext.

Let's first review the TLS 1.2 protocol looking at the handshake in the following PCAP with Wireshark.

In this capture, the handshake exchange follows the classic TLS 1.2 pattern. Two key packets form the backbone of the session setup:

Packet 4 – Client Hello

This is the client’s initial greeting, where it offers:

• A list of supported cipher suites (e.g., RSA-based, DHE, ECDHE) A random value (used later in key derivation)
• Optional TLS extensions like:
• SNI (Server Name Indication)—lets the server know which hostname the client wants
• ALPN—negotiates application-level protocols like HTTP/2

While this packet doesn't contain secrets, it tells us what crypto options are on the table, and whether weak ciphers are even being considered.

Packet 6 – Server Hello, Certificate, Server Hello Done

This is the most critical packet for analysis and eventual decryption. It includes:

• Server Hello: Chooses a cipher suite and sends its random value.
• Certificate: The server sends its X.509 certificate, which contains:
• The public RSA key used for key exchange
• Signature and subject details
• Algorithm (e.g., SHA256 with RSA Encryption)

In this PCAP, the certificate is 1472 bytes and includes a public key that will be used by the client to encrypt the pre-master secret.

• Server Hello Done: signals the client proceeds with key exchange.

From this point forward, traffic is encrypted.

Additionally, if we look for files exchanged over HTTP, nothing is seen.

Decrypting the Session

To decrypt TLS 1.2 traffic in this scenario, we will follow five steps:

1. Get Certificate
2. Extract Modulus
3. Get Prime Factors
4. Create Private Key
5. Load key into Wireshark

Note: This only works if the RSA key was generated with poorly chosen or non-random primes—typically the result of outdated crypto libraries, manual key selection, or known RNG failures. Modern 2048- or 4096-bit keys generated with secure randomness remain computationally infeasible to factor. For this demonstration, we use a deliberately weakened key to make the lab reproducible.

Using OpenSSL, we extract the Modulus, convert it into decimal, and factor it using tools like dcode.fr or custom scripts. With p and q recovered we generate a private key.

Once imported into Wireshark, along with the IP and port, the encrypted session traffic becomes readable. This allows us to view plaintext exchanges and even export HTTP objects transmitted during the session.

Automating the Process

For efficiency, we built a proof-of-concept (PoC) Python script that:

• Takes a PCAP and desired key.pem filename as input
• Attempts modulus factorization
• Outputs a usable private key
• Displays IP and port information for decryption

This PoC works only in controlled lab environments. Against securely generated RSA keys, the factoring step fails.

The script can be found here.

Takeaways and Applications

Our demonstration shows how TLS 1.2 traffic can still be decrypted under certain conditions. By analyzing the protocol handshake and leveraging cryptographic weaknesses in RSA key generation and exchange, we were able to reconstruct the session key and decrypt traffic directly within Wireshark.

We learned:

• TLS 1.2 and TLS 1.3 differ fundamentally in how handshake data is exposed.
• How to identify relevant handshake packets and extract the RSA public certificate.
• The process of factoring an RSA modulus to retrieve the private key.
• Use that private key in Wireshark’s RSA keys list (for static RSA ciphersuites) to decrypt TLS 1.2 traffic.
• The continued forensic and offensive relevance of TLS 1.2 traffic in legacy systems and misconfigured servers.

The risk we’ve demonstrated is already exploitable when a server’s RSA key is generated with weak or predictable primes, or if the key has otherwise been compromised. In such cases, TLS 1.2 sessions without forward secrecy are fully decryptable.

While factoring securely generated 2048- or 4096-bit keys is not realistic with current computing power, improvements in cryptanalysis or quantum computing could change that equation in the future.

Looking ahead, the danger will only increase. Breakthroughs in parallel processing and large-scale quantum computing will shorten the time needed to factor RSA keys. For TLS 1.2 sessions without forward secrecy, the consequences would be catastrophic: any adversary who obtains a server’s private key could instantly decrypt all past, present, and future communications recorded using that key.

This risk applies broadly to RSA-based encryption, but within TLS 1.2, where forward secrecy is not guaranteed, the impact is both immediate and absolute.

Want to dive deeper into these concepts? Check out FOR572: Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response.

This blog was co-authored by Abdelrhman Mohamed and Daniel Bissell.