10 ms·

Alpine Edge has switched to libressl

236 points by gbrown_ 10y ago

marios 10y ago
I recently built LibreSSL to replace OpenSSL on my laptop that runs ArchLinux. After installing, pretty much every thing works seamlessly so far. I rebuilt python because apparently the ssl module looks for RAND_egd (or something of the vein that LibreSSL has removed - and I didn't compile it with a shim). Other than that, dig is broken on my system ("ENGINE_by_id failed") although I have not bothered to fix it since drill works fine. It's nice to see LibreSSL being picked up by Linux distributions. I wish other major distros did this (I'm looking at you Debian). IIRC, Alpine was often used to built docker images. If that's still the case, I'd say it's good news.
- guitarbill 10y ago
  It does seem like a very practical solution. Hopefully we'll see this in the bigger distros once the smaller distros prove it's doable.
- microcolonel 10y ago
  Worried about OpenSSL, but fine with running drill? ;- ) drill segfaults for me on a regular basis.
  - marios 10y ago
    To be fair, I'm not a heavy user of either dig or drill. I use it mostly to check that my local resolver (unbound) is still responding, and that the DHCP distributed resolver isn't handing out garbage. My usage probably falls into the well tested part of the code I guess.
- secure 10y ago
  > I'm looking at you Debian You can read up on the packaging efforts at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 — there hasn’t been any activity in a while, so if you have something to add, please post there (but please refrain from +1/me too posts).
  - voltagex_ 10y ago
    What's the general etiquette regarding "bumping" Debian bugs?
- edwintorok 10y ago
  There is a LibreSSL overlay in Gentoo, which patches various software that would otherwise fail to build with LibreSSL, currently they are these packages: dev-qt/qtcore dev-qt/qtnetwork net-misc/socat It used to be a bit painful to setup, but things have improved, now I only need this in make.conf: USE="... libressl" CURL_SSL="libressl" And this to mask it: /etc/portage/package.mask/openssl dev-libs/openssl There is still some software that would fail to install (with a conflict between openssl and libressl), but none that I need currently.
nailer 10y ago
I tried libre on OS X (it's on Homebrew), the binary is around half the size of the equivalent OpenSSL release. Kudos to Libre for stripping out so much junk - OSs that people don't use and ciphers that people shouldn't be using - and producing a more auditable sensible codebase.
- majewsky 10y ago
  I would hope that "OSs that people don't use" do not contribute to the binary size on a different OS, since the relevant source files are just not built for the traget OS. Of course, the operative word in this sentence is "hope".
  - gpvos 10y ago
    LibreSSL got the OpenBSD treatment, so the base version is for OpenBSD only, and then there's a portable version for other OSs. For OpenSSL, I wouldn't know, but fear the worst.
    - qwertyuiop924 10y ago
      Go see the talk on the reasons for the LibreSSL fork. Don't just fear the worst, know the worst.
      - mrweasel 10y ago
        Bob Becks talk on LibreSSL is really informative, scary and entertaining. https://www.youtube.com/watch?v=-4psTQ1sX7s https://www.youtube.com/watch?v=-4psTQ1sX7s
        qwertyuiop924 10y ago
        That's the one I was talking about. Sorry, I didn't have the link on me.
        protomyth 10y ago
_asummers 10y ago
How has LibreSSL stood up lately to the relatively frequent CVEs in OpenSSL the past few months? I know the initial months were a frenzy of removing garbage and classes of problems (#yadf) that preempted a few CVEs, but I haven't been paying attention to the commit logs to know if it was also susceptible to them.
- deleted 10y ago
  [deleted]
- mrweasel 10y ago
  A quick look through the release notes: https://www.libressl.org/releases.html https://www.libressl.org/releases.html seems to indicate that they've only been affected by six CVEs since October 2015. I haven't followed LibreSSL recently, but previously many of the CVEs that affected OpenSSL are for features that LibreSSL ripped out.
- noinsight 10y ago
  Wikipedia has a comparison list: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
StreamBright 10y ago
I hope LibreSSL gets the traction it needs in the coming months or years. There are great wins using it and it is worth to move over the FOSS stack to use LibreSSL instead of OpenSSL and reduce the number security bugs we are facing today.
- pjmlp 10y ago
  Regardless how much love it gets, it will never be safe. https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...
  - qwertyuiop924 10y ago
    Yes, that's a valid argument, but if you think everybody will switch to Oberon any time soon, prepare to be disappointed. In any case, LSSL can be a heck of a lot safer than OSSL, and, in fact, already is.
    - pjmlp 10y ago
      Oberon ship has sailed long time ago. I still like it, but that is just a nostalgia thing. It was a great experience in the mid-90's, but a modern language in 2016 requires much more that what it offered, hence why I eventually got disappointed with Go's feature set. I would rather see Ada, SPARK, Swift, Rust, ATS, Idris, F*, Formal Methods or whatever else that ensures that our code runs on top of solid foundations.
      - qwertyuiop924 10y ago
        I'm not sure I entirely agree, but fair 'nuff. In any case, my point still stands: People aren't going to rewrite all that C code. The best we can hope for is for some UB to actually be standardized, so that the sociopaths who write the compilers are reigned in a bit.
        pjmlp 10y ago
cm3 10y ago
I'm glad that VoidLinux isn't anymore the only distro in town that's switched to LibreSSL. And with Docker defaulting to Alpine, more OpenSSL/LibreSSL compatibility fixes will trickle into upstream projects. This is good news. EDIT: Next, I predict a linux distro will, after having switched to musl, also support llvm/compiler-rt/libunwind/libc++ as base toolchain instead of gcc/libgcc/libstdc++
- rvense 10y ago
  Can Clang/LLVM compile Linux itself?
  - qznc 10y ago
    No. https://llvm.org/bugs/show_bug.cgi?id=4068 https://llvm.org/bugs/show_bug.cgi?id=4068 https://www.phoronix.com/scan.php?page=news_item&px=Clang-The-Kernel-2016 https://www.phoronix.com/scan.php?page=news_item&px=Clang-Th...
  - cm3 10y ago
    A not-yet-fully-upstreamed branch maintained by the linux foundation can, yes. But just like FreeBSD has to make an exception to build certain packages with gcc, the kernel can be exclusively built with gcc for the time being. If you're not using musl libc, I guess glibc might also require gcc but that's an unsurprising coupling, likely due to gcc C extensions in use. The important points are that such a distro will quickly improve the situation of clang and libc++ compatibility across the board and exercise the alternative toolchain a lot more. In fact, there isn't much incompatible code out there, and it's been fixed mostly due to efforts of Debian, FreeBSD and of course Apple and Bitrig and Gentoo. FreeBSD is the leading force behind making lld a viable alternative to binutils ld and so far ThinLTO (which works with binutils, to be clear) is exclusive to llvm, so there's that. https://aur.archlinux.org/packages/llvmlinux-git/ https://aur.archlinux.org/packages/llvmlinux-git/ http://llvm.linuxfoundation.org/index.php/Main_Page http://llvm.linuxfoundation.org/index.php/Main_Page
    - bogomipz 10y ago
gtt 10y ago
The only thing I miss in libreSSL is SRP. How would hn crowd recommend to pick alternative to SRP?
- zeveb 10y ago
  Was the issue that the OpenSSL SRP stuff was wonky, or that the LibreSSL guys hate SRP? I hope that it's the latter, because SRP is a really good protocol. As an aside, does anyone know if there's been progress with elliptic curve SRP? The last literature review I did was … shaky.
  - Rafert 10y ago
    They looked for maintainers[0] and later removed it when the OpenSSL SRP code was considered bad and turned out to be vulnerable as well[1] [0]: http://undeadly.org/cgi?action=article&sid=20140429062932 http://undeadly.org/cgi?action=article&sid=20140429062932 [1]: http://www.openbsd.org/papers/eurobsdcon2014-libressl.html http://www.openbsd.org/papers/eurobsdcon2014-libressl.html
akerro 10y ago
https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html
pilif 10y ago
I'm running nginx linked against LibreSSL on our frontend since February. We've not seen any issues and LibreSSL has been a perfect drop-in replacement for OpenSSL so far.
qwertyuiop924 10y ago
Oh good. Finally. I want to see OSSL burn. Because it sure as heck doesn't deserve to live.
montyedwards 10y ago
I'm currently evaluating LibreSSL for use in data protection software I licensed to a large company. The optional libtls API bundled with LibreSSL is a really simple wrapper API that is secure by default. And it was a breeze to build on Windows because they use cmake (just need to download released bundle rather than from git to avoid problems.) A couple of the optional libtls functions don't work on Windows (tls_load_file), but 100% of OpenSSL-1.0.1+ api functions I tried so far worked fine. For me, the biggest downside is LibreSSL doesn't support X25519 yet, while BoringSSL and OpenSSL both support it. And BoringSSL is starting to get easier to use with other software like nginx without messy patches. Hopefully, X25519 will be added as a beta feature during LibreSSL 2.5.x and released as stable in 2.6. If you have time, take a look at https://github.com/libressl-portable/openbsd https://github.com/libressl-portable/openbsd And email patches to: tech@openbsd.org Edited: tls_load_file instead of tls_read
- jamiesonbecker 10y ago
  > LibreSSL doesn't support X25519 yet ouch, that's pretty core. (We use it for storage crypto in the Userify on-prem server [ssh key/sudo management] management servers, although the managed nodes themselves just use 'regular' TLS/https for communication.) That means we can't switch to Alpine pretty soon, which I was contemplating for our AWS Marketplace instances in order to move to a distro with a smaller footprint. (X25519 is also the default between Chrome and web servers: https://www.chromestatus.com/feature/5682529109540864 https://www.chromestatus.com/feature/5682529109540864 ) Any idea on when X25519 will be added?
  - montyedwards 10y ago
    No idea when LibreSSL will add X25519 or X448, as defined in RFC 7748 - Elliptic Curves for Security. Here's RFC 7748 https://tools.ietf.org/html/rfc7748 https://tools.ietf.org/html/rfc7748 Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748 https://www.rfc-editor.org/errata_search.php?rfc=7748
  - stock_toaster 10y ago
    > (X25519 is also the default between Chrome and > web servers: https://www.chromestatus.com/feature/5682529109540864 ) I thought chacha20/poly was the default. That's what I get when I connect to https://www.google.com https://www.google.com with chrome (chrome-53) at any rate.
bluejekyll 10y ago
This is a really short note. I'm curious, was BoringSSL evaluated at all as an alternate substitute?
- gbrown_ 10y ago
  LibreSSL aims to be a mostly API compatible replacement for OpenSSL, BoringSSL does not. Literally the first text on the BoringSSL web page. BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
jcoffland 10y ago
It's worth remembering that OpenSSL has faithfully served the community for many years. Most of those years with almost no financial support. Few projects would survive the scrutiny they have undergone. These guys deserve some credit.
- leonatan 10y ago
  As with most security-related projects, it takes very little to have the trust house of cards fumble.

236 points by gbrown_ 10y ago

I recently built LibreSSL to replace OpenSSL on my laptop that runs ArchLinux. After installing, pretty much every thing works seamlessly so far. I rebuilt python because apparently the ssl module looks for RAND_egd (or something of the vein that LibreSSL has removed - and I didn't compile it with a shim). Other than that, dig is broken on my system ("ENGINE_by_id failed") although I have not bothered to fix it since drill works fine. It's nice to see LibreSSL being picked up by Linux distributions. I wish other major distros did this (I'm looking at you Debian). IIRC, Alpine was often used to built docker images. If that's still the case, I'd say it's good news.

guitarbill 10y ago
It does seem like a very practical solution. Hopefully we'll see this in the bigger distros once the smaller distros prove it's doable.
microcolonel 10y ago
Worried about OpenSSL, but fine with running drill? ;- ) drill segfaults for me on a regular basis.
- marios 10y ago
  To be fair, I'm not a heavy user of either dig or drill. I use it mostly to check that my local resolver (unbound) is still responding, and that the DHCP distributed resolver isn't handing out garbage. My usage probably falls into the well tested part of the code I guess.
secure 10y ago
> I'm looking at you Debian You can read up on the packaging efforts at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 — there hasn’t been any activity in a while, so if you have something to add, please post there (but please refrain from +1/me too posts).
- voltagex_ 10y ago
  What's the general etiquette regarding "bumping" Debian bugs?
edwintorok 10y ago
There is a LibreSSL overlay in Gentoo, which patches various software that would otherwise fail to build with LibreSSL, currently they are these packages: dev-qt/qtcore dev-qt/qtnetwork net-misc/socat It used to be a bit painful to setup, but things have improved, now I only need this in make.conf: USE="... libressl" CURL_SSL="libressl" And this to mask it: /etc/portage/package.mask/openssl dev-libs/openssl There is still some software that would fail to install (with a conflict between openssl and libressl), but none that I need currently.

nailer 10y ago

I tried libre on OS X (it's on Homebrew), the binary is around half the size of the equivalent OpenSSL release. Kudos to Libre for stripping out so much junk - OSs that people don't use and ciphers that people shouldn't be using - and producing a more auditable sensible codebase.

majewsky 10y ago
I would hope that "OSs that people don't use" do not contribute to the binary size on a different OS, since the relevant source files are just not built for the traget OS. Of course, the operative word in this sentence is "hope".
- gpvos 10y ago
  LibreSSL got the OpenBSD treatment, so the base version is for OpenBSD only, and then there's a portable version for other OSs. For OpenSSL, I wouldn't know, but fear the worst.
  - qwertyuiop924 10y ago
    Go see the talk on the reasons for the LibreSSL fork. Don't just fear the worst, know the worst.
    - mrweasel 10y ago
      Bob Becks talk on LibreSSL is really informative, scary and entertaining. https://www.youtube.com/watch?v=-4psTQ1sX7s https://www.youtube.com/watch?v=-4psTQ1sX7s
      - qwertyuiop924 10y ago
        That's the one I was talking about. Sorry, I didn't have the link on me.
      - protomyth 10y ago

_asummers 10y ago

How has LibreSSL stood up lately to the relatively frequent CVEs in OpenSSL the past few months? I know the initial months were a frenzy of removing garbage and classes of problems (#yadf) that preempted a few CVEs, but I haven't been paying attention to the commit logs to know if it was also susceptible to them.

deleted 10y ago
[deleted]
mrweasel 10y ago
A quick look through the release notes: https://www.libressl.org/releases.html https://www.libressl.org/releases.html seems to indicate that they've only been affected by six CVEs since October 2015. I haven't followed LibreSSL recently, but previously many of the CVEs that affected OpenSSL are for features that LibreSSL ripped out.
noinsight 10y ago
Wikipedia has a comparison list: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...

StreamBright 10y ago

I hope LibreSSL gets the traction it needs in the coming months or years. There are great wins using it and it is worth to move over the FOSS stack to use LibreSSL instead of OpenSSL and reduce the number security bugs we are facing today.

pjmlp 10y ago
Regardless how much love it gets, it will never be safe. https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...
- qwertyuiop924 10y ago
  Yes, that's a valid argument, but if you think everybody will switch to Oberon any time soon, prepare to be disappointed. In any case, LSSL can be a heck of a lot safer than OSSL, and, in fact, already is.
  - pjmlp 10y ago
    Oberon ship has sailed long time ago. I still like it, but that is just a nostalgia thing. It was a great experience in the mid-90's, but a modern language in 2016 requires much more that what it offered, hence why I eventually got disappointed with Go's feature set. I would rather see Ada, SPARK, Swift, Rust, ATS, Idris, F*, Formal Methods or whatever else that ensures that our code runs on top of solid foundations.
    - qwertyuiop924 10y ago
      I'm not sure I entirely agree, but fair 'nuff. In any case, my point still stands: People aren't going to rewrite all that C code. The best we can hope for is for some UB to actually be standardized, so that the sociopaths who write the compilers are reigned in a bit.
      - pjmlp 10y ago

cm3 10y ago

I'm glad that VoidLinux isn't anymore the only distro in town that's switched to LibreSSL. And with Docker defaulting to Alpine, more OpenSSL/LibreSSL compatibility fixes will trickle into upstream projects. This is good news. EDIT: Next, I predict a linux distro will, after having switched to musl, also support llvm/compiler-rt/libunwind/libc++ as base toolchain instead of gcc/libgcc/libstdc++

rvense 10y ago
Can Clang/LLVM compile Linux itself?
- qznc 10y ago
  No. https://llvm.org/bugs/show_bug.cgi?id=4068 https://llvm.org/bugs/show_bug.cgi?id=4068 https://www.phoronix.com/scan.php?page=news_item&px=Clang-The-Kernel-2016 https://www.phoronix.com/scan.php?page=news_item&px=Clang-Th...
- cm3 10y ago
  A not-yet-fully-upstreamed branch maintained by the linux foundation can, yes. But just like FreeBSD has to make an exception to build certain packages with gcc, the kernel can be exclusively built with gcc for the time being. If you're not using musl libc, I guess glibc might also require gcc but that's an unsurprising coupling, likely due to gcc C extensions in use. The important points are that such a distro will quickly improve the situation of clang and libc++ compatibility across the board and exercise the alternative toolchain a lot more. In fact, there isn't much incompatible code out there, and it's been fixed mostly due to efforts of Debian, FreeBSD and of course Apple and Bitrig and Gentoo. FreeBSD is the leading force behind making lld a viable alternative to binutils ld and so far ThinLTO (which works with binutils, to be clear) is exclusive to llvm, so there's that. https://aur.archlinux.org/packages/llvmlinux-git/ https://aur.archlinux.org/packages/llvmlinux-git/ http://llvm.linuxfoundation.org/index.php/Main_Page http://llvm.linuxfoundation.org/index.php/Main_Page
  - bogomipz 10y ago

gtt 10y ago

The only thing I miss in libreSSL is SRP. How would hn crowd recommend to pick alternative to SRP?

zeveb 10y ago
Was the issue that the OpenSSL SRP stuff was wonky, or that the LibreSSL guys hate SRP? I hope that it's the latter, because SRP is a really good protocol. As an aside, does anyone know if there's been progress with elliptic curve SRP? The last literature review I did was … shaky.
- Rafert 10y ago
  They looked for maintainers[0] and later removed it when the OpenSSL SRP code was considered bad and turned out to be vulnerable as well[1] [0]: http://undeadly.org/cgi?action=article&sid=20140429062932 http://undeadly.org/cgi?action=article&sid=20140429062932 [1]: http://www.openbsd.org/papers/eurobsdcon2014-libressl.html http://www.openbsd.org/papers/eurobsdcon2014-libressl.html

akerro 10y ago

https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html

pilif 10y ago

I'm running nginx linked against LibreSSL on our frontend since February. We've not seen any issues and LibreSSL has been a perfect drop-in replacement for OpenSSL so far.

qwertyuiop924 10y ago

Oh good. Finally. I want to see OSSL burn. Because it sure as heck doesn't deserve to live.

montyedwards 10y ago

I'm currently evaluating LibreSSL for use in data protection software I licensed to a large company. The optional libtls API bundled with LibreSSL is a really simple wrapper API that is secure by default. And it was a breeze to build on Windows because they use cmake (just need to download released bundle rather than from git to avoid problems.) A couple of the optional libtls functions don't work on Windows (tls_load_file), but 100% of OpenSSL-1.0.1+ api functions I tried so far worked fine. For me, the biggest downside is LibreSSL doesn't support X25519 yet, while BoringSSL and OpenSSL both support it. And BoringSSL is starting to get easier to use with other software like nginx without messy patches. Hopefully, X25519 will be added as a beta feature during LibreSSL 2.5.x and released as stable in 2.6. If you have time, take a look at https://github.com/libressl-portable/openbsd https://github.com/libressl-portable/openbsd And email patches to: tech@openbsd.org Edited: tls_load_file instead of tls_read

jamiesonbecker 10y ago
> LibreSSL doesn't support X25519 yet ouch, that's pretty core. (We use it for storage crypto in the Userify on-prem server [ssh key/sudo management] management servers, although the managed nodes themselves just use 'regular' TLS/https for communication.) That means we can't switch to Alpine pretty soon, which I was contemplating for our AWS Marketplace instances in order to move to a distro with a smaller footprint. (X25519 is also the default between Chrome and web servers: https://www.chromestatus.com/feature/5682529109540864 https://www.chromestatus.com/feature/5682529109540864 ) Any idea on when X25519 will be added?
- montyedwards 10y ago
  No idea when LibreSSL will add X25519 or X448, as defined in RFC 7748 - Elliptic Curves for Security. Here's RFC 7748 https://tools.ietf.org/html/rfc7748 https://tools.ietf.org/html/rfc7748 Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748 https://www.rfc-editor.org/errata_search.php?rfc=7748
- stock_toaster 10y ago
  > (X25519 is also the default between Chrome and > web servers: https://www.chromestatus.com/feature/5682529109540864 ) I thought chacha20/poly was the default. That's what I get when I connect to https://www.google.com https://www.google.com with chrome (chrome-53) at any rate.

bluejekyll 10y ago

This is a really short note. I'm curious, was BoringSSL evaluated at all as an alternate substitute?

gbrown_ 10y ago
LibreSSL aims to be a mostly API compatible replacement for OpenSSL, BoringSSL does not. Literally the first text on the BoringSSL web page. BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

jcoffland 10y ago

It's worth remembering that OpenSSL has faithfully served the community for many years. Most of those years with almost no financial support. Few projects would survive the scrutiny they have undergone. These guys deserve some credit.

leonatan 10y ago
As with most security-related projects, it takes very little to have the trust house of cards fumble.