Nobody has ever presented any evidence ever that NSA has Google's SSL/TLS keys. Not only that, but Google has (a) pinned their public keys so that the browser binary itself can reject bogus- but- signed certificates, and (b) pushed heavily to enable forward secrecy in TLS, which means that even if you compromise their key, you can't decrypt sessions without being an active man in the middle.

Not quite. Having someone's private SSL key doesn't necessarily let you read the contents of their SSL traffic due to forward secrecy. It does let you sign messages as if you were them, or MITM their traffic.

http://en.wikipedia.org/wiki/Secure_Socket_Layer

For instance, on HN, Chrome is currently doing this:

    Your connection to news.ycombinator.com is encrypted with 128-bit encryption.
    
    The connection uses TLS 1.2.
    
    The connection is encrypted using AES_128_CBC, with SHA256 for message
    authentication and ECDHE_RSA as the key exchange mechanism.

Using ECDHE_RSA, my browser and HN's server will agree upon a key to use for encryption using AES128 in CBC mode. Now in order to read what the server sends me and what I send to the server, you need to break the crypto:

1. Brute force the 128 bit key. This is.. probably not going to happen?

2. Via a weakness in the AES128 algorithm or implementation, you can simplify a brute force into feasibility (AFAIK, no such attack currently exists).

3. Via a passive attack on ECDHE_RSA, you could potentially guess the shared key efficiently and decipher our communications (AFAIK, no such attack currently exists).

So it's not quite as simple as recording encrypted information and obtaining the SSL keys. You need the server to actively remember the keys used for every encrypted connection, and obtain those, too. Or MITM everything and record the unencrypted data.