9 ms·

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially t

• api 11y ago
  You speak as if SSL/TLS hasn't been a rat's nest of problems. If they did it competently, there is no reason they couldn't implement their own crypto encapsulation. As far as why they rolled their own... have you ever actually tried to use IPSec? It's a usability nightmare. It's also problematic in containers due to container permission issues. I suppose they could have used DSSL (datagram SSL) but that'd probably add more overhead than what they did. I see little real world evidence that this "let the pros handle it" attitude toward crypto is helping.
  • weavenetwork 11y ago
    True. We did try ipsec, and couldn't find an implementation that was oss, demonstrably safe, and easy enough to pull into a first release. As weave matures, we'd love to work with experts to implement standard solutions, even if they are costly to put in place.
    • api 11y ago
      "demonstrably safe" -- this is another issue I have with this crypto conservative FUD. "Use SSL, don't roll your own!" Then we get BEAST, CRIME, Heartbleed, etc., and we discover that the dominant SSL/TLS implementation is a rat's nest of comically awful code: http://opensslrampage.org http://opensslrampage.org Look at the older posts for LuLz like: http://opensslrampage.org/post/83007010531/well-even-if-time-isnt-random-your-rsa http://opensslrampage.org/post/83007010531/well-even-if-time... I wonder just how much scrutiny IPSec implementations have gotten, especially since it's such a usability nightmare that nobody uses it.
      • weavenetwork 11y ago
        indeed. at the risk of entering tinfoil hat land, note the following http://blog.cryptographyengineering.com/2014/12/on-new-snowden-documents.html http://blog.cryptographyengineering.com/2014/12/on-new-snowd... ..although also the not 100% reassuring https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/ https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-...
        • takeda 11y ago
          What about other libraries? GnuTLS, NSS, PolarSSL, wolfSSL?
          • weavenetwork 11y ago
            What about them? Would you recommend one of them over the others?
            • takeda 11y ago
              Yes, any of them is better than rolling your own. Even if they have bugs (it is unlikely they don't), they'll still have less bugs than own implementation. If you are still not convinced, at least give user option what to use. curl[1] is a good example of giving freedom to the user. [1] http://curl.haxx.se/docs/ssl-compared.html http://curl.haxx.se/docs/ssl-compared.html
              • weavenetwork 11y ago
                Thanks @takeda. Are you aware that we did not roll our own crypto? Instead we used the NaCl crypto libs[1]. Weave adds about 300 LOC to integrate NaCl. You can read about it here - http://docs.weave.works/weave/latest_release/how-it-works.html#crypto http://docs.weave.works/weave/latest_release/how-it-works.ht... You can also read a bit about weave crypto in the comments from mradestock and msackman elsewhere on this page. I would be extremely grateful if you could provide actionable advice (or help) on which other crypto libraries could fit our requirements for weave. Please note that in addition to functional requirements, any library must be open source, hard to misuse, easy to package, and demonstrably safe. alexis [1] http://nacl.cr.yp.to/ http://nacl.cr.yp.to/
    • yellowapple 11y ago
      OpenBSD's implementation checks off at least the first two boxes, though the third would be a bit difficult in the GNU/Linux world.
      • weavenetwork 11y ago
        We are open to recommendations, help and overall insight from expert contributors in security. As many people on this thread have pointed out, it is a big and complex world..
• lclarkmichalek 11y ago
  Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705 https://twitter.com/lclarkmichalek/status/544882194456776705
  • msutherl 11y ago
    This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more depth in an email?" Even if you're dealing with a troll, this is still the best strategy.
    • weavenetwork 11y ago
      I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing? Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.
      • msutherl 11y ago
        To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation? But let's look at the Tweet in question: "@lclarkmichalek @weavenetwork please, if it is so simple and robust you are very welcome to contribute a patch." 1. He says "please", which in this case is sarcastic. 2. Then he says "if it is so simple," which is a dismissive way of saying "you think that it's simple, but you're wrong – it's actually very complicated." 3. And also "if it so so ... robust," which is a dismissive way of saying "you think that it's (more) robust, but you're wrong – it isn't." 4. And finally "you are very welcome to contribute a patch," which, first, does not need to be said as presumably anybody knows that they are welcome to submit a patch to an open source project, and second, basically amounts to "so, I'm going to make my problem your problem." This case is different from a feature request from a user, where "feel free to do it yourself" is slightly less inappropriate. There, what is meant is "this feature is not important enough to warrant our endorsement or any allocation of resources, but if you were to take on the burden entirely yourself, we would consider it." In this case, what is meant is something more like "we believe that your charge that there is a fundamental issue with our software is false and we are not interested in discussing until you have actually done the work for us," or in other words "fuck you." I admit, "fuck you" is quite strong for the general case, but the tone of the Tweet warrants that translation.
• weavenetwork 11y ago
  as laurie mentions in his article, you can easily use off the shelf security solutions with weave... the point of the current crypto is to provide something basic that works. we chose nacl for ease of implementation primarily. happy to add more types of security in the future. help would be welcomed!
• weavenetwork 11y ago
  Tony, the team recently updated the crypto docs to clarify the rationale etc etc - http://weaveworks.github.io/weave/how-it-works.html#crypto http://weaveworks.github.io/weave/how-it-works.html#crypto ... Moreover the entire crypto code for weave is about 300 lines. Please please please if you are an expert then a thorough review would not only be welcome but also acted upon. Thank-you. Alexis.
• jheriko 11y ago
  "they do not use a password hashing function" this is a bit of a facepalm whenever i hear this.
  • mradestock 11y ago
    > "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto http://weaveworks.github.io/weave/how-it-works.html#crypto: "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final ephemeral session key." Disclaimer: I work on Weave.
    • heavenlyhash 11y ago
      What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF", rfc2898, and pretty much everything in https://en.wikipedia.org/wiki/Key_derivation_function https://en.wikipedia.org/wiki/Key_derivation_function is a good start for reading. Furthermore, it's not clear to me what the use of the diffie-hellman is actually for. Perhaps I'm misreading or the linked document is an oversimplification, but... It appears that the public DH key is transferred without any authentication. If the public DH key is transferred without any authentication, it's trivially MITMable and serves no purpose whatsoever. It's true that mixing in the password later solves MITM at that point, but... yeah: All of the privacy and integrity you could produce with the system described is what comes from the password.
      • msackman 11y ago
        DH is used to ensure that every connection between every pair of weave router nodes that ever gets established uses a unique session key. Yes, the public key is exchanged in the clear, and yes, that is MITMable. But as you say, the subsequent combination of the result of the DH with the non-exchanged password solves that. What is the weakness with this approach? Is your point that there's nothing gained from doing the DH - you may as well just generate a secret key randomly, exchange that between the peers in the clear, and still have them combine that with the password secret, and the level of information exposed is the same? I think there is a difference. Say you have a captured stream of traffic and you want to decrypt it. With the simpler non-DH scheme, you already have the basic key, so all you need to do is guess the password, and run that through sha256 and then you can decrypt the entire stream. Now you have the password, you can decrypt every stream you capture from now on. But with the DH scheme, you have to both guess the password, and the ephemeral private keys which are never exchanged (either that, or break Curve25519). Even once you've done that, you only get access to that one captured stream - sure, you now know the password, but every connection between weave routers will use different random private keys to their DH, so you'll still have to brute force those for every stream you capture (or, again, break Curve25519). So ISTM there is a substantial difference there. That, to me, is the point of using the DH. But maybe I'm missing something... I'm slightly wondering whether people here are considering the use of DH and Public Key crypto by weave in the context of the usual "generate keys once and save them". This is just not the case in weave - weave generates fresh public and private keys for EVERY connection between routers. There is no requirement for weave that the password is human readable. It can be supplied through a file, so you can happily dd if=/dev/random of=/my/weave/passwd bs=1k count=1 to create a suitable weave password