5 ms·

I think this is misleading. I now believe that the NSA has the private keys for substantially all SSL certs in use, and I expect that a non-trivial percentage

by frisco 13y ago

I think this is misleading. I now believe that the NSA has the private keys for substantially all SSL certs in use, and I expect that a non-trivial percentage of Tor nodes are run by the government. 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. For Tor, a bunch of attacks are possible by owning only a small percentage of all nodes. Recently, Tor was issuing a "call for relays" due to a dwindling number of participants that was endangering the network. Considering that Tor came out of Navy research, if you don't think they have a statistically interesting number of nodes, you're crazy. If they don't, it's only because they don't think that Tor is an interesting source right now. TL;DR: Security depends on your threat model, and while I think that Tor and HTTPS provide strong protection from run-of-the-mill attackers, I don't think that either provides meaningful security if you're worried about the NSA.

noerps 13y ago
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.
deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
- noerps 13y ago
  All Convergence does is delegate to another 3rd party, which may lead to the conclusion there may be an attack in progress, that you may not have noticed before. You still have to trust another stranger that may offer you some perspective on issued and signed certificates (or not). Convegernce i.e. refused to work with CDNs which may have different certificates for the same domain for example, which may be completly valid. The key of public key crypto (like in RSA) was to make key management easier and independent of a 3rd party, to avoid further bloat, overhead and complexity. This is the same for Certificate Transparency/Pinning mentioned earlier, given the details it looks very strong on paper, but the implementation will suck in r/l terms.
MertsA 13y ago
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.
- Phlarp 13y ago
  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?
  - phlo 13y ago
    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-secrecy.html http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...
sneak 13y ago
> 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.
- frisco 13y ago
  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.
  - sneak 13y ago
    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.

by frisco 13y ago

noerps 13y ago

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.

deleted 13y ago

[deleted]

deleted 13y ago
[deleted]
noerps 13y ago
All Convergence does is delegate to another 3rd party, which may lead to the conclusion there may be an attack in progress, that you may not have noticed before. You still have to trust another stranger that may offer you some perspective on issued and signed certificates (or not). Convegernce i.e. refused to work with CDNs which may have different certificates for the same domain for example, which may be completly valid. The key of public key crypto (like in RSA) was to make key management easier and independent of a 3rd party, to avoid further bloat, overhead and complexity. This is the same for Certificate Transparency/Pinning mentioned earlier, given the details it looks very strong on paper, but the implementation will suck in r/l terms.

MertsA 13y ago

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.

Phlarp 13y ago
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?
- phlo 13y ago
  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-secrecy.html http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...

sneak 13y ago

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

frisco 13y ago
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.
- sneak 13y ago
  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.