SSL & TLS Attacks for the Layman – MITM Downgrade Attacks

Posted by Arvind Doraiswamy on February 7, 2017 at 10:24 AM

In this five part blog series, I've been focusing on covering some of the attacks that have exploited various features in the SSL/TLS mechanism. We've covered general bad practices, bad implementation, oracles, and repeated plain text. Today we'll be discussing MITM Downgrade Attacks.


This targets the fact that clients and servers for some re export-grade cryptography. This simply means that encrypting your communication with ciphers that are not very strong and can easily be decrypted. By default browsers don't use these ciphers, but the negotiation is in plain text so an attacker can see what ciphers are being chosen.

Because of this bug, a man-in-the-middle attacker canhijack the negotiation process and tell a vulnerable client to use export-grade RSA (i.e. 512-bit key which isn't strong despite it looking that way) to encrypt all traffic until the symmetric key is decided. Remember, SSL uses public key (asymmetric) crypto to start off, decides a secret and then uses this secret to encrypt further traffic (symmetric). Since the public key exchange is using export-grade RSA, an attacker can break this (factorization problem - not brute force) and retrieve the decryption key being used. Here's a brief overview article and really nice article with a bit more detail on the same. Once this key is retrieved, the attacker can decrypt traffic that passes on the symmetric key and decrypt everything for that session between the client and the server.

Conducting the "breaking," which really is solving RSA for manageable numbers, is a time-consuming endeavor. If you had to do it per-SSL-session, it would still be a bug but less practical. However, servers reuse a single export-grade RSA key when they start up and until they are shut down. So, if an attacker manages to get one decryption key, they can get potentially capture traffic and decrypt it successfully for many sessions.

The fix is to make sure that no one ever uses export-grade ciphers.


This is similar to FREAK because it targets the same fact that export-grade Diffie-Hellman (DH)ciphers are supported by clients and servers. However, it attacks Diffie-Hellman, another public key encryption algorithm, instead of RSA.

DH is safe because it is hard to solve the discrete logarithmic problem and get back the initial numbers (exponents) chosen at the start. If those numbers can be predicted or obtained somehow DH is breakable. But the fact remains that it is very hard to do.

The researchers who found LogJam though, did something creative. To understand, let's use an analogy. Think of a 25-character password stored as a one-way hash. If you wanted to crack the hash using brute force it would be very difficult and you would need lots of power and time. But if you built (offline) something called a rainbow table, which had every single possible hash for any 25-character long password, things change. The next time you get a password hash all you have to do is look up the 25-character password in that table up.

Back to Diffie-Hellman. The researchers basically precomputed the discrete logarithm for 512 bit prime numbers. Meaning, the next time they saw DH being used with 512 bit primes they'd know what exponents were being used, and hence find out the actual symmetric key being used inside. And as it turns out, a lot of servers use the exact same prime number. So, if you solve it once, you've potentially compromised all connections to those servers.

Additionally, servers still support export grade DH ciphers. This fact and the rainbow table wizardry is what LogJam is about. A man-in-the-middle attacker will downgrade a connection, force the connection to use 512-bit DH, and then use the rainbow table to find the secrets.

The mitigation is to think of all the possible services on your servers that use Diffie-Hellman. Once identified, ensure they are all configured correctly--namely disable export-grade DH cipher suites and ensure that 2048-bit primes are used to compute the shared secret. On the client side, stay updated, use newer browsers and hope that browsers reject connections that use export-grade DH.

Topics: developer guidance, crypto

Arvind Doraiswamy

Written by Arvind Doraiswamy

Arvind is a Senior Security Engineer who focuses on conducting security assessments for clients, contributing articles to our secure coding knowledgebase, and writing tools to improve our company's security testing efficiency for clients.