STARTTLS is not a protocol

As regular readers will know, I’m not a fan of STARTTLS but today I realised that some people are confused as to what it even means. And there’s a perfectly good reason for this – some graphical email software is actually listing STARTTLS as a protocol for talking to mail servers and people are jumping to conclusions.

So what is STARTTLS all about if you go back to basics?

Originally, when only nice people had access to computers, network traffic was unencrypted. If you had physical access to the network you could pretty much read anything you wanted to, as everything connected to the same network saw the same data. This isn’t true now, but encryption you data is a good idea just in case it can be intercepted – and if it’s going over the Internet that’s definitely the case.

In the mid 1990s, the original mass-market web browser, Netscape, decided to do something about it and they (or more specifically their chief scientist Taher Elgamal, invented a protocol called Secure Sockets Layer (SSL) to protect HTTP (web) traffic. Actually, several times as the first couple of attempts weren’t very secure at all.

SSL didn’t really fit in with the OSI model; it runs on top of the transport protocol (usually TCP) but under the presentation layer, which would logically handle encryption but doesn’t usually. To use it you need an SSL layer added to the stack to transparently do the deed on a particular port.

But, as a solution to the encryption problem, SSL took off and pretty much every major protocol has an SSL port along with its original cleartext one. So clear HTTP is on port 80, HTTPS is on port 443. Clear POP3 is on port 110, encrypted on 995. Clear IMAP is on port 143, encrypted on 993.

As is the way of genius ideas in cybersecurity, even the third version of SSL was found to be full of holes. SSL version 3.1, which was renamed TLS, continued plugging the leaks and by TLS 1.2 it’s considered pretty much secure now. TLS 1.3, which interoperates with TLS 1.2, simply deprecates certain cyphers and hashes on the suspicion they might be insecure; although anyone into cybersecurity should tell you that everything is secure only until it’s broken.

Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post

Unfortunately, because different levels of TLS use different cyphers and reject others, TLS levels are by no means interoperable. And neither is it the case that a newer version is more secure; bugs have been introduced and later fixed. This’d be fine if everything and everyone used the same version of TLS, but in the real world this isn’t practical – old hardware, in particular, bakes in old versions of SSL or TLS and if you decided to deprecate older cyphers and not work with them, you loose the ability to talk to your hardware.

But apart from this, things were going along pretty well; and then someone had the bright idea of operating encrypted and unencrypted connections on the same port by hacking it at the application layer instead. This was achieved by modifying the application protocol to include a STARTTLS command. If this is received, the application then negotiates a TLS connection. If the receiving host didn’t understand what STARTTLS meant it’d send back and error, and things could continue unencrypted.

In other words, if you’re implementing an SMTP server with STARTTLS, this keyword is added to the protocol and the SMTP server does something about it when it sees it.

What could go wrong?

Well quite a lot of things, actually. Because TLS doesn’t fit in to the OSI model, it’s actually very difficult to deal with the situation where a TLS connection is requested and agreed to but the TLS layer fails to agree on a cypher with an older or newer version on the other end. There’s no mechanism for passing this to the application to say “okay, let’s revert to Plan A”, and the connection tends to hang.

There’s also a problem with name-based virtual servers must all use the same host certificate because the TLS connection must be established before the application layer headers are transferred.

But perhaps my biggest gripe is that enabling STARTTLS makes encryption optional. You’re not enforcing encryption when you need to, and even if you think you are, STARTTLS connection are obviously vulnerable to a man-in-the-middle attack. You have no idea how many times TLS has been turned on and off between the two endpoints.

You might be tempted to think that optional encryption is better than none at all, but in reality it means you don’t care – and if you don’t care, don’t bother. It just leads to a false sense of security. And it can lead to interoperability problems. My advice is to use “always TLS” ports for sensitive data and turn off the old port.

Freeloaders step in to fund Open Source thanks to OpenSSL fiasco





Some good has come out of the heartbleed bug – some of the larger organisations using it have decided to put some money in to its developemnt. Quite a lot in fact. it’s through an initiative of the Linux Foundation, and is supported by the likes of Microsoft, Cisco, Amazon, Intel, Facebook, Google and IBM. The idea is to fund some critical open source projects.

While this is welcome news for the open source community in general, and certainly vindicates the concept, I have to question its effectiveness. The vulnerability was actually reported by the community two years ago, and had already been fixed. However, it persisted in several releases until it had been. One could blame the volunteers who developed it for sloppy coding; not spotting it themselves and not fixing it when it was pointed out to them earlier. But I can’t blame volunteers.

It’s up to people using Open Source to check its fit for purpose. They should have carried out their own code reviews anyway. At the very least, they should have read the bug reports, which would have told them that these versions were dodgy. Yet none of them did, relying on the community to make sure everything was alright.

I dare say that the code in OpenSSL, and other community projects, is at last as good as much of the commercially written stuff. And on that basis alone, it’s good to see the freeloading users splashing a bit bit of cash.

I wonder, however, what will happen when Samba (for example) comes under the spotlight. Is Microsoft really going to fund an open-source competitor to its server platform? Or vmware pay to check the security of VirtualBox? Oracle isn’t on the current list of donors, incidentally, but they’re doing more than anyone to support the open source model already.

Heartbleed bug not as widespread as thought

Having tested a few servers I’m involved with, many of which are using old or very old versions of OpenSSL, I can’t say I’ve found many with the problem. You can test a server here: http://filippo.io/Heartbleed/ on a site recommended by Bruce Schneier.

So what’s going on? Does this affect very specific nearly-new releases. This story could turn out to be a serious but solvable problem, and a media panic. I recall spending most of 1999 doing interviews on how the “year 2000 bug” was going to be a damp squib, but it’s early days yet.

Heartbleed bug

Someone’s finally found a serious bug in OpenSSL. It allows a remote attacker to snoop around in the processes memory, and this is seriously bad news because this is where you will find the private keys its using. They’re called “private keys” because, unlike public keys, they need to remain private.

This is going to affect most web sites using https, and secure email (if you’re using it – most aren’t). But before user’s rush off to change their passwords (which are different for each site, aren’t they?) – there’s no point in doing this if an attacker is watching. The popular press reckons your passwords are compromised; I don’t. If I understand it correctly, this exploit theoretically allows an attacker to intercept encrypted traffic by pretending to be someone else, and in doing so can read everything you send – including your password. So don’t log in until the server is fixed. They can’t read your password until you use it.

To cure this bug you need a new version of OpenSSL, which is going to be a complete PITA for server operators who aren’t on-site. Hell, it’ll be a PITA even if you are on-site with the servers. Once this is done you’ll also need new certificates, and the certificate authorities aren’t geared up for everyone in the world changing at once.

But the big fun one is when you can’t update OpenSSL. It’s used everywhere, including in embedded systems for which there was never any upgrade route. I’m talking routers, smart TVs – everythign.

I believe that SSH isn’t affected by this, which is one good thing, but I’m waiting for confirmation. Watch this space.

But, if you’re using a secure web site to log in over SSL, consider the password compromised if you’ve used it in the last few days and be prepared to change it soon.

FreeBSD 8.4 released today

FreeBSD 8.4 has just been released. But I thought we were up to 9.1? Actually version 8 is still being maintained for those who don’t want to change too much in one go, as is the way for FreeBSD.

FreeBSD Logo
FreeBSD 8.4 released

Given this conservatism, why bother upgrading from 8.3 to 8.4? If you want the latest, why not go straight to  9.1; otherwise be conservative and leave well alone? This time I might upgrade, because 8.4 contains fixed versions of BIND and OpenSSL. Certain high-profile DDoS attacks amplified by a feature of BIND are a good enough reason to suggest everyone keeps up with the latest BIND release.

You could, of course, update BIND and OpenSSL by just pulling them from the repository but there are a number of other good bug fixes in there anyway, especially in several on the Ethernet drivers. And ZFS has been improved, if you want crazy disks.

I’m not expecting 9.2 to show up until early next year, if convention holds, which is a pity because some of the BIND and OpenSSL problems were found after 9.1 was released. Don’t wait until January, apply the patches now! (Follow the links above).