HTTPS may not be as safe as it once was

A-vulnerability-in-SSLv2-poses-a-big-threat-to-encryption-_459_40117183_0_14121339_300-300x199Proper encryption is seen by many as the linchpin to the Internet’s current and future success. Everything from online banking to private email correspondence needs to be kept out of the hands of cyber criminals, and as such encryption methods were implemented into many of the world’s modern data transfer systems. However, it would appear that HTTPS encryption has a vulnerability that could quickly get out of hand if it isn’t nipped in the bud. 

A new attack strategy dubbed DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) has essentially broken an older form of encryption that many servers still use. The implications of this vulnerability are far-reaching, and show the importance of constant diligence when it comes to cyber security.

How many servers are at risk?

In order for a server to be vulnerable, it has to either support SSLv2 requests or use a private key that links up with another system that supports SSLv2. All told, one of these two conditions can be attributed to around 17 percent of HTTPS servers.

While that may not seem like much, it also doesn’t take into account key reuse. Recycling keys allows for a more efficient system, but it also opens servers up to a DROWN attack simply due to the probability of communicating with a server that supports SSLv2. Once this variable is accounted for, the number of vulnerable HTTPS servers jumps to 33 percent.

This is why the DROWN attack is such a huge problem for current cyber security measures. A system with an incredibly sophisticated encryption protocol can still be compromised if it communicated with a server that supports SSLv2.

What does this say about open source?

The reason that hackers were able to discover vulnerabilities in SSLv2 had to do with the fact that the protocol is contained within the OpenSSL software library. SSLv2 is open sourced, which means anyone can look at the source code and tool around with it. This is great for educational purposes, as it allows encryption experts to comb through lines of code to help plug holes. However, it also means more nefarious individuals get the chance to root around and discover vulnerabilities they could then exploit.

A great example of open source gone awry is the Heartbleed vulnerability found in SSL-TLS encryption. Trend Micro security experts have spent a good deal of time analyzing this exploitation and have concluded it to be a major problem. Heartbleed also relied on the open sourced nature of OpenSSL, with hackers utilizing bugs in vulnerable versions of encryption software to access a system’s memory. If done correctly, this allowed the cyber criminal to gain access to logins and passwords contained on the server.

However, the worst part of this whole debacle was that Heartbleed gave hackers the ability to intercept encryption keys, thereby granting the capability to decrypt traffic. The fact that this whole transaction doesn’t even leave a trace only compounds an already frightening situation, and goes to show that completely open sourcing encryption methods may not be the best idea.

Open source is a fantastic educational too, but it needs to be done with hackers in mind. Auditing the content given to the public is an absolute necessity when it comes to encryption. Heartbleed and the more recent DROWN attacks show in no uncertain terms that letting hackers review a piece of software can only end in the discovery of exploitations.

What can IT administrators do?

Although the entirety of this situation may seem overwhelming, there is an extremely straightforward way to mitigate the risks of a DROWN attack on encryption within your system: don’t support SSLv2. This protocol is old and obviously broken, and as such administrators need to recognize what kind of risk they run if they decide to support it. Users of OpenSSL 1.0.2 and OpenSSL 1.0.1 should upgrade to 1.0.2g and 1.0.1s., respectively.

What’s more, IT officials need to make sure that keys aren’t reused by servers that once supported SSLv2. This runs the risk of using a key that has already been compromised by a hacker, therefore defeating the purpose of using newer forms of encryption. There are obviously certain advantages to reusing keys within a system, but the ever-present possibility of a cyberattack is infinitely more pertinent than any of them. As such, it’s best to simply avoid the problem altogether and stick to completely unique keys.

Encryption is too important to simply hand the keys over to cyber criminals and other nefarious parties. Server administrators need to take an active role in defeating techniques like DROWN in order to cut the problem off at the source.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.