Preventing your servers from downgrade attacks

One of the coolest attacks is forcing a downgrade between the client and server, making the server believe that client has support only for older and insecure versions of your protocol. This works with Windows’ NTLM authentication and with SSL, mostly.

How does ‘downgrade attack’ work?

Downgrade attacks are born from a misconfiguration and takes place within MITM attacks. Privilege is escalated by trapping the connection request and thus forcing the use of an older protocol version with known security issues by faking the client-side accepted protocol versions. Then the weak protocol is attacked and access is escalated.

Some softwares like Cain (for Windows) can perform both attacks (ARP Poisoning + NTLM Downgrade). Cain can also spoof the challenge in order to make the cracking easier.

Why support old protocols?

You may have old clients in your network or software with limited functionality. What I say? Dump them. If you have to open a hole into your setup to accomodate something, you are doing it wrong! There’s almost no control about a MITM attack due protocol’s weakness, since everything is spoofed. It’s better clarify your client of the risks he’s assuming on doing that.

What are the chances?

There’s no way to do remote ARP poisoning because ARP packets are not sent through routers but it can be easely done from inside. Internal fraud can be done though MITM attacks and paired with a downgrade attack can leverage session hijacking on local servers.

How to stop the downgrade?

Simply configure your software to accept only the latest (or at least the latest without serious flaws) protocol versions.


OpenSSL accepted protocol’s configuration is commonly done in application level.

Apache’s mod_ssl

To disable SSLv2 (unsecure) under apache and keep only the good encryption types, configure your httpd.conf (or apache2.conf — depends on distro) to the following:

SSLProtocol -ALL +TLSv1


Stunnel supports protocols since SSLv2 through latest TLS versions but you can ensure the protocol version with the following:

sslVersion = TLSv1 TLSv1.1 TLSv1.2


I’ve heard that some newer versions of JVM doesn’t even accept SSLv2, but you can use TLSv1 or SSLv3. Do not use SSLv3 since it’s vulnerable to the POODLE attack.

Just add the following to your connector configuration:

               <Connector port="443" ...
               scheme="https" secure="true"
               ..." />

There are more configuration required for SSL’ing on Tomcat. For this, please visit this reference.

I’ve used SSLv3 on examples because it’s the version in widest use but TLSv1 is also recommended.Use TLSv1 only! SSLv3 has proven to be vulnerable to attacks (i.e. POODLE).


Just configure your servers to accept SSH2. The default is to accept SSH1 and SSH2 so this is a must-have configuration since SSH1 is weak.

Protocol 2

That’s all! If you are using something to make your connection secure, make sure that this “something” is also secure!

I’ll be writing more about MITM attack along the week.


comments powered by Disqus