Hacker News Reader

> SSL certs require cooperation of a trusted registrar even for the biggest companies -- Google's is signed by Equifax, for example. Given what we've seen in the last few days, requesting keys from the root CAs is a no-brainer.

Getting a root's key does not enable them to decrypt the traffic. Getting the server's SSL private key USUALLY means you can retroactively decrypt, but it is possible (though uncommon) for servers to be configured to use ephemeral keys (EDH modes) which provide perfect forward secrecy (that is, the property that the session key can't be recovered even with later compromise of the server's long-term key).

Interesting sidenote: AFAIK there are no widely-supported (TLS 1.1 or below) methods of mitigating the BEAST attack while enabling PFS - those modes are TLS 1.2+ which isn't widely spoken yet.

This is all irrelevant though. The issue is with the tech companies giving them the plaintext data themselves. No amount of transport-layer encryption helps with that.

You have to stop using US services.

I can't update my original post now, but I stand corrected. I "remembered" uploading the private key with the CSR last time I went through the process, but must have misremembered. Well, that's some good news I guess. The NSA could still easily request the private key from the company, of course.

You don't share your private key with the CA.

A certificate is an attestation (signature) by a CA's private key that a given PUBLIC key is yours, that anyone with the CA's public key can verify.

The CSR does not contain your private key.

NONE OF THIS MATTERS. This is not about bulk-decrypting SSL, though I'm sure NSA does that when and where they can, too. This is about coordinated, automated, integrated methods of transmitting the plaintext.

Why should they bother getting a key and scraping gmail's payloads when they could just have Google give them an API? Furthermore, this method would continue working perfectly even ifwhen services switched to ephemeral key modes that provide PFS.

A key thing to point out, all a root CA does is verify your public key. The NSA can't get Google's private key from Equifax and they can't even impersonate Google if the end user is using Chrome even if Equifax signed a cert for them. The reason is because Chrome basically checks to see if the cert matches up with a known good copy.

Also, if your platform supports it, Gmail has perfect forward secrecy meaning that even if the NSA records all HTTPS traffic to gmail and later demands Google's private key they can't decrypt any of that captured traffic.

Tor on the other hand is a problem. It has several fundamental flaws as you pointed out like by controlling some gateway nodes and a few others you can start breaking any sort of secrecy that you would get from Tor. Really the only good thing about Tor is that it's well known. I really wish Tor would just die and people would move over to something better like I2P where it's an anonymous network, not just a kludged together anonymous proxy with hidden services slapped on as an afterthought.

I was under the impression having the ability to subpoena a key or cert from either the CA or the company issued the cert would give the NSA carte blanche on decrypting any (encrypted) data they may have gathered by other means.

Since I don't seem to be understanding the associated technology as well as I thought I was, could you point me towards some relevant reading on this topic? How/Why are the current implementations of HTTPS considered to have perfect forward security?

With regard to your latter question, [1] gives a good overview on PFS in TLS. You'll need to exchange keys using (EC)DHE, essentially.

As for subpoenaing keys: Most CAs will allow for you to generate your key pair and certificate signing request on your own hardware. You'd then submit the CSR which the CA would in turn generate a signed certificate from. The private key should never be shared with the CA. In order to eavesdrop on communications, the NSA would then need to subpoena each targeted company's key. Wide reach is easy (go for the 5-10 biggest fish), comprehensive reach nigh impossible.

[1] http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...

With SSL, both parties negotiate synchronous encryption (like in AES) and key exchange (like in RSA) for that, the trust is established with signed certificates obtained from a 3rd party. Which is/was fine on paper and concept, the implementation sucks and we don't have alternatives to that.

With any CA's (or better, the right one's) private key, they could still use it to stage a MITM attack on the website, assuming they have the right access.

I think you are in the risk of a man-in-the-middle attack if the website's private key is compromised. Someone forces a proxy server between you and the website, via DNS spoofing or ARP IP take over in the subnet. When you try to go to the website, you land on the proxy which has the website's private key (and the cert) to initiate SSL connection with your browser assuming the website's identity. The proxy then turns around to make another SSL connection to the real website on your behalf, ferrying data back and forth between two connections, capturing all your "secure" traffic.

Tor does not provide security, it can provide obfuscation that may lead to anonymity or pseudonymity, not more.

I concur with your statement that SSL isn't really secure end-to-end communication when 3rd party certificates are involved.