Corporate Blog

The maintenance to protect against the “POODLE” exploit has been finished, as we’ve noted on our status blog. While I’d like this to be a short post stating just that, like the maintenance itself, there is more to it than meets the eye.

What was anticipated to take about an hour during a scheduled weekend maintenance window ended up taking much longer as we waded through the pros and cons of configuring some or all services to disable SSL version 3. (Of course, very few people know about and can prepare for these things in advance.) First, there was some debate in information security circles about just how serious this issue was/is, how quickly it needed to be addressed, and by whom. In short, some took it more seriously than others, but there was general agreement that other issues (Heartbleed and Shellshock, for example) were much bigger. Those that didn’t feel it was that serious had their reasons, but we’re not in business to gamble with your security.

While this is a vulnerability in a protocol (SSL version 3) that is (or has been) used to secure different types of connections, the main area of concern was with HTTPS connections — i.e., web browsing. To my knowledge, the only known exploit of this protocol vulnerability uses JavaScript, and only over HTTPS connections. In other words, there is currently no known issue with using SSLv3 to secure non-HTTPS connections — e.g., email.

To that end SSLv3 will still work on some of our mail servers. How this is handled — if your email program can’t use TLS — differs between email programs, with some email clients failing silently and establishing a non-secure connection instead, and some failing completely to connect. We expect that most email programs using our existing suggested configurations will continue to work across all of our servers. However, while we have not had any reports of issues from clients, one of the reasons this took longer than anticipated was the surprising number of current or recent email clients that stopped working when we disabled SSLv3 on the mail servers. Connections by email clients configured to use SSLv3 still work on server NC018, while on NC027 they will fail silently as described above. This is related to the differing behaviour of the software running these two mail servers.

All web servers (including control panels) were configured to deny SSLv3 connections by Monday this week. Web browser developers seem to have kept up with and done a better job implementing TLS in current versions than some email client developers. As we’ve stated several times previously, Outlook 2003 should be relegated to the past, along with Microsoft Internet Explorer version 6. The latter uses only SSL (and has TLS disabled) by default. Microsoft, of all people, have actually had an active campaign to discourage the use of MSIE 6 since 2009 with their ie6countdown.com website; according to that website, only 3.3% of users worldwide are still using MSIE 6, and about three quarters of them are in China. Put it this way, using MSIE 6 today is like trying to drive a Model T Ford on modern roads among modern cars, expecting to go as fast as modern cars and to be serviced by modern mechanics. In short, using certain software today is simply a bad idea, even if it still appears to some people to work.

Another thing I’d like to address here is the difference between SSL (secure sockets layer) and TLS (transport layer security) … or, more correctly, the perceived difference. There is no difference. They are essentially the same thing. For all intents and purposes, the lay person can consider TLS version 1.0 to be SSL version 4.0. That’s not true from a technical standpoint, but as someone who deals every day with clients who just want their computers to work and are more concerned about the intricacies of their trucking business (for example), they do the same thing: encrypt your Internet connections. TLS, as the successor to SSL, is newer and better (as the “SSL version 4.0” comparison above makes clear), and you should use TLS in preference to SSL any time you have a choice.

Finally, a word about email security. It has become more and more clear to me over the years that the trend in software development is to hide things from the average user. There is a point to which this is good; after all, if you had to type in all of the commands that your email program (for example) uses to connect to the mail server to download or send your email, you might as well write a letter with a quill and ink and send it via carrier pigeon. However, if your email program is going to fail silently and send your message in the clear — i.e., over an unencrypted connection — that’s something you probably want to know about if you thought you were using an encrypted connection. But this is not something you will read about in glossy brochures extolling the virtues of this email program or that. The fact is, most people will never be aware of such an issue, and those that have the most to fear — for example, people living in or reporting on dictatorships — will only realise they have a problem when there is that ominous knock at the door that reveals their communications have been compromised.

For this reason it is not enough to rely on your email service provider — not even NinerNet Communications — to secure your communications if you are, for example, an activist in a police state or a reporter with confidential sources. No, you have to take that responsibility on yourself by encrypting the actual messages you send before you send them. How to do this is certainly beyond the scope of this post, and even if you were to do it it may not be necessary for all of your communications. But going to this extent to protect yourself in this way takes extra time and effort and may require additional software on your computer, but at the end of the day you need to determine for yourself the pros and cons in your own cost-benefit analysis.