4 ms·

A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. https://www.libressl.org/ https://www.libressl.org/

flangola7 4y ago
Why isn't it used more?
- wolf550e 4y ago
  It's not 100% compatible with existing applications. IIRC Alpine Linux tried to switch and reverted back to openssl twice.
  - Arnavion 4y ago
    Gentoo and OPNsense also switched back (to be precise, stopped supporting both and now just support OpenSSL) for the same reason.
colmmacc 4y ago
I love LibreSSL and what they represent, but neither LibreSSL nor BoringSSL target all platforms or compatibility with OpenSSL, which can be a bit of a challenge ... and I don't think LibreSSL is likely to have FIPS certification. At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module. We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally. We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.
- mappu 4y ago
  Is your FIPS .dll/.so publicly available? It's surprisingly hard to get FIPS crypto in Golang on Windows.
traceroute66 4y ago
> A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. Ahem. Cough. Maybe I should leave this little link here for a patch published today ? https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...
- lucb1e 4y ago
  Going by the patch, that looks like the same bug as OpenSSL fixed. That's seven of the eight bugs not applicable. But this is just one round of patches, I have no further information or experience on/with LibreSSL or how the features compare. Just saying that one patch release does not mean either secure or insecure software.
- brynet 4y ago
  Commit message: https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2 https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2 > "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"
  - g0xA52A2A 4y ago
    This exemplifies one of the key reasons OpenBSD forked OpenSSL. For those who haven't seen it I'd recommend this presentation from Bob Beck[1], around the 10 minute mark he recounts fixing issues in the memory allocator which had been reported 4 years prior. Seems there's still a similar backlog sitting behind embargoes? [1] https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
deleted 4y ago
[deleted]
dochtman 4y ago
A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation: https://github.com/rustls/rustls https://github.com/rustls/rustls Some thoughts on lessons learned from other projects/vulnerabilities: https://docs.rs/rustls/latest/rustls/manual/index.html https://docs.rs/rustls/latest/rustls/manual/index.html
- Flocular 4y ago
  For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago. The project has potential but isn't quite ready for prime time yet.
  - oconnor663 4y ago
    Importantly, that C code (and assembly) is in the guts of crypto primitives. Those tend to be a lot easier to test than higher level X.509 parsing code, which I think is all done in safe Rust. But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.

flangola7 4y ago

Why isn't it used more?

wolf550e 4y ago
It's not 100% compatible with existing applications. IIRC Alpine Linux tried to switch and reverted back to openssl twice.
- Arnavion 4y ago
  Gentoo and OPNsense also switched back (to be precise, stopped supporting both and now just support OpenSSL) for the same reason.

colmmacc 4y ago

I love LibreSSL and what they represent, but neither LibreSSL nor BoringSSL target all platforms or compatibility with OpenSSL, which can be a bit of a challenge ... and I don't think LibreSSL is likely to have FIPS certification. At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module. We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally. We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.

mappu 4y ago
Is your FIPS .dll/.so publicly available? It's surprisingly hard to get FIPS crypto in Golang on Windows.

traceroute66 4y ago

> A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. Ahem. Cough. Maybe I should leave this little link here for a patch published today ? https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...

lucb1e 4y ago
Going by the patch, that looks like the same bug as OpenSSL fixed. That's seven of the eight bugs not applicable. But this is just one round of patches, I have no further information or experience on/with LibreSSL or how the features compare. Just saying that one patch release does not mean either secure or insecure software.
brynet 4y ago
Commit message: https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2 https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2 > "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"
- g0xA52A2A 4y ago
  This exemplifies one of the key reasons OpenBSD forked OpenSSL. For those who haven't seen it I'd recommend this presentation from Bob Beck[1], around the 10 minute mark he recounts fixing issues in the memory allocator which had been reported 4 years prior. Seems there's still a similar backlog sitting behind embargoes? [1] https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU

deleted 4y ago

[deleted]

dochtman 4y ago

A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation: https://github.com/rustls/rustls https://github.com/rustls/rustls Some thoughts on lessons learned from other projects/vulnerabilities: https://docs.rs/rustls/latest/rustls/manual/index.html https://docs.rs/rustls/latest/rustls/manual/index.html

Flocular 4y ago
For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago. The project has potential but isn't quite ready for prime time yet.
- oconnor663 4y ago
  Importantly, that C code (and assembly) is in the guts of crypto primitives. Those tend to be a lot easier to test than higher level X.509 parsing code, which I think is all done in safe Rust. But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.