3 ms·

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 Goog

by 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...
- noerps 13y ago
  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.
- simonbrown 13y ago
  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.
- ww520 13y ago
  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.

by MertsA 13y ago

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...
noerps 13y ago
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.
simonbrown 13y ago
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.
ww520 13y ago
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.