4 ms·
OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
by leccine 12y ago
OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
- AceJohnny2 12y agoLike NaCl? http://nacl.cr.yp.to/ http://nacl.cr.yp.to/
- tptacek 12y agoNaCl addresses a different problem than OpenSSL. NaCl is great if you have no legacy or compatibility requirements, and it should be the only crypto library most web and mobile developers ever come within a mile of. But it's not a workable replacement for OpenSSL.
- Tomte 12y agoWhat about this from the libsodium web site? "NaCl ships with constructions that were just prototypes, and that shouldn’t be used any more." What does "shouldn't be used any more" mean? Certainly not security, or djb would have released an update. Compatibility with other products? Something else?
- tptacek 12y agoNo, IIRC Bernstein improved his public key signing system, and libsodium uses the new version. Neither construction is useful for standard TLS.
- uuid_to_string 12y agoFor per packet encryption. For authentication, there is CurveCP. People seem confident with OpenSSH's authentication mechanism. Why not use that? At some point one has to trust that the IP address one is sending/retrieving data to/from is the correct one. That's easier said than done if some host wants to keep changing its IP address every few days. The SSL PKI scheme (the SSL approach to authentication), as implemented for public websites, is not much of a confidence-builder, IMO. Opinions may differ. If websites maintained consistent IP addresses and we could authenticate these machines using OpenSSH keys, I would be more willing to believe we could verify their "authenticity".
- leccine 12y agoExactly. The problem with SSL/TLS that it relies on a broken promise with the CAs, and as we have seen several times it is extremely easy to exploit. Hello rogue CAs.
- Spittie 12y agoWhile I can agree with that, how do you get people to use your new awesome crypto library? LibreSSL (the name of the OpenBSD fork, it seems) API should stay OpenSSL-compatible, making it mostly a drop-in replacement. Also, I think that an OpenSSL cleanup is needed even if we get a new awesome library too. We can't drop OpenSSL overnight, and as you said it's bad. So this at least make it less bad, until there's something we can switch to.
- leccine 12y agoNobody said we can drop OpenSSL over night. If you start now in 2 years we might see the results.
- jerf 12y ago"We need a new clean start, sane design and rock solid implementation with principles and following best practices." We need everything after the comma, sure, but there's no particular logical connection with the bit before your comma. A drop-in, API-compatible replacement (or at least one where the bits of the API thrown out are carefully chosen and generally unused) with OpenSSL that isn't scary and has been vetted is by far the fastest way to get to the second bit. This is probably the best thing that could have happened to OpenSSL, and I predict a decent chance this will be the dominant branch in under a year.
- djmdjm 12y agoSo far, two of the clean starts (Apple's and GnuTLS) are known for the critical "goto fail" bugs. How would your clean start be different?
- leccine 12y agoI think if you dont understand what clean start means, there is no point having a conversation about this ^.
- Steltek 12y agoA clean start should include a better license. Either accept that SSL libraries _absolutely_must_ be update-able and auditable to be sure, which for myself implies nothing less than LGPLv3; or go for second-best and have just a plain old no-advert BSD license that is suitable to the GPL-has-cooties privatized crowd.