To read the original post, click here.
Did you know that an obsolete security protocol developed waaaay back in 1996 is still in use today– and it can make your data vulnerable to a cyberattack?
In this Q&A article, you’ll learn why the original cryptographic protocol used in Netscape back in 1996 still matters today, how a design flaw can put your current data at risk, and what you can do to help keep your information secure.
What is SSL?
Security protocols are used every day on the Internet to make sure your data is secure (confidential, unmodified, and trustworthy). Secure Socket Layer (SSL) is the first secure protocol used in the original web browser: Netscape. The purpose of SSL is to provide a mechanism by which a user can access a webpage and be sure that the communication is both trusted and confidential. Version 3.0 was created in 1996.
However, there were some problems with SSL. It involved into a new protocol, called Transport Layer Security (TLS), in 1999. TLS provides a way for web servers to support older web browsers by changing (or downgrading) the security protocol from the new TTL to the older SSL protocol. Since SSL evolved into TLS, we often use one term to describe the other. The evolution of the SSL/TLS protocol looks like this:
SSL 2.0 → SSL 3.0 →TLS 1.0 →TLS 1.1 →TLS 1.2
Why is SSL 3.0 bad?
On October 14, 2014, two Google researchers discovered a new way to defeat the protection provided by SSL ((LINK: https://www.openssl.org/~bodo/ssl-poodle.pdf )). They called this vulnerability POODLE.
Can I patch this vulnerability?
No, there is no patch. The protocol has a design flaw, and the only fix is to stop using SSL 3.0 on browsers and web servers.
There is an optional protocol extension called TLS_FALLBACK_SCSV, but both the client and server must use it. Additionally, not all browsers support this extension; therefore, even if you configure your server to use it, there is no guarantee that the browser will support it. You cannot depend on this extension.
How bad is this problem?
The attack requires the attacker to both intercept your traffic and inject new traffic. This requires either malware on your computer or an untrusted network connection (such as a public WiFi connection). Although difficult, skilled hackers can do this, and for around $100, an unskilled hacker can buy a commercial device that makes this attack easier to perform.
When an attack is successful, your “secure” communication is no longer secure. It can be intercepted and modified. If you were to connect to your bank, your account information, passwords, etc., could all be seen and modified.
But my browser normally supports TLS. Won’t this protect me?
No. Normally the TLS protocol will check to see if both parties can agree to use TLS instead of SSL, but an attacker can intercept and modify the communication (this type of attack is called Man in the Middle, or MITM) and claim that SSL must be used. Once the two computers “agree” to downgrade (i.e., choose to use a weaker, older protocol) to SSL3, the POODLE attack can be used to intercept and modify all secure communications.
As long as both the server and your browser support SSL, you cannot assume that your connection is secure.
What should I do?
To protect yourself, you should configure your browser to stop using SSL.
If you have a server, you can protect your clients by disabling SSL. For instructions on how to do that, this link ((LINK: http://disablessl3.com/ )) provides a nice guide.
What will break if I have a web server and I disable SSL?
You should not notice any problems. Nearly all browsers support TLS.
The only people who will be affected are those who use Internet Explorer (IE) version 6, or Opera version 4.0. These are the only browsers that do not support TLS. According to this page, the percentage of people who use IE6 is less than 0.3% ((LINK: http://www.w3schools.com/browsers/browsers_explorer.asp )).
The only users who must use IE6 are those running Windows XP, which received its last service pack in 2008. It is no longer maintained, unless you purchased an extended support contract for obsolete software from Microsoft. In other words, it is highly unlikely (0.3%) that your customers will notice any problem if you disable SSL 3.0 on your servers.
Does this affect only web servers and web browsers?
Sadly, no. Many companies allow clients to connect to their systems using a VPN (Virtual Private Network). This VPN creates a secure connection over the Internet from the client’s machine to the customer’s network. Some of these VPN servers use SSL/TLS. And that means the “secure” VPN connection is vulnerable to security attacks.
I’m still not sure I should disable SSL3.
If you do nothing at all, SSL3 will stop working. That’s because vendors are removing support for SSL3 from their products. Some examples include:
So TLS 1.0 is okay?
Well, that’s another problem. In December 2014, it was discovered that TLS 1.0 was also vulnerable to the POODLE attack. ((LINK: https://www.imperialviolet.org/2014/12/08/poodleagain.html)) This was an implementation error that browsers could be patched to address, but TLS 1.0 is still vulnerable to attacks from skilled hackers.
Ideally, the latest and greatest version of TLS should be used, but this cannot be done until every one of your clients’ browsers have upgraded to support TLS 1.1 and 1.2.
As of February 2013, contemporary browsers (Chrome v20+, IE v8+, Opera v10+, and Safari v5+) support TLS 1.1 and TLS 1.2. However, Windows 7 and 8 users who use IE version 10 or lower do not have TLS 1.1 and TLS 1.2 by default. Therefore, we do not recommend at this time that TLS 1.0 be disabled on a server, unless you know that your users’ browsers will not be affected.
In short, a surprising number of web servers still use SSL 3.0. Stop using SSL 3.0! It’s not secure, and it’s not needed.
Links in this article are provided because they have information that may be useful. NYSTEC does not warrant the accuracy of any information contained in the links and neither endorses nor intends to promote the advertising of the resources listed herein. The opinions and statements contained in such resources are those of the author and do not necessarily represent the opinions of NYSTEC.