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:[email protected] aim://kimholburn skype://kholburn - PGP Public Key on request _______________________________________________ Link mailing list [email protected] http://mailman.anu.edu.au/mailman/listinfo/link
