[LINK] Gov’t, certificate authorities conspire to spy on SSL users?

[Kim Holburn]

http://arstechnica.com/security/2010/03/govts-certificate-authorities-conspire-to-spy-on-ssl-users/

> SSL is the cornerstone of secure Web browsing, enabling credit card and bank details to be used on the 'Net with impunity. We're all told to check for the little padlock in our address bars before handing over any sensitive information. SSL is also increasingly a feature of webmail providers, instant messaging, and other forms of online communication.
> 
> Recent discoveries by Wired and a paper by security researchers Christopher Soghoian and Sid Stamm suggests that SSL might not be as secure as once thought. Not because SSL itself has been compromised, but because governments are conspiring with Certificate Authorities, key parts of the SSL infrastructure, to subvert the entire system to allow them to spy on anyone they wish to keep tabs on.
> 
> With SSL, any two parties on the Internet can make a secure connection between them, through which information can be passed without eavesdroppers being able to listen in. However, the core technology used in initiating SSL connections has some problems. The first problem is that although it allows you to create a secure connection between two parties, it doesn't allow either party to prove that the person they're talking to is the one they think they're talking to. The second is that if an eavesdropper can intercept the initial negotiation they can sit between the two other parties and decrypt and then re-encrypt the data sent between them, allowing them to see what's being sent, without either party knowing.
> 
> Such attacks, where someone sits between the two parties and listens in on their conversation, are known as "man-in-the-middle" attacks. They're a big threat when trying to perform private communication over an insecure medium. Fortunately, there's a solution.
> 
> The solution to both of these problems is cryptographic certificates. A certificate provides an unforgeable proof of identity, allowing one person to verify that they are indeed talking to their bank (rather than a hacker), and by incorporating certificate data into the set-up of the secure connection, the man in the middle can no longer decrypt and encrypt the traffic without being detected.
> 
> The problem with certificates is that on its own, a certificate announcing "I am Amazon.com" doesn't mean much—anyone could make one. To deal with that, certain organizations are trusted by SSL software. If a certificate is issued by one of these companies, it will be trusted by SSL software. The reason these companies are trusted is that they make some promise to verify who people are before issuing them with certificates. In other words, before they'll give me a certificate that lets me claim to be a bank or a well-known online retailer, they'll check that I really am the bank or retailer, and only if I am who I say I am will they give me the certificate.
> 
> These organizations are called Certificate Authorities (CAs), and their role in the system is essential. Most Web browsers and operating systems have a set of certificates from a few dozen CAs, and will verify that the certificates used in any SSL connection can be traced back to one of those CAs. If the certificate can't be traced back, the software will typically display a warning about an untrusted connection, and might even refuse to connect entirely.
> 
> The weak link here is that if a CA could be persuaded to issue a certificate to, say, Amazon to someone who wasn't actually from Amazon, then all the protections fall apart. Anyone connecting to the person with that certificate would think that they were connecting to the real Amazon. Moreover, if the person could intercept traffic between would-be customers and the real Amazon, they could do the decryption/re-encryption trick to listen in on any traffic sent to and from the company.
> 
> Untrustworthy certificate authorities
> 
> Until now, it had been broadly assumed that the CAs were honest and wouldn't give certificates to people they shouldn't, thereby keeping the entire system trustworthy. Though there have been attacks on certain aspects of the cryptography and handling of certificates by software, the basic design of SSL has been solid, and these specific problems have been solved by tightening policies and fixing software. Unfortunately, these untrustworthy CAs render all the encryption technology irrelevant, as it can now be bypassed.
> 
> 
> The security researchers found out that an Arizona-based network security company, Packet Forensics, was covertly selling a piece of hardware designed to perform these man-in-the-middle attacks—just as long as it could be provided with a suitable certificate. The existence of such a product makes no sense without the ability to retrieve such certificates—which meant that CAs must be handing over certificates so that they could be used with the device.
> 
> Software for security researchers and/or hackers that could perform this kind of man-in-the-middle attack has been around for some years, but its utility has always been limited due to the difficulties in getting appropriate certificates; the tools are useful in demonstrating the kind of attacks mentioned above, but have little practical value. The existence of hardware changes things substantially—nobody goes to the expense of designing and creating hardware devices unless they can use them.
> 
> Packet Forensics initially denied that it even sold the devices, but eventually admitted that they were real. The company sells hardware to law-enforcement agencies and similar groups, so these certificates might well be issued on demand of a court order. But equally, they could be coerced by blackmail, or even outright theft.
> 
> This strikes a blow at the entire trust system integral to SSL. If CAs can't be trusted, the SSL can't be used safely.
> 
> And it gets worse.
> 
> It gets worse
> 
> 
> The set of CAs trusted by default by different browsers and OSes vary, but there are some commonalities between them all. A few big CAs like VeriSign are supported as standard across the board. These CAs might in turn be victims of court orders, blackmail, and so on. But many platforms go further, and include government CAs. That is, certificate authorities operated not by private, independent corporations, but by government departments (typically government telecommunications monopolies). The reason for this is to allow governments to avoid a dependence on external third parties for their cryptographic needs, but the result is this: any one of those governments could produce a certificate purporting to be from any site in the world, feed it into one of Packet Forensics' machines, and use it to eavesdrop on encrypted traffic. Because the browser will automatically trust a certificate issued by one of these government authorities, it won't provide any alert to the user that something is wrong with the certificate. Everything will appear to work as normal. It just won't be secure.
> 
> Now, a careful observer might be able to detect this. Amazon's certificate, for example, should be issued by VeriSign. If it suddenly changed to be signed by Etisalat (the UAE's national phone company), this could be noticed by someone clicking the padlock to view the detailed certificate information. But few people do this in practice, and even fewer people know who should be issuing the certificates for a given organization.
> 
> Even this is limited; if VeriSign issued the original certificate as well as the compelled certificate, no one would be any the wiser. The researchers have devised a Firefox plug-in that should be released shortly that will attempt to detect particularly unusual situations (such as a US-based company with a China-issued certificate), but this is far from sufficient.
> 
> This gives governments considerable ability to intercept and eavesdrop on supposedly secure communications. It's true that the case is, at present, only circumstantial. Just because a company is selling man-in-the-middle hardware that requires the use of court-ordered certificates, and just because companies like VeriSign make a lot of money from security and surveillance does not necessarily mean that anyone has actually bought or used the technology. But it seems unlikely that a company would develop or promote a man-in-the-middle system if it could not be used. Though the weakness of the CA system is well-known, the prospects of real attacks on CA trust seemed slim. Not so any more. VeriSign, for its part, refuses to comment on the matter; other CAs, such as GoDaddy, insist that no such request has ever been made, nor would such a request be granted.
> 
> Update: VeriSign has commented to say, "VeriSign has never issued a fake certificate, and to do so would be against our policies."
> 
> The value to governments—enabling largely undetectable spying on, say, Gmail accounts—could be substantial, as such tools are widely used among both terrorists and freedom fighters alike. It'd be useful in the growing international industrial espionage business, too. And governments are certainly known to be interested; Etisalat last year rolled out a BlackBerry patch that embedded spyware into RIM devices enabling monitoring of e-mail, so it can hardly be considered trustworthy (in spite of its widespread appearance in trusted CA lists).


-- 
Kim Holburn
IT Network & Security Consultant
T: +61 2 61402408  M: +61 404072753
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request