The news that the NSA used various methods to weaken cryptographic algorithms and protocols has caused more of a shock than I would have thought. It's been widely believed that the NSA had already broken some methods of encryption (whether a specific kind or in the right circumstances) through discovering flaws, new math, or computation power. But I suppose the intentional insertion of weakness as well as working with some companies to install backdoors or flaws is what stuns. By making supposedly secure methods weaker, the NSA endangers us all, including America's personal, corporate, and government interests. But there's one thing you can do about secure Web connections.
Bruce Schneier, who has seen the Snowden-provided documents on which the ProPublica/Guardian/New York Times report was based, has a set of recommendations for what security methods to employ. He skips one nascent effort, though, that's easy for non-technical users to add: the Perspectives Project. This Carnegie-Mellon University project lets users consult a central database of Web site digital certificates and be informed when any of those certificates change, and manually report attacks.
Right now, the Web of trust (sorry) for digital certificates works thusly. If you want to use the industry-standard SSL/TLS protocol for establishing a secure connection between client software and a server — in this case, a Web site, but also for email and many other purposes — the Web site in question has to obtain a certificate. It creates a certificate using a proprietary or public key-generation process (the private ones may now be suspect), and then has it digitally signed by a certificate authority (CA), which is either a company you work with directly, or with which a Web hosting company interacts on your behalf. (To sign a certificate, the plain-text contents are hashed, which distills the messages through a one-way encryption algorithm into a relatively short run of characters. That hash is encrypted with the CA's private key.)
A globally acceptable CA has a certificate installed in every operating system and in many browsers that contains cryptographic information that can be used to validate any certificate that it signs. When your browser connects to a Web server, the server sends its certificate. The browser checks its own list or that of the operating system to ensure that the signature is valid. If so, the server's public key is used to encrypt a session key, a symmetrical one that both sides use. (The plain text of the certificate is hashed by the browser or OS, while its signature is decrypted using the built-in public key for the CA. If the two hashes match, great; if not, the text has been modified. If the certificate isn't signed by the CA, the key won't decrypt it, too, resulting in a failure.)
There are several hundred CAs
in the world, and they have a huge number of reseller relationships which
gives access to countless more groups. There is no enforceable standard by
which CAs issue certificates (guidelines, yes), nor the security provisions to restrict
them. This means it's trivial for a party that has access to a CA to issue certificates for domains for which they have no business doing so. These certificates are perfectly valid, but they are illegitimate. This is what happened when DigiNotar's system was compromised. DigiNotar certificates were issued for a bunch of major Internet services.
Because of the lack of global recordkeeping and standards, it's impossible to know whether a given certificate from a CA is valid. Google has promoted the notion of pinning, which they built into Chrome and use for some of their domains. A browser that supports pinning only allows a certificate for listed domains to be signed by specific CAs. If a certificate is presented signed by another CA, the browser sounds the alarm. (There's a proposal called DANE that would allow every domain owner to list the valid certificate signatures for each subdomain in DNS records, but it requires the long-in-progress DNSSEC security upgrade to be further along to work at any scale.)
Without pinning, however, it's possible for an exploited CA or one that is under the control of a government (suspected in some countries) to issue a certificate for any Web site it chooses and use it without detection. Sorry for the bold. This can then be paired with DNS poisoning, in which domain-name queries for an ISP, business, or entire country (cf., Iran et al.) are provided with a false response that directs a browser (or email client or what have you) to a different IP address. An illegitimate but valid certificate coupled with DNS poisoning allows seamless interception of supposedly secure data. It is likely happening all the time.
It's also critical to note that the NSA revelation includes successful attacks against SSL/TLS connections. There's not enough detail to know what it means. Does the NSA have a way to generate CA-signed certs? Has it figured out how to break the basic protocol? Is there a weakness in one or more server software packages that allows an https connection to be intercepted and decrypted? Hard to know.