Thanks to Jacob Kaplan-Moss, Donald Stufft, David Reid, Allen Short, Zain Memon, and Chris Armstrong for review.
This is a guide for technical individuals to understand in what circumstances SSL communications are secure against an observer-in-the-middle (for all intents and purposes: the NSA).
The way SSL works is that when you got your operating system or browser, it had a list of Certificate Authorities (CA), basically a list of public keys. At some point google.com bought an SSL certificate from some CA, say Verisign, Verisign signed google's private key. When you make a connection to google.com it verifies that the SSL certificate it provides really was signed by a root certificate, and all communication is encrypted using standard public key cryptography.
There are two types of observers-in-the-middle (OITM), active and passive:
Passive observers record all traffic (either decrypted, or for later decrypting), they in no way alter it.
Active observers read all messages, decrypt them (if encrypted), possibly rewrite them, record them, re-encrypt them (if originally encrypted) and send them on to their destination.
If this happens, then the NSA is able to sit between you and google.com and it can rewrite all of google.com's traffic to say that it's certificate is some other one, which they created and signed using Verisign's private key. Note that this works for any CA, it doesn't have to be the CA that signed google.com's original key.
This requires an active observer.
Prevention: This can be prevented by using certificate pinning. Pinning works by requiring that a given host must be identified by a specific public key. There is currently no general, widely deployed, mechanism for certificate pinning. Google Chrome includes a list of pinned hosts, and tack.io is a proposal for a general purpose pinning system.
If this happens then the NSA is able to read all encrypted traffic to and from google.com.
This works with either an active or passive observer.
Prevention: This can be prevented by perfect forward secrecy (PFS). Essentially PFS works by using two secret keys, the private key, and a second, per session key, exchanged using a Diffie-Hellman key exchange. This will protect against passive observers, but is still vulnerable to active observers.
The NSA is able to read individual messages, reading all traffic would (probably) be too much computering.
This works with either an active or passive observer.
Prevention: Increase key-sizes used in certificates.
We're all fucked.
This works with either an active or passive observer.
Prevention: Turn off your computer.
If the NSA has google.com's private key and is performing an active attack then you're screwed. Against a passive attack PFS and certificate pinning will thwart attacks. If the NSA broke RSA or has a lot of computers, we're all fucked.
Remember: google.com is just an example, and computer refers to any networked device (e.g. your phone, your tablet, your television...).
But even the PFS ciphersuites cannot prevent real access by the NSA, as they can just instruct Google to not give them the private key, but just save and relay the actual session keys over some private wire.
In the case Google is colluding with the NSA, we're screwed any way they like it..
One of the additional problems is that most big sites have non-ephemeral ciphersuites prioritized over ephemeral (PFS) ciphersuites (if they offer them at all) in their list. And as the server makes the final decision for the selected ciphersuite, this means that the client still uses non-ephemeral suites if both parties support them.
My guess: SSL accelerators cause this as they prefer non-ephemeral suites that do not require additional per-connection storage and session key generation.
Source: I'm the maintainer of one of the SSL libraries