gistfile1.rst

Guide to how fucked is SSL?

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).

How does SSL work?

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.

What types of observers are there?

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.

How can SSL be fucked?

Verisign gives the NSA their private key

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.

google.com gives the NSA their private key

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 has a lot of computation power

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.

RSA is broken

We're all fucked.

This works with either an active or passive observer.

Prevention: Turn off your computer.

Conclusion

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...).

Quantic computers could theoretically makes this true by simplifying the problem to break a RSA key as a linear time-complexity problem (so very fast). So if one organization on earth has that,

@gawen Cant you chain it like a Merkle tree to help guard against that?

If the NSA broke RSA

Do you think RSA is broken or not? If so, why? You aren't making claims or providing any arguments, you are just saying random stuff about RSA really.

RSA is broken

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.

Another big problem is that most non-browser SSL clients don't check certificates properly and so are vulnerable to a MITM attack with no special key knowledge.

Also I don't know if you consider this in scope, but the NSA can just hack your browser using one of the 0-days they're sitting on, and then no amount of transport encryption helps.

Since you're using Google as an example, you should mention that Google has used Perfect Forward Secrecy since 2011.
http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-term-with.html

Is it worth mentioning the possibility that various symmetric key portions of ciphersuites could be broken? For example, if RC4 has an unknown vulnerability, the effective key space could be small enough for the NSA to attack that way.

You missed a prevention in your "the CA gives the eaves-dropper their private key" (or it's compromised, that's also a possibility - forget the government). If, in this case, Google is a not also in cahoots with the eaves-dropper you can use client certificate authentication/mutual authentication, depending on the cipher used.

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

不明觉厉
don't know why, but think it's Big