Hackers presumed to be from Iran compromised internet security earlier this month, but it’s not a meltdown, as one analysis put it. It does though highlight a dirty little secret: the most common method for authenticating secure internet links has fatal flaws.
The attack was against the encryption technology used every time you create a secure web connection, say from your web browser to internet banking. These technologies, Transport Layer Security (TLS) and its predecessor Sockets Layer (SSL), put the “s” for “secure” in the https of a web address. They make the little padlock icon appear.
A core part of this technology is about authentication. When you open that secure connection to your bank’s website, how do you know it’s not an impostor? How do you know someone hasn’t inserted themselves into the secure link to conduct a man in the middle attack?
The answer? Secure websites identify themselves with a digital certificate, usually called an SSL certificate, issued by trusted third parties called Certification Authorities (CA). In effect the CA countersigns the identity offered by the bank’s server and says, “Yes, you are genuinely connected to your bank. It is safe to proceed.” Except that is uses a bunch of brain-wrenching mathematics called a digital signature.
Each CA has a digital certificate too, to prove its identity, counter-signed by a higher-level, more-trustworthy CA. At the top are the most-trusted “root CAs”. Your web browser trusts those because it’s programmed to do so.
All this trust is fragile. We trust commercial CAs because they’d be out of business if proven untrustworthy. We trust government CAs because they implement government-grade security. In theory.
But our presumed-Iranian hackers gained access to a CA — Comodo in New Jersey — using a valid username and password for one of their regional affiliates. Once in, they started issuing fake SSL certificates, bypassing the usual human checks — nine in all before they were caught, including domains belonging to Google, Yahoo, Skype, Microsoft’s Live service that includes Hotmail, and the Mozilla organisation that makes the Firefox web browser.
Comodo’s analysis says only one fake certificate was seen live on the internet on a computer in Iran, login.yahoo.com, and then only for a short time.
To make use of the fake certificates, the hackers would have needed to set up a fake server and somehow gotten users connecting to it even though they’d typed the correct web address. That means subverting the domain name system (DNS) that translates domains such as login.yahoo.com into numerical internet (IP) addresses. Easy to do within your own networks, or within Iran where internet infrastructure is tightly controlled. It’s more difficult to draw in traffic from elsewhere.
While this attack seems unlikely to have had a significant effect, it has reminded us of the SSL certificate system’s weaknesses.
CAs are assumed to be trustworthy, yet some are run on the cheap. Low-end CAs sell certificates for as little as $23, which doesn’t buy much security or cross-checking that the buyer is genuine. Many CAs send out new certificates by unencrypted email, where they could be intercepted and copied.
Other CAs are just dodgy. Just one example is Etisalat, a company in the United Arab Emirates that has copies of those root CA master keys even though it has been caught planting spyware on BlackBerry devices.
There is a system for revoking fake and other invalid certificates, namely revocation notices from CAs, but it’s broken. Web browsers generally don’t check the revocation lists automatically, but rely on the vendor’s regular software updates. That can take weeks.
Ars Technica isn’t the only publication calling into question this entire fragile system. And not before time.
Different browsers default the CRL check differently – Chrome has server on, IE (9) has server on, publisher off…
@Meski: Yeah I decided not to dig too far down into the specifics for an article for a general audience. It’s good to see the newer browsers being better-behaved about this stuff.
Someone else has also just told me that stealing the SSL certificate from an unencrypted email won’t get you very far without the real server’s private encryption key, that one that was used to create the certificate signing request. True. But I’ve also seen certain web hosting environments send that private key in unencrypted email — which is really stupid.
:)))) What a stupid CA would that be to send both the public key and the private key through one channel. This is the very most basic thing that every computer science student would learn in his/her first course of cryptography, when we are talking about public and private keys. Seems like that these people have to go to school once again and pass their exams!!!