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...).
Elliptic Curve Crypto can be used here - ECDSA and
ECDH. OpenSSH already supports Elliptic curve PKI from a few releases -
http://openbsd.das.ufsc.br/openssh/txt/release-5.7. Concering
digital certificates, there don't seem to many CAs supporting this,
however, there seem to be http://www.entrust.net/ecc-demo/ and
http://www.entrust.net/ecc-certs/index.htm. Also, few details on that
here http://this.is.thoughtcrime.org.nz/elliptic-curve-ca-guide.
Browser support is also important here - latest Firefox and Chrome
should be supporting it (both use NSS which implements TLS1.1 -
https://en.wikipedia.org/wiki/Transport_Layer_Security#Standards).Also,
for KDFs like scrypt can be
used.
Yes, one can still argue that Quantum algorithms can be used to break
these (including RSA). However, there are none built (or being built)
which can work, breaking RSA/EC is a distant target.