4 ms·

> reporting by non-technical journalists doesn't help the cause non-technical journalists Ever heard of a certain Jacob Appelbaum?

acqq 12y ago
That guy you mention in spite of his very technical background also avoided the technical details and possibly also tried to sensationalize: I was worried as he claimed that the SSH is broken, but it seems that there is no document that states that for the passive capture of the SSH traffic (at least the documents are there and everybody can analyse them). However we already knew for a while that the active attacks are being done: http://www.theguardian.com/technology/2014/dec/07/north-korea-sony-pictures-regin-gchq-nsa-snowden-belgacom http://www.theguardian.com/technology/2014/dec/07/north-kore... The active attack can of course obtain enough information to decrypt the traffic automatically afterwards or even record it unencrypted. It appears that's the context of the SSH decryption in the documents.
- spacefight 12y ago
  When will you guys all wake up? GCHQ does the full take on the cables, and there is no document yet, that claims NSA doesn't. So, all your sessions are hosed at some point in time. Either now or in the future. And yes, sensationalize is sometimes necessary to get more folks onboard to work with the documents.
  - dmix 12y ago
    So what if they are stored? There has been a big shift towards using perfect-forward-secrecy as default in the last 18 months.
    - spacefight 12y ago
      Can't you see the pattern? Take all, break the crypto later. PFS might be next, who knows. Yes, for now OTR and PGP is fine. There must be a big speculation on future breakthroughs regarding breaking crypto - otherwise they wouldn't build Bluffdale. Edit: Instead of downvoting, how about taking position?
      - acqq 12y ago
        It's not that the PFS is known to be broken, it's that it's actually still very rarely used (1) The present is problematic enough, we don't even need to hypothesize on the future breakages. 1) http://en.wikipedia.org/wiki/Forward_secrecy http://en.wikipedia.org/wiki/Forward_secrecy "As of December 2014, 20.0% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers." IPSEC is also often configured with the disabled PFS, even if the RFC is from 1998 ( http://tools.ietf.org/html/rfc2412 http://tools.ietf.org/html/rfc2412 )
      - tptacek 12y ago
        "PFS might be next, who knows"? What does that even mean? OTR and TLS PFS are closely related.
        acqq 12y ago
        Even when the PFS is configured, the defaults can be faulty: https://www.imperialviolet.org/2013/06/27/botchingpfs.html https://www.imperialviolet.org/2013/06/27/botchingpfs.html "I'm not aware of any open source servers that support anything like that." The article is from June 2013, has anything changed since?
        tptacek 12y ago
        Most sites that enable PFS do so with solid ECDH. It's hard to find PFS configuration guidelines that will give you breakable conventional DH groups. The latter half of AGL's post is about systems security, not (really) the cryptographic security of TLS. It's about things you can do that would make NSA owning up your servers a greater or lesser threat to previously encrypted TLS sessions.
deleted 12y ago
[deleted]
sneak 12y ago
If Jake Appelbaum had any technical credibility, he would have claimed something other than a break in SSH for his talk. :(
- tete 12y ago
  You might want to look at page 19 and 35: http://www.spiegel.de/media/media-35515.pdf http://www.spiegel.de/media/media-35515.pdf Did he actually say break?
  - xorcist 12y ago
    No, he did not say break in his talk. He said something along the lines of "at one point, the NSA mentions SSH together with SSL and IPsec as technologies which there are methods against" which could mean just about anything. They could break into the host and steal the host keys for example, without having to do costly cryptanalysis. But the moment he breathed SSH, pretty much all of IRC and the whole Saal 1 could not think of anything else. Everyone and their brother wanted to know what to use instead of SSH now that it's broken. It was a bit of panic in the air. My suggestion is to go to the leaked slide and make your own conclusions. There are among the most credible people we have behind openssh and the crypto primitives are used in a very straightforward way.
    - AlyssaRowan 12y ago
      They talk about decrypts of SSH tunnelling as a "potential", if they can later steal the keys. SSH, I note, does have an RSA-based key exchange as well as its usual Diffie-Hellman: if their targets have been using plain RSA, that would make an attacker's life easier for historical decrypts! Based on their typical methodology, I think that is probably what they are talking about, because they mention stealing IPsec pre-shared keys from router configurations in a very similar context. Of course, all we have is a probably - this selection of documents is not anywhere near as comprehensive as we'd perhaps like here. We're having to fill in the blanks - and there's too many blanks to fill in clearly. There seems to be relatively little in this leak from NSA's PICARESQUE/PIEDMONT, or GCHQ's STRAP3 (which covers specific operational details: purely by way of hypothetical example :-), where individual full-take feed taps actually are in Telehouse North, or specific details about SIGINT enabling via the Cavium Nitrox chips), sadly. Alternative ideas (or leaks!) are welcomed. Recent versions of OpenSSH have using some non-NIST primitives from djb, including Curve25519-SHA256 key exchange, Ed25519 keys and ChaCha20-Poly1305 transports. I am quite confident neither NSA nor GCHQ have any good cryptanalytic attacks against those primitives. There is mention of some exploitation against finite-field Diffie-Hellman in TLS (PHOENIX). That lacks context, however, and we can only guess about what's missing. One possibility is it's an active attack which tricks the peers into agreeing keys over an unsafe field (TLS 1.2 has no way to date for peers to suggest or agree on lists of named fields; however, the recent ffdhe draft does provide one) - however active attacks don't really fit the context under discussion in the slides. The TLS Working Group at IETF is currently discussing this, and a suggestion's been made to remove the old finite-field DHE transports due to their poor performance and apparent vulnerability, replacing them with ECDHE over secp256r1 (a NIST curve), and quite possibly in the near future X25519 over Curve25519 (a non-NIST curve). I don't know how that's going to resolve yet.

acqq 12y ago

That guy you mention in spite of his very technical background also avoided the technical details and possibly also tried to sensationalize: I was worried as he claimed that the SSH is broken, but it seems that there is no document that states that for the passive capture of the SSH traffic (at least the documents are there and everybody can analyse them). However we already knew for a while that the active attacks are being done: http://www.theguardian.com/technology/2014/dec/07/north-korea-sony-pictures-regin-gchq-nsa-snowden-belgacom http://www.theguardian.com/technology/2014/dec/07/north-kore... The active attack can of course obtain enough information to decrypt the traffic automatically afterwards or even record it unencrypted. It appears that's the context of the SSH decryption in the documents.

spacefight 12y ago
When will you guys all wake up? GCHQ does the full take on the cables, and there is no document yet, that claims NSA doesn't. So, all your sessions are hosed at some point in time. Either now or in the future. And yes, sensationalize is sometimes necessary to get more folks onboard to work with the documents.
- dmix 12y ago
  So what if they are stored? There has been a big shift towards using perfect-forward-secrecy as default in the last 18 months.
  - spacefight 12y ago
    Can't you see the pattern? Take all, break the crypto later. PFS might be next, who knows. Yes, for now OTR and PGP is fine. There must be a big speculation on future breakthroughs regarding breaking crypto - otherwise they wouldn't build Bluffdale. Edit: Instead of downvoting, how about taking position?
    - acqq 12y ago
      It's not that the PFS is known to be broken, it's that it's actually still very rarely used (1) The present is problematic enough, we don't even need to hypothesize on the future breakages. 1) http://en.wikipedia.org/wiki/Forward_secrecy http://en.wikipedia.org/wiki/Forward_secrecy "As of December 2014, 20.0% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers." IPSEC is also often configured with the disabled PFS, even if the RFC is from 1998 ( http://tools.ietf.org/html/rfc2412 http://tools.ietf.org/html/rfc2412 )
    - tptacek 12y ago
      "PFS might be next, who knows"? What does that even mean? OTR and TLS PFS are closely related.
      - acqq 12y ago
        Even when the PFS is configured, the defaults can be faulty: https://www.imperialviolet.org/2013/06/27/botchingpfs.html https://www.imperialviolet.org/2013/06/27/botchingpfs.html "I'm not aware of any open source servers that support anything like that." The article is from June 2013, has anything changed since?
        tptacek 12y ago
        Most sites that enable PFS do so with solid ECDH. It's hard to find PFS configuration guidelines that will give you breakable conventional DH groups. The latter half of AGL's post is about systems security, not (really) the cryptographic security of TLS. It's about things you can do that would make NSA owning up your servers a greater or lesser threat to previously encrypted TLS sessions.

deleted 12y ago

[deleted]

sneak 12y ago

If Jake Appelbaum had any technical credibility, he would have claimed something other than a break in SSH for his talk. :(

tete 12y ago
You might want to look at page 19 and 35: http://www.spiegel.de/media/media-35515.pdf http://www.spiegel.de/media/media-35515.pdf Did he actually say break?
- xorcist 12y ago
  No, he did not say break in his talk. He said something along the lines of "at one point, the NSA mentions SSH together with SSL and IPsec as technologies which there are methods against" which could mean just about anything. They could break into the host and steal the host keys for example, without having to do costly cryptanalysis. But the moment he breathed SSH, pretty much all of IRC and the whole Saal 1 could not think of anything else. Everyone and their brother wanted to know what to use instead of SSH now that it's broken. It was a bit of panic in the air. My suggestion is to go to the leaked slide and make your own conclusions. There are among the most credible people we have behind openssh and the crypto primitives are used in a very straightforward way.
  - AlyssaRowan 12y ago
    They talk about decrypts of SSH tunnelling as a "potential", if they can later steal the keys. SSH, I note, does have an RSA-based key exchange as well as its usual Diffie-Hellman: if their targets have been using plain RSA, that would make an attacker's life easier for historical decrypts! Based on their typical methodology, I think that is probably what they are talking about, because they mention stealing IPsec pre-shared keys from router configurations in a very similar context. Of course, all we have is a probably - this selection of documents is not anywhere near as comprehensive as we'd perhaps like here. We're having to fill in the blanks - and there's too many blanks to fill in clearly. There seems to be relatively little in this leak from NSA's PICARESQUE/PIEDMONT, or GCHQ's STRAP3 (which covers specific operational details: purely by way of hypothetical example :-), where individual full-take feed taps actually are in Telehouse North, or specific details about SIGINT enabling via the Cavium Nitrox chips), sadly. Alternative ideas (or leaks!) are welcomed. Recent versions of OpenSSH have using some non-NIST primitives from djb, including Curve25519-SHA256 key exchange, Ed25519 keys and ChaCha20-Poly1305 transports. I am quite confident neither NSA nor GCHQ have any good cryptanalytic attacks against those primitives. There is mention of some exploitation against finite-field Diffie-Hellman in TLS (PHOENIX). That lacks context, however, and we can only guess about what's missing. One possibility is it's an active attack which tricks the peers into agreeing keys over an unsafe field (TLS 1.2 has no way to date for peers to suggest or agree on lists of named fields; however, the recent ffdhe draft does provide one) - however active attacks don't really fit the context under discussion in the slides. The TLS Working Group at IETF is currently discussing this, and a suggestion's been made to remove the old finite-field DHE transports due to their poor performance and apparent vulnerability, replacing them with ECDHE over secp256r1 (a NIST curve), and quite possibly in the near future X25519 over Curve25519 (a non-NIST curve). I don't know how that's going to resolve yet.