5 ms·

Regarding the direct tapping into the fiber cables, does using SSL have any effect on it? (in case it's not obvious, I'm a cryptography n00b)

by scribu 13y ago

bretpiatt 13y ago
If you believe SSL is cryptographically secure against the party trying to access your data. It also only encrypts the payload. If I'm tapping your connection at a minimum I still see who you exchange data with, at what time, and how much. Metadata is very powerful.
throwaway10001 13y ago
IIRC, they can store it ssl-ed and wait for the encryption to be broken. If Google can store everything in their servers, NSA, CIA et al with virtually unlimited budgets and some of the best mathematicians in the world surely can do the same.
- wavefunction 13y ago
  This is likely. They store everything then decrypt as necessary in a continuous batch mode as targets are identified. It looks like they have some sort of alerting system for real-time "incident surfacing" for things they feel they need to react to quickly, but I imagine most of their work is over the longer-term as far as building profiles of their targets.
c0ur7n3y 13y ago
I wouldn't be surprised if the NSA has a "special" relationship with many certificate authorities that allows it to man-in-the-middle SSL.
- EthanHeilman 13y ago
  Not just the NSA, many companies can buy CA privledges from a CA. For instance trustwave used to sell this as a service so companies could watch their employees. http://www.eweek.com/c/a/Security/Mozilla-Asked-to-Revoke-Trustwave-CA-for-Allowing-SSL-Eavesdropping-545114/ http://www.eweek.com/c/a/Security/Mozilla-Asked-to-Revoke-Tr...
- sneak 13y ago
  If they did any sort of active MITM like this, this would be incredibly easy to detect and would nearly instantly divulge their intercept operations. Have we learned nothing from their public history? They simply don't do shit like that.
kniht 13y ago
It bears repeating because this argument comes up in every PRISM thread... The basics: HTTPS is TLS/SSL transport level encryption of HTTP traffic (including HTTP headers). The way it works is that client and server go through a handshake process where the server (and optionally client) present a public key and proof of ownership of a private key. The server public key is also normally signed by a certificate authority (e.g. Verisign), this is what is normally meant by a certificate. Threat Models: There are a number of different threat models that crop up when talking about TLS. I'll talk briefly about each below. 1. Compromised Certificate Authority (CA) If the CA is compromised then the rogue CA can be used to create new certificates that claim to be for the intended target server (e.g. Google or Facebook)[1]. The fake certificate can then be used to launch a Man-in-the-Middle (MITM) attack where the attacker convinces a victim to connect to them, and creates two separate TLS connections VICTIM<-TLS1->MITM<-TLS2->SERVER. The MITM can see the unencrypted messages since the victim is encrypting to the key in the fake certificate. Chrome's certificate pinning can be used to prevent this type of attack since the browser will check to see if the server has presented the _correct_ certificate for the intended server (by comparing public key fingerprints AFAIK). This attack can also be prevented if the connection is mutually authenticated by either a client certificate or an ephemeral ChannelID as discusses here[2]. 2. Attacker has _correct_ private key for server This threat model assumes the attacker has obtained the server's private key either via coercion / collusion. Certificate pinning doesn't prevent this type of attack. 2a. If the attacker is a passive attacker, meaning that they can only observe and record encrypted messages, then they can decrypt any messages that are sent over a cipher spec that doesn't have perfect forward secrecy (PFS). If the connection is setup using the Ephemeral Diffie-Hellman key exchange then the communication channel should be safe from a passive attacker. If the connection is mutually authenticated and the client certificate has not been compromised by the attacker, then the connection should also be safe from this attacker. 2b. If the attacker acts as a MITM then even PFS cipher specs can be compromised. 3. Attacker can break TLS encrypted channels and extract data without needing the keys All bets are off if this can be done in a general way. There have been several attacks (BEAST, CRIME, Lucky13) that can extract small repeated bits of data (user authentication cookies), but no known attacks that can get at all of the data sent over a TLS encrypted channel. [1] http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulen... [2] http://tools.ietf.org/html/draft-balfanz-tls-channelid-00 http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

Regarding the direct tapping into the fiber cables, does using SSL have any effect on it? (in case it's not obvious, I'm a cryptography n00b)

by scribu 13y ago

Regarding the direct tapping into the fiber cables, does using SSL have any effect on it? (in case it's not obvious, I'm a cryptography n00b)

bretpiatt 13y ago

If you believe SSL is cryptographically secure against the party trying to access your data. It also only encrypts the payload. If I'm tapping your connection at a minimum I still see who you exchange data with, at what time, and how much. Metadata is very powerful.

throwaway10001 13y ago

IIRC, they can store it ssl-ed and wait for the encryption to be broken. If Google can store everything in their servers, NSA, CIA et al with virtually unlimited budgets and some of the best mathematicians in the world surely can do the same.

wavefunction 13y ago
This is likely. They store everything then decrypt as necessary in a continuous batch mode as targets are identified. It looks like they have some sort of alerting system for real-time "incident surfacing" for things they feel they need to react to quickly, but I imagine most of their work is over the longer-term as far as building profiles of their targets.

c0ur7n3y 13y ago

I wouldn't be surprised if the NSA has a "special" relationship with many certificate authorities that allows it to man-in-the-middle SSL.

EthanHeilman 13y ago
Not just the NSA, many companies can buy CA privledges from a CA. For instance trustwave used to sell this as a service so companies could watch their employees. http://www.eweek.com/c/a/Security/Mozilla-Asked-to-Revoke-Trustwave-CA-for-Allowing-SSL-Eavesdropping-545114/ http://www.eweek.com/c/a/Security/Mozilla-Asked-to-Revoke-Tr...
sneak 13y ago
If they did any sort of active MITM like this, this would be incredibly easy to detect and would nearly instantly divulge their intercept operations. Have we learned nothing from their public history? They simply don't do shit like that.

kniht 13y ago

It bears repeating because this argument comes up in every PRISM thread... The basics: HTTPS is TLS/SSL transport level encryption of HTTP traffic (including HTTP headers). The way it works is that client and server go through a handshake process where the server (and optionally client) present a public key and proof of ownership of a private key. The server public key is also normally signed by a certificate authority (e.g. Verisign), this is what is normally meant by a certificate. Threat Models: There are a number of different threat models that crop up when talking about TLS. I'll talk briefly about each below. 1. Compromised Certificate Authority (CA) If the CA is compromised then the rogue CA can be used to create new certificates that claim to be for the intended target server (e.g. Google or Facebook)[1]. The fake certificate can then be used to launch a Man-in-the-Middle (MITM) attack where the attacker convinces a victim to connect to them, and creates two separate TLS connections VICTIM<-TLS1->MITM<-TLS2->SERVER. The MITM can see the unencrypted messages since the victim is encrypting to the key in the fake certificate. Chrome's certificate pinning can be used to prevent this type of attack since the browser will check to see if the server has presented the _correct_ certificate for the intended server (by comparing public key fingerprints AFAIK). This attack can also be prevented if the connection is mutually authenticated by either a client certificate or an ephemeral ChannelID as discusses here[2]. 2. Attacker has _correct_ private key for server This threat model assumes the attacker has obtained the server's private key either via coercion / collusion. Certificate pinning doesn't prevent this type of attack. 2a. If the attacker is a passive attacker, meaning that they can only observe and record encrypted messages, then they can decrypt any messages that are sent over a cipher spec that doesn't have perfect forward secrecy (PFS). If the connection is setup using the Ephemeral Diffie-Hellman key exchange then the communication channel should be safe from a passive attacker. If the connection is mutually authenticated and the client certificate has not been compromised by the attacker, then the connection should also be safe from this attacker. 2b. If the attacker acts as a MITM then even PFS cipher specs can be compromised. 3. Attacker can break TLS encrypted channels and extract data without needing the keys All bets are off if this can be done in a general way. There have been several attacks (BEAST, CRIME, Lucky13) that can extract small repeated bits of data (user authentication cookies), but no known attacks that can get at all of the data sent over a TLS encrypted channel. [1] http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulen... [2] http://tools.ietf.org/html/draft-balfanz-tls-channelid-00 http://tools.ietf.org/html/draft-balfanz-tls-channelid-00