6 ms·

A bit funny, a software library focused on cryptography, where security is an afterthought rather than proactive effort. I would consider the alternatives befo

A bit funny, a software library focused on cryptography, where security is an afterthought rather than proactive effort. I would consider the alternatives before going to OpenSSL.

mbrodersen 4y ago
https://www.microsoft.com/en-us/research/blog/project-everest-advancing-the-science-of-program-proof/ https://www.microsoft.com/en-us/research/blog/project-everes...
bheadmaster 4y ago
LibreSSL is a fork by OpenBSD crew that happened after the Heartbleed: https://www.libressl.org/ https://www.libressl.org/ Considering OpenBSD's reputation for proactive security, I'd say LibreSSL might be the best alternative out there.
- michaelsbradley 4y ago
  BearSSL is also worth a look: https://bearssl.org/ https://bearssl.org/
  - speedgoose 4y ago
    It’s not actively developed and it doesn’t support TLSv1.3 though.
    - snvzz 4y ago
      But it is high quality, small and uses few resources, thus worth a mention.
- mjhay 4y ago
  Why hasn't LibreSSL taken off? I thought for sure it would after heartbleed. I assume it's mostly network effects/laziness, despite being fairly compatible (at least when it originally forked) and everyone already using OpenSSH from the openbsd as well.
  - yjftsjthsd-h 4y ago
    Compatibility seems to be a difficulty: https://voidlinux.org/news/2021/02/OpenSSL.html https://voidlinux.org/news/2021/02/OpenSSL.html
  - jessermeyer 4y ago
    Large web companies like Google implement their own encryption stack anyway. On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.
    - woodruffw 4y ago
      > Large web companies like Google implement their own encryption stack anyway. Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!). So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs). [1]: https://boringssl.googlesource.com/boringssl/ https://boringssl.googlesource.com/boringssl/
      - arianvanp 4y ago
        AWS maintains their own TLS stack: https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls
      - seadan83 4y ago
        Is this an argument for GPL? Seems like the big players came, saw, borrowed, and then did their own thing without contributing back. If this were my project, I would be inclined to archive it and do a GPL fork.
        woodruffw 4y ago
        None of what happened with OpenSSL or its forks is incompatible with the GPL.

A bit funny, a software library focused on cryptography, where security is an afterthought rather than proactive effort. I would consider the alternatives before going to OpenSSL.

mbrodersen 4y ago

https://www.microsoft.com/en-us/research/blog/project-everest-advancing-the-science-of-program-proof/ https://www.microsoft.com/en-us/research/blog/project-everes...

bheadmaster 4y ago

LibreSSL is a fork by OpenBSD crew that happened after the Heartbleed: https://www.libressl.org/ https://www.libressl.org/ Considering OpenBSD's reputation for proactive security, I'd say LibreSSL might be the best alternative out there.

michaelsbradley 4y ago
BearSSL is also worth a look: https://bearssl.org/ https://bearssl.org/
- speedgoose 4y ago
  It’s not actively developed and it doesn’t support TLSv1.3 though.
  - snvzz 4y ago
    But it is high quality, small and uses few resources, thus worth a mention.
mjhay 4y ago
Why hasn't LibreSSL taken off? I thought for sure it would after heartbleed. I assume it's mostly network effects/laziness, despite being fairly compatible (at least when it originally forked) and everyone already using OpenSSH from the openbsd as well.
- yjftsjthsd-h 4y ago
  Compatibility seems to be a difficulty: https://voidlinux.org/news/2021/02/OpenSSL.html https://voidlinux.org/news/2021/02/OpenSSL.html
- jessermeyer 4y ago
  Large web companies like Google implement their own encryption stack anyway. On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.
  - woodruffw 4y ago
    > Large web companies like Google implement their own encryption stack anyway. Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!). So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs). [1]: https://boringssl.googlesource.com/boringssl/ https://boringssl.googlesource.com/boringssl/
    - arianvanp 4y ago
      AWS maintains their own TLS stack: https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls
    - seadan83 4y ago
      Is this an argument for GPL? Seems like the big players came, saw, borrowed, and then did their own thing without contributing back. If this were my project, I would be inclined to archive it and do a GPL fork.
      - woodruffw 4y ago
        None of what happened with OpenSSL or its forks is incompatible with the GPL.