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.
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 )
I too would definitely be interested if there's any sort of milestone planned for X25519. There are a couple of open enhancement requests on it in both openbsd and portable [1,2] dating to before ratification of RFC 7748 (or Chrome 50), but no assignees yet. I also don't see any discussion on the libressl public mailing list archives at marc.info, though I'm not sure if that's complete. It seems like it may become an ever bigger breaking issue for a lot of folks as support becomes more widespread following standardization, inclusion in OpenSSL 1.1.0, and increasing major browser/OS support.
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]:
ChaCha20-Poly1305 is a symmetric cipher, used for encrypting your traffic. X25519 is an key exchange protocol using asymmetric cryptography, and is used in during connection setup to establish keys for the symmetric cipher.
X25519 would appear under "Key exchange" and ChaCha20-poly1305 under "Cipher Suite"
With Chromium I just get ECDHE_RSA and AES_128_GCM, anyway.
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
And email patches to: tech@openbsd.org
Edited: tls_load_file instead of tls_read