If you host your own websites and you need to provide some level of encryption for the communications that pass between the server and a connected user, there’s a really good chance that you already know quite a bit about Secure Sockets Layer (SSL) technology.
SSL has been around for a very long time, and it has become the standard term that lay people use when talking about any kind of encrypted internet communications, even when SSL is not in play. In fact only a tiny percentage of encrypted internet communications are still using SSL, and the majority have moved forward to a new technology called Transport Layer Security (TLS). Even so, the total global internet population is massive, so the tiny percentage of connections still using SSL could potentially add up to millions of individual connections per day.
The final update of SSL was SSL3, and this was found to be an inherently vulnerable protocol, and if you already heard about that, it’s probably had you a bit worried. We’d like to take a moment to tell you more about what’s going on with SSL3, and what it could mean for you.
What exactly is the problem with SSL3?
Yes, it’s true that SSL is vulnerable to exploit. Before you hit the panic button and break out your tinfoil hat, consider that all encryption technologies are vulnerable. It’s just that some technologies are more vulnerable than others.
When data is sent over the internet, it is not all sent as one continuous stream. It gets split into chunks called “packets”. This makes the data transmission very efficient, because the packets can be routed through multiple different pathways simultaneously to reach their destination. Those little packets of data don’t always arrive safely at their destination, but when this happens the recipient computer detects that there are missing packets and simply requests new copies of those packets from the sender. There are two main types of packets used for internet communications, called UDP and TCP
SSL (and TLS) adds encryption to each packet so that if they’re intercepted, it’s going to take a lot of work for somebody to be able to retrieve any meaningful data from them. Without that encryption, the data has no protection at all.
In this world there are some people who are very naughty. Every year they wake up on Christmas morning to find their stocking filled with coal, and I guess this must make them even more mad at the world, so they do even more bad things. That means things like creating packet sniffing software that seeks out packets containing the kind of data that would be interesting for them.
Packet sniffing is quite hard work and requires sorting through a lot of useless packets, but there will always be some packets of significant interest, mainly because administrators nearly always send passwords in unencrypted emails (because few ordinary computer users understand why or how to use encryption), and most users never change their administrator assigned passwords. Incidentally, this is why you should always let users create their own passwords at sign-up, as it avoids the need for transmitting a password in plain text.
A huge number of websites also allow users to log in on ordinary http connections,, instead of requiring a secure connection. How easy or difficult it would be to obtain a password this way depends on the length of the password string and how patient the attacker is.
These kinds of attacks are called Man In The Middle (MITM) attacks. There are plenty of them around, but the one that put the final nail in the coffin of SSL3 was the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. POODLE was interesting because it allows attackers to insert things into unused bytes in a packet (padding). TLS is not vulnerable to POODLE attacks (but it might be vulnerable to something else). It is therefore preferable for all connections to use TLS when possible.
Should you worry about POODLE attacks?
Yeah. You should worry about any kind of attack. The clue is right there in the word “attack”. But you don’t need to worry about it in the same sense that you would worry about leaving the iron on when you’ve just left home for a three day road trip. There are no reported instances of POODLE ever having been used outside of a controlled environment to capture information, and the most likely explanation for this is that it’s simply not worth the effort required.
Think about it this way: Every day thousands of users willingly submit their information to successful phishing attacks. Phishing is low tech, almost effortless, and hugely successful. Why would somebody go to the trouble of handcrafting an elaborate firearm if hitting you on the head with an old stick will achieve the same result?
If a POODLE attack were ever to be seriously implemented, it would be going after a specific high level target, and it’s a lot of work to do something like that. An average attacker with only the intention to steal money doesn’t need to go to all that trouble just yet. A super-spy out to steal state secrets, well that’s a whole different scenario.
Regardless of whether you’re the CIA, a bank, or just running a simple online shop, it doesn’t mean you can afford to be complacent about the possibility of any kind of known attack, especially if it is one you can guard against, as will be explained in a moment.
Should you just completely disable SSL3 on the server?
This is a question that has stirred up considerable debate among people who care about this kind of thing. Organizations with a strong sales focus will argue vehemently against disabling any kind of legacy support because it cuts off a considerable (and wealthy) portion of the market. Older people tend to resist upgrading systems that have always seemed reliable to them, and they are usually the ones with the most money to burn and the least reason not to burn it.
Organizations with a strong security focus, on the other hand, offer the equally valid argument that enabling legacy support encourages users to use insecure systems that place them at risk.
Looking at it from a strictly legal point-of-view, the latter group are probably right because ultimately you will be in the frame if anything should go amiss. POODLE attacks are directed at the client, not the server, but if a client suffers a loss because your server allowed them to make an insecure connection, there’s really nothing to stop them from suing you, even if you have some sort of fancy disclaimer buried in your T&C. For that reason, if you use HTTPS for anything other than site identification, it is probably best to disable SSL3 entirely.
It could be argued that as a provider of a service, you have a responsibility to take care of the safety of people who visit your site, much in the same way that shopping mall owners need to make sure their floors are not too slippery.
As a user, how can I disable SSL3 in my browser?
It’s a really good idea to do that, but in modern browsers it may not be necessary, as some will have it disabled by default. Older browser versions may require manual configuration changes.
Anyone would reasonably expect that with Google’s strong focus on meeting the needs of users, they’d have made it easy to tweak every possible feature in Chrome you might want to tweak. Actually it is not at all easy to make significant changes to Chrome. Disabling SSL3 in Chrome requires adding a switch to the application launch instruction, as follows: –-ssl-version-min=tls1
With Firefox, it is much simpler to disable SSL3 permanently without having to mess around changing the application launch settings. You start with about:config in the URL bar.
Accept the warning if one is offered.
Do a search for TLS.
Change the value of the key security.tls.version.min from 0 to 1.
This means you won’t accept a connection with anything less than TLS1, so attempts by a server to establish an SSL3 connection will be rejected. Firefox makes everything so easy that you have nothing further to do except closing the tab.
Simple method, stop using it unless you really have to. More complex method, go to Start → Internet Options → Advanced and uncheck Use SSL3.0.
Ensure all the latest security patches are downloaded and installed on your Mac system. SSL3 will be disabled by default.
You’re on your own. Good luck!
After disabling SSL3 on my server and in my browser, will I be safe?
Of course not. There are just two choices:
- Be connected to the online world; or
- Be safe
There are no shades in between these two extremes.
header image courtesy of Alex Vinogradov