6 ms·

The content in this post is in the section titled 'SSL on CloudFlare'. The text leading up to that is (at best) fluff and incorrect in parts.

by ctz 13y ago

jgrahamc 13y ago
Please indicate what is incorrect and I will ask the CEO to correct.
- genwin 13y ago
  > To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. ... As part of these challenges, we always request the right to disclose at least the fact that we received such an order but we are not always granted that request. Are you challenging orders you haven't received? It might help to be more clear. For all we know, CloudFare has been required to give all its data to the NSA. The law allows that, and the law could prevent CloudFare from disclosing it.
  - eastdakota 13y ago
    There are orders other than FISA orders that we have challenged.
    - genwin 13y ago
      I suggest the paragraph be more clear on that, then. "We may however receive orders unrelated to FISA, in which case we are legally allowed to challenge the order." It might be best to be completely forthcoming. Let the customers know that their data can always be secretly read by the NSA with CloudFlare's assistance, even all customers' data, but you challenge what you are legally allowed to challenge. Or say nothing about it. As it is the text implies that the customers' data is better protected against snooping, which isn't possible and most everyone knows that now, so it leads to suspicion.
- ctz 13y ago
  Point by point: The first paragraphs make the mistake of assuming you need to break keys to collect SSL traffic (assuming no PFS). You can start collecting SSL traffic now, and break the keys at your leisure later on. I can see cases where breaking confidentially of contemporary communication even 10-20 years hence would be extremely valuable. "Just the power necessary to run the server farm needed to break a 1024-bit key would likely cost in excess of $20M/year" The ECRYPT II Yearly Report on Algorithms and Keysizes suggests that an adversary with a budget of $10M should be countered with at least 78 bits of security, and that 1024-bit modulus RSA keys have 73 bits of security. I think this is a pretty good source on this sort of thing. "Google is a notable anomaly. The company uses a 1024-bit key" I've seen in the past Google presenting ECDSA server keys on P256, for some hosts and assuming your client advertises ECC with suitable extensions. Such keys are roughly equivalent in strength to 3248-bit modulus RSA keys. "This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google." An important note here: an active attacker can silently downgrade client connections to turn off PFS. "(Remember, for a naive algorithm, each bit doubles the time it takes to break the key, so a 2048-bit key isn't twice as strong, it is 2^1024 times as strong.)" This is dangerously misleading, even with the qualification. In fact, its around 2^30 times as strong. You really must assume your adversary is using the best available factoring algorithm, or your conclusions will be meaningless.
  - vxNsr 13y ago
    About your first point, the slide would seem to indicate that the NSA didn't start collecting data until the dates posted. So for whatever reason they didn't collect data until that point, it's not clear if they've actually been able to read any of that data yet.
  - agwa 13y ago
    > An important note here: an active attacker can silently downgrade client connections to turn off PFS. Are you sure this is true? SSLv2 didn't have any protection of the handshake so downgrade attacks were possible, but since SSLv3 the client and server send each other MACs of the handshake traffic so any tampering should be detected. Quoth Wikipedia, TLS and SSL 3.0 provide "Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite." [1] [1] http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/Transport_Layer_Security
deleted 13y ago
[deleted]

The content in this post is in the section titled 'SSL on CloudFlare'. The text leading up to that is (at best) fluff and incorrect in parts.

by ctz 13y ago

The content in this post is in the section titled 'SSL on CloudFlare'. The text leading up to that is (at best) fluff and incorrect in parts.

jgrahamc 13y ago

Please indicate what is incorrect and I will ask the CEO to correct.

genwin 13y ago
> To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. ... As part of these challenges, we always request the right to disclose at least the fact that we received such an order but we are not always granted that request. Are you challenging orders you haven't received? It might help to be more clear. For all we know, CloudFare has been required to give all its data to the NSA. The law allows that, and the law could prevent CloudFare from disclosing it.
- eastdakota 13y ago
  There are orders other than FISA orders that we have challenged.
  - genwin 13y ago
    I suggest the paragraph be more clear on that, then. "We may however receive orders unrelated to FISA, in which case we are legally allowed to challenge the order." It might be best to be completely forthcoming. Let the customers know that their data can always be secretly read by the NSA with CloudFlare's assistance, even all customers' data, but you challenge what you are legally allowed to challenge. Or say nothing about it. As it is the text implies that the customers' data is better protected against snooping, which isn't possible and most everyone knows that now, so it leads to suspicion.
ctz 13y ago
Point by point: The first paragraphs make the mistake of assuming you need to break keys to collect SSL traffic (assuming no PFS). You can start collecting SSL traffic now, and break the keys at your leisure later on. I can see cases where breaking confidentially of contemporary communication even 10-20 years hence would be extremely valuable. "Just the power necessary to run the server farm needed to break a 1024-bit key would likely cost in excess of $20M/year" The ECRYPT II Yearly Report on Algorithms and Keysizes suggests that an adversary with a budget of $10M should be countered with at least 78 bits of security, and that 1024-bit modulus RSA keys have 73 bits of security. I think this is a pretty good source on this sort of thing. "Google is a notable anomaly. The company uses a 1024-bit key" I've seen in the past Google presenting ECDSA server keys on P256, for some hosts and assuming your client advertises ECC with suitable extensions. Such keys are roughly equivalent in strength to 3248-bit modulus RSA keys. "This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google." An important note here: an active attacker can silently downgrade client connections to turn off PFS. "(Remember, for a naive algorithm, each bit doubles the time it takes to break the key, so a 2048-bit key isn't twice as strong, it is 2^1024 times as strong.)" This is dangerously misleading, even with the qualification. In fact, its around 2^30 times as strong. You really must assume your adversary is using the best available factoring algorithm, or your conclusions will be meaningless.
- vxNsr 13y ago
  About your first point, the slide would seem to indicate that the NSA didn't start collecting data until the dates posted. So for whatever reason they didn't collect data until that point, it's not clear if they've actually been able to read any of that data yet.
- agwa 13y ago
  > An important note here: an active attacker can silently downgrade client connections to turn off PFS. Are you sure this is true? SSLv2 didn't have any protection of the handshake so downgrade attacks were possible, but since SSLv3 the client and server send each other MACs of the handshake traffic so any tampering should be detected. Quoth Wikipedia, TLS and SSL 3.0 provide "Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite." [1] [1] http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/Transport_Layer_Security

deleted 13y ago

[deleted]