The answer is a hierarchical system of trust relationships called the Public Key Infrastructure. The PKI provides websites that wish to communicate secure information a “Certificate” that basically means, “We know ’em. He’s cool.” When your browser attempts to access a site using SSL, it is handed this Certificate, inspects said Certificate and decides whether or not to trust the site. If it does, the browser will begin encrypting any traffic to this server with the information contained within the Certificate. If it does not, you get the nastygram shown in the image up there at the top of this post.
You may also have noticed that modern browsers often have a big color-code icon in the URL bar at the top of your browser when you’re on an SSL site. A green icon tells you that the owner of the Certificate is valid, that they are also the owner of the website and that the Certificate itself is valid. A red icon tells you the browser cannot vouch for the safety of the Certificate, either because its unsigned (often the case with small test website, for example) or because the ownership of the Cert and the site do not match.
Certificates use the Public Key Infrastructure (PKI)
How is the Public Key Infrastructure supposed to keep encryption keys secure? Well, its a bit of a “friend of a friend,” kind of thing.
Entities called Certificate Authorities (CA) are recognized throughout the industry as trusted parties from which information about other Certificate holders can be requested. The Certificate holder might be a website for your bank, or it might be another Certificate Authority. Thus if you wanted to, you could trace the certification of trusted sources from any Certificate holding website straight up to the top, where only a very few entities exist. The same mechanism that identifies a legitimate website with a legitimate Certificate also identifies a legitimate CA.
A Certificate is basically an official ID card for any entity wishing to provide encrypted traffic. It tells anyone who requests the information who the bearer is and which CA provided them credentials. But the encryption happens based on the “Public Key” that is attached to that Certificate. When your browser approves the Certificate, it then uses the Public Key to encrypt any data sent to the server. The server uses its “Private Key” to decrypt the messages. Without the Private Key, the message is unreadable.
When the server wishes to communicate back to your browser, it encrypts the message using its Private Key. Again, without the Public Key (plus a few details that identify this conversation between the browser and server), decrypting the message is impossible. Also, if the Public Key cannot decrypt the message, this is proof that the message did not come from the correct server – thus thwarting the MITM attack that might swoop into the middle of your transaction. PKI provides both encryption and authentication.
Trust can be broken
This seems like a pretty good system, doesn’t it? Layers of trust extending from your browser straight to the top of the security world, with names like Verisign, Xcert and even Netscape. The system provides both privacy by encrypting data and authentication by pairing the keys and session information. How could this possibly go wrong?
The answer in this case seems to be a hacker gaining access to a CA and issuing itself bogus Certificates for legitimate entities. The hacked CA, DigiNotar, has been fairly tight-lipped about the break-in, so we don’t yet know by what means they were hacked or how many Certificates were issued. Some reports estimate that number to be around 200 Certificates.
But that’s not the end of the story. Not only does a hacker need to gain access to some of the highest-security servers in the public world (we hope) to get the Certificates, they also have to spoof their intended targets completely. That’s a tall order for your run-of-the-mill pissed-off ex-employee to handle on their own. Particularly since in this case, it appears just about all traffic in and out of Iran was getting spoofed.
In order to affect that kind of ubiquitous MITM, the hacker would presumably need to do some serious DNS poisoning (perhaps the subject of another article, some time). Whereas “normal” phishing and session-hijacking attacks would simply redirect the user to another web address, this attack would need to completely rewrite the routes between the victim host and victim server. An ISP could do it – they run your DNS servers for you – but why?
This is why many experts seem to be suggesting that this spoof had to be the work of a government. Perhaps Iran is trying to keep tabs on its people ahead of a potential revolution. Perhaps other governments are looking to dig up sensitive information on Iran by monitoring Gmail and Google Docs. Or it might really be the work of a single hacker or small confederation of hackers. Anything’s possible and at this point, we just don’t know.
What is important is that this type of attack is possible at all. As security guru Bruce Schneier points out, this is in part because of the number of potential points of failure: there are simply too many CAs issuing too many Certificates. Moreover, while browser manufacturers like #Microsoft #Mozilla and #Google are updating their browsers to reject bogus certificates, the fact is that many applications do not bother to check for Certificate authenticity beyond matching the name on the Cert with the name on the website. So in a system built on shared trust models, there maybe more trust than there is cause to be trusting.
Obligatory “Don’t Panic” wrap-up
While the severity of these attacks is profound, the reality is that this does not so far appear to be a particularly feasible attack for the average crook. For now at least, the danger seems to be on a governmental level: either one’s own government snooping on them or a foreign government snooping. If that seems less than comforting, just remember that Anonymous and LolsSec are private enterprises and so far, there is no indication that such a group could pull this off. Nor for that matter could a terrorist organization unaided by a government.
Even a government would have a hard time pulling this same stunt twice: from now on, security experts will be eyeing CAs with even less trust than they have in the past. Browsers will get smarter, banks will demand safeguards. And banks run the world of security – if not the world – so Internet security is bound to get much tighter over the next few months.
Like all security breaches once discovered, we almost owe a debt of gratitude for the wake-up call. Vulnerabilities are discovered and patched, principles involved are alerted to another potential hazard and security generally tightens up. As new facts come to light, it will be interesting to see just who is behind the attacks. And what comes next.
