
Alpine Edge has switched to libressl - gbrown_
http://lists.alpinelinux.org/alpine-devel/5463.html
======
montyedwards
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
> 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?

~~~
stock_toaster

      > (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.

~~~
wolf550e
TLS cipher suites have five parts:

    
    
      1. key exchange:
        PSK - for embedded only
        RSA - obsolete because it doesn't provide PFS
        DHE - secure only if 2048 bits and up
        ECDHE - usually using P-256, secure
        ECDHE with Curve25519, called "X25519" - secure
        CECPQ1 - Google experiment in post quantum crypto
      2. authentication:
        PSK - for embedded only
        RSA encryption/decryption - obsolete because it doesn't provide PFS
        RSA signing and verification - secure if keys are 2048 bits and up
        ECDSA signing and verification - usually over P-256, secure
        EdDSA signing and verification - draft standard, uses Curve25519 and Curve448, secure
      3. cipher (for confidentiality):
        RC4 - disallowed
        3DES - obsolete because of sweet32
        AES-128 - good, requires AES hardware to be both fast and secure
        AES-256 - same as AES-128 but is required for post-quantum and against parallel attacks on many keys
        CHACHA20 - good, is fast on generic hardware
      4. MAC (to protect against tampering which usually breaks confidentiality):
        HMAC-MD5 - obsolete
        HMAC-SHA1 - ok
        HMAC-SHA256 and HMAC-SHA384 - no more secure than SHA1 for this use case
        GCM - faster than HMAC, requires CLMUL CPU instruction to be fast
        POLY-1305 - fast and secure on generic hardware
      5. KDF used to generate symmetric keys:
        MD5+SHA1 - obsolete, probably ok
        HMAC-SHA1 - ok
        HMAC-SHA256 and HMAC-SHA384 - no more secure than SHA1 for this use case
    

Originally 5 was the same as 4 and was not specified separately. Also, many
details omitted.

But anyway, chacha20-poly1305 is actually one of these [1]:

    
    
       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
       TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
       TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
       TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
       TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
       TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256
    

and you use only the first two from the list. The "ECDHE" part can be regular
ECDHE with P-256 or X25519.

1 -
[https://tools.ietf.org/html/rfc7905#section-2](https://tools.ietf.org/html/rfc7905#section-2)

~~~
djsumdog
This is a really good list. Those long cryptic string constants make a lot
more sense now.

------
cm3
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++

~~~
zeveb
> 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++

You're probably right, but I hate that the work free software developers
contribute to LLVM & clang will end up being taken proprietary by the likes of
Apple. With GCC one knows that the users of one's code will always have the
ability to run, read, modify & share that code, rather than having their
rights stripped away.

~~~
Sanddancer
Yes, some people won't give back. However, a project like llvm/clang, most
people do give back because sharing is cool, and also it makes their job
easier because they don't have to repatch for every new version of the
compiler. Sony's team developing the Playstation 4 wished at times they could
use newer versions of llvm/clang for their software, but couldn't because
their version had so many patches [1]. Because of this, after the PS4 was
released, Sony developers sent a bunch of patches upstream, and work pretty
closely with the rest of the developers. Some bits and pieces may not get
merged upstream, but that's the same for any project, GPL or not.

[1] [http://llvm.org/devmtg/2013-11/slides/Robinson-
PS4Toolchain....](http://llvm.org/devmtg/2013-11/slides/Robinson-
PS4Toolchain.pdf)

------
marios
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.

~~~
secure
> 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_
What's the general etiquette regarding "bumping" Debian bugs?

------
jcoffland
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
As with most security-related projects, it takes very little to have the trust
house of cards fumble.

------
akerro
[https://www.openbsd.org/donations.html](https://www.openbsd.org/donations.html)

------
_asummers
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.

~~~
mrweasel
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.

------
nailer
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
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
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
Go see the talk on the reasons for the LibreSSL fork.

Don't just fear the worst, know the worst.

~~~
mrweasel
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)

~~~
protomyth
This is the other one given by Bob Beck
[https://www.youtube.com/watch?v=GnBbhXBDmwU](https://www.youtube.com/watch?v=GnBbhXBDmwU)
\- bit different conversation, but same slides

------
pilif
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.

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

~~~
gbrown_
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.

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

~~~
zeveb
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
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)

------
StreamBright
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
Regardless how much love it gets, it will never be safe.

[https://groups.google.com/forum/m/#!msg/boring-
crypto/48qa1k...](https://groups.google.com/forum/m/#!msg/boring-
crypto/48qa1kWignU/o8GGp2K1DAAJ)

~~~
qwertyuiop924
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.

~~~
whyever
What about switching to Rust?
[https://github.com/ctz/rustls](https://github.com/ctz/rustls)

~~~
qwertyuiop924
Impressive, but I'm willing to bet nobody will want to rewrite _all_ of
open/libreSSL, one of the most popular cryptographic libraries out there, in
Rust.

~~~
steveklabnik
[https://crates.io/crates/ring](https://crates.io/crates/ring) , which is
BoringSSL, being ported over. Eventually it'll be Rust and asm.

(And is what rustls uses)

~~~
qwertyuiop924
Well then, maybe. Consider me corrected.

------
qwertyuiop924
Oh good. Finally.

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

