Slew of snafus threaten integrity of SSL/TLS

There’s something of a crisis brewing for secure sockets layer/transport layer security (SSL/TLS), the authentication and encryption standard for the internet, and it's due to general carelessness rather than the NSA trying to break it.

As far as we know, SSL/TLS - or HTTPS as many web users know it - is still secure as a technology, but recent fumbles with the digital certificates that underpin it have shown up its fragility.

Last week, well-known certificate issuer Comodo reported it had issued certificates for banned generic internal resource names such as “mailserver” and private network internet protocol addresses.

Certificates with generic names could be used by attackers to trick users' software into thinking it's communicating with the proper, authenticated system it wants to speak to - when in fact it could be under the attacker’s control.

Comodo only issued eight bad certs, which were revoked as soon as the mistake was discovered.

However, while sorting out the problem, Comodo had a look around and discovered it was far from alone in handing out certificates with generic names and internal IP addresses.

Several other certificate authorities (CAs) have done the same - Comodo found no fewer than 408 bad ones.

The certificates contain names like “exchange2010”, “helpdesk”, “jira”, “analytics”, and “bugzilla”, or vouched-for IP addresses that are not routable on the internet, such as 192.168.238.1.

The list of bad certs include some very trusted entities: government departments, Apple, Vodafone, Microsoft, NASA, Cisco, and even other certificate authorities.

Would we have known about the bad certs without Comodo’s mea culpa? Maybe, but the large number of bad certs points to sloppy practices in the industry.

It follows news that Symantec subsidiary Thawte issued 164 bogus test certificates for existing internet domains. It also issued thousands of fake certificates for bogus domains that had never been registered.

In 2015, we’re supposed to encrypt everything, use SSL/TLS everywhere and put our trust in that little HTTPS padlock icon in browsers.

But it turns out that current certificate issuance policies end up subverting what most users think is a secure session.

In October, security vendor Netcraft noted it was easy for scammers to apply for real certificates for their phishing sites, to give them that “all is safe” padlock icon. 

Certificate issuers Comodo, Cloudflare/Globalsign, Go Daddy and Symantec again were found by Netcraft to have happily issued domain validated certificates to phishers targeting banks, PayPal and other sites.

This is because there are three levels of validation in digital certificates - domain, organisational and extended validation (DV, OV and EV).

Scammers discovered that the first two validation levels are essentially neither here nor there as certificate authorities don’t make enough checks on applicants before handing out the digital bona-fides, sometimes for free.

This is bad, because your average user has no idea about the different levels of trust and will assume that the “westpack.com.au” phishing site goes to a bank server where it’s safe to do business.

There’s an inherent conflict here, between making SSL/TLS security accessible for everyone at low cost and effort because there’s no other option; and preventing such a system from being used as a tool for criminals and spies to defraud users.

However, we can't entirely blame the certificate authorities: it's the way the current certificate system works.

The Linux Foundation-managed Let’s Encrypt free certificate authority - which is sponsored by big names such as Mozilla, Akamai, Cisco, and the Electronic Frontier Foundation - has acknowledged that the problem is not easy to fix.

So what's the solution? The answer involves browser vendors relying on companies such as Microsoft and Google to check site content, and if found to be dodgy, not displaying that padlock to users.

It’s a workaround, but one that depends on Google (and Microsoft et al) getting it right, and quickly before the scammers strike.

Validating content also relies on having access to application programming interfaces from internet giants that monitor site reputation, and there’s the question of how extensible this solution is: can it be used for other applications such as mail and app stores, for instance?

It’s time to start thinking hard about debugging the current digital certificate system, because the ground it’s built upon is increasingly shaky.

We can’t do without SSL/TLS/HTTPS anymore, so we need to make the system a lot more robust.