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.

Thoughts on Infosec, 2014 – first day

I usually post a show report about Infosec somewhere, and for various painful reasons, this year it has to go here. And this year I’m at a bit of a loss.

Normally there’s a theme to the show; the latest buzzword and several companies doing the same thing. I wasn’t able to spend as long as normal there today, thanks to the RMT, but I think it’s probably “Cloud Security” this year. As with “cloud” anything, this is a pretty nebulous term.

Needless to say, the first day of the show lacked the buzz, with a smaller than usual number of visitors, haggared by disrupted journeys, mooched around the booths.

I was a bit surprised to see very little on the “heartbleed bug”, although there were a couple of instances. Either the marketing people didn’t understand it, or had uncharacteristically been put in their places.

One stand that’s always interesting is Bit9, a company after my own heart with alternatives to simple virus scanning. They went on a spending spree earlier in the year and have purchased and integrated Carbon Black. This is technology to allow their customers to monitor exactly what’s happening on all their (Windows) computers; which applications launch with others, what initiates a network connection and so on. It’s all very impressive; a GUI allows you to drill down and see exactly what’s happening in excruciating details. What worries me is the volume of data it’s likely to generate if its being used for IDS. There will be so much it’ll be hard to see the wood for the trees. When I questioned this I was told that software would analyse the “big data”, which is a good theory. It’s one to watch.

Plenty of stands were offering the usual firewalls. Or is that integrated solutions to unified threat management. Nothing has jumped out yet.

At the end of the day there was a very sensible keynote address by Google’s Dr Peter Dickman that was definitely worth a listen. All solid stuff, but from Google’s perspective as an operator of some serious data centre hardware. He pointed out that Google’s own company is run on its cloud services, so they’re going to take care of everyone’s data as they would their own. Apparently they also have an alligator on guard duty at one of their facilities.

I was a bit saddened to see a notice saying that next year’s show will now be in early June and Olympia. I’ve got fond memories of Earls Court going back more than thirty years to the Personal Computer World show. And Earls Court just has better media facilities!

 

Infosec 2014 set to be disrupted by tube strike

It could hardly come at a worse time for Infosec, the UK’s best Information Security show due to take place at Earls Court next week. The RMT is planning a tube strike through the middle of it. Infosec 2014 runs from 29th April to 1st May; the strike runs from the evening before and services aren’t expected to resume until the 1st May. As many exhibitors shut up early on that day and head for home, and the real networking happens in the evenings at the hostelries around Earl’s Court, this is something of a disaster.

On a personal note, the largest outlet for my scribblings on the show in recent years shut up shop at the end of 2013; I’ll be putting the trade stuff in the Extreme Computing newsletter and probably blogging a lot more of it here. If I can get there. I shall try my best, and blog live as the show continues.

Infosec 2013 – First Impressions

I’m here at Infosec 2013 at Earls Court, looking for the latest trends in Information Security. It feels a bit more sober this year, but this could be to do with the number of people turning up on the Tuesday. Hot topics? Well user privilege management seems to be headlining, at least a bit. That’s what the marketing people are aiming their guns at anyway, but it’s too early to tell what the real story will be.

I had a look at the “new” Firebox firewalls. Their big thing is application management, which is, apparently, a big selling point. Rather than just blocking out particular web sites based on URL, they are using signatures on web pages to do the blocking. This approach allows companies, for example, to allow people to access profiles on Facebook but not play games. It’s a good idea, but I don’t see how it can get around the YouTube problem – a mixture of business and entertainment videos (often embedded in supplier and customer web sites) with no obvious way to tell between them. I’ll be taking a closer look.

New at the show is South Korean cyber security company AhnLab. Given my recent comments on the North Korean cyber-warfare claims, they’ll be interesting to talk to.

What’s going on in the cyber-security business-wise? Overseas outsourcing is a recurring theme. Scary!

 

Infosec Europe 2011 – worrying trend

Every Infosec (the Information Security show in London) seems to have have a theme. It’s not planned, it just happens. Last year it was encrypted USB sticks; in 2009 it was firewalls. 2011 was the year of standards.

As usual there were plenty of security related companies touting for business. Most of them claimed to do everything from penetration testing to anti-virus. But the trend seemed to be related to security standards instead of the usual technological silver bullets. Some of the companies were touting their own standards, others offering courses so you could get a piece of paper to comply with a standard, and yet others provided people (with aforementioned paper) to tick boxes for you to prove that you met the standard.

This is bad news. Security has nothing to do with standards; proving security has nothing to do with ticking boxes. Security is moving towards an industry reminiscent of Total Quality Assurance in the1990’s.

One thing I heard a lot was “There is a shortage of 20,000 people in IT security” and the response appears to be to dumb-down enough such that you can put someone on a training course to qualify them as a box-ticker. The people hiring “professionals” such as this won’t care – they’ll have a set of ticked boxes and a certificate that proves that any security breach was “not their fault” as they met the relevant standard.

Let’s hope the industry returns to actual security in 2012 – I’ll might even find merit in the technological fixes.