3 ms·

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 de

by 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 Phlarp 13y ago

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.