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.
Swift is good for enterprises that standardized on Macs and ios devices, but there aren't many of those (yet).
I'm pretty sure Swift isn't ready on Windows, which is a shame because most "enterprises" standardized on Microsoft Windows and Active Directory.
Go (golang) has better support for a wider variety of platforms, but it has serious bugs on non-Linux platforms (as of go 1.7.1) that make it unsuitable for the enterprise. Basically, whatever customized Linux distro used at Google will likely get the most time from superstars on the go team. Also, calling C functions and callbacks from C can cause all sorts of issues, and the "cgo isn't go" mantra scares me when considering Windows desktops, etc. as a target platform.
C++ is making a comeback and I like C++14, but backwards compatibility and other factors make it too complex compared to other languages. But at least it supports all the major platforms and there's no worry it'll drop support for one due to vendor politics.
Rust looks promising from a cross-platform perspective like C++, but Rust is still way too new for the enterprise just like Swift. Perhaps in five years, it'll stand a chance in the enterprise (as much as C++) and without the complex baggage from inheriting decades of backward compatibility.
Who knows what'll happen by the time Swift or Rust is considered enterprise ready and truly cross platform -- maybe in 5 years, there will be a cross-platform native compiled F# that doesn't heavily favor one vendor's platform or nim might skyrocket out of obscurity -- who knows, but its fun to imagine and do some coding to make the future brighter.
Nobody is suggesting OpenBSD not being RedHat should be embarrassing.
However, it is not ideal to have a security-focused OS not directly provide binpatches for the base system and core libraries like libressl. Trusting OpenBSD.org is one thing, but trusting additional entities like mtier, etc. just to get security updates without having to compile is another.
FWIW, I think we should feel embarrassed about not giving more funding & time to OpenBSD given everything they already do for us.
The traditional means of patching is recompiling from source. That is the ONLY officially supported method.
This is just another convenient option. I fail to see the problem here.
If you want supported first-party binary security patches you should be using a project that provides that, such as FreeBSD, or just about any Linux distro that is not Gentoo.
I think there would be no problem with OpenBSD supporting an automated build-and-recompile tool, that would be perfectly fine and would stop people like me bitching about updates. Yeah yeah "it's trivial for you to write etc etc" but that's not the point: it's like saying that developing a text editor is simple so we shouldn't provide vi. This sort of thing is better designed and implemented by people who know the OS inside out, not by users.
For what it is worth the project does provide regular binary updates for both the base system and ports for -current (snapshots). If I were to guess, I would guess that one of the reasons that the project does not provide binary updates for -stable is because they are busy providing binary builds for -current. Since all the devs run -current, you can see which one they choose to invest their limited resources in.
Following current is pretty simple if you're happy to track snapshots, which are updated regularly (usually every week). If you're worried about stability, remember that -current turns into -stable twice a year, so current is pretty stable, and any issues that do crop up get fixed very quickly, because they impact the developers.
The problem is that the OpenBSD team doesn't want to write and maintain a tool like that, and they also don't want to utilize their sparse resources hosting the necessary package build infrastructure for all of the architectures they support. They are volunteers, so it really is up to them to work on whatever they want to work on.
Additionally, the amount of security patches we're talking about here is so small that just updating from source code really isn't that big of a deal for most people.
> it really is up to them to work on whatever they want to work on.
Sure, and it really is up to me to keep bitching :)
Besides, the contradiction here is that they are not all volunteers: M:Tier employs some of them exactly to do that job. So, they don't want to do it, but they'll do it if the price is right? Why can't this pricing be done transparently through OpenBSD, rather than some obscure third-party company?
If the problem is funding, why can't they do like RedHat or Oracle, who ask for money to provide automated updates? Oh yeah they do, but through m:tier for some sort of reason (tax? street rep? We can but speculate).
> just updating from source code really isn't that big of a deal for most people.
It's enough to keep the m:tier service running and people like me bitching, so clearly for a lot of people it is. It's enough that every other linux distro out there does it. Denying it over and over won't change that.
> Besides, the contradiction here is that they are not all volunteers: M:Tier employs some of them exactly to do that job. So, they don't want to do it, but they'll do it if the price is right? Why can't this pricing be done transparently through OpenBSD, rather than some obscure third-party company?
So you're begrudging some of the OpenBSD developers for having a day job? That is completely absurd. How are they supposed to feed themselves and their families?
Several of FreeBSD's core developers work for Apple. Red Hat employs a large chunk of the GNU and Linux ecosystems. Red Hat actually does something very similar to what M:Tier does.
M:Tier is really just another example of a company that is providing value added support over the offerings of a freely available open source project. They are even generous enough to provide their openup script under an open source license and binary updates free of charge for the most recent version of OpenBSD. I think that is a pretty good deal for everyone involved.
> So you're begrudging some of the OpenBSD developers for having a day job?
Au contraire, I begrudge why they have to do their OpenBSD-related day-job, working on what is basically an essential part of any modern OS (update distribution infrastructure), outside of the official project and with no official endorsement. It devalues them, it devalues the project and only invites speculation on the motives of such arrangements.
> Several of FreeBSD's core developers work for Apple.
Do I have to pay an Apple subscription to get automatic FreeBSD updates? No.
> Red Hat employs a large chunk of the GNU and Linux ecosystems
Sure, and I do have to pay to get automated updates from them, but at least I know they are official. M:tier packages are not official but sort-of wink-wink-nudge-nudge. For a project living and dying on trust, it's a poor show.
> M:Tier is really just another example of a company that is providing value added support
Sure, but my point is that OpenBSD is a pretty isolated example of a project that actively refuses to provide what any comparable project provides, with very flimsy excuses. This leaves the space open for m:tier to make a buck that really belongs to the OpenBSD project. IMHO the project (which is otherwise extremely fond of reminding us that they are short of money) gets shortchanged here, even if some individuals might not be.
> Sure, and I do have to pay to get automated updates from them, but at least I know they are official. M:tier packages are not official but sort-of wink-wink-nudge-nudge. For a project living and dying on trust, it's a poor show.
Well that is because the official and ONLY supported way to patch an OpenBSD system is to compile from source. Like pretty much all of OpenBSD's documentation, the instructions to do so are very clear.
M:Tier provides a service that is merely a convenience. It is not essential and I would suspect that only a small fraction of OpenBSD users even make use of their openup script and binary package updates at all.
I suspect you are being purposely obtuse and cannot understand that the way in which your favorite $OS is not the only right way to do things.
The OpenBSD project has no obligation to provide binary updates. They provide source code patches and clear instructions of how to apply them. This is actually better for security because you can actually see what is being changed by the patch if you know a little bit about programming.
> I suspect you are being purposely obtuse and cannot understand that the way in which your favorite $OS is not the only right way to do things.
The OpenBSD project actively refuses to provide a service that pretty much any other OS project provides, so that a commercial entity can make a buck, and I am the one being purposely obtuse?
> only a small fraction of OpenBSD users even make use of their openup script
Until it relies on m:tier servers, of course. Why would I have to trust an unrelated company to update a security-conscious OS?
> This is actually better for security
This is actually worse for security because it relies on sysadmins being human robots that constantly check errata, or being faultless programmers who will never botch a hacked-together-enough-that-works custom script to get errata and apply patches. But hey, don't take it from me, hear it from m:tier themselves: "Keeping your installed OpenBSD packages up to date is hard and time-consuming. Nobody wants to read the mailing lists to spot security fixes and/or updates never mind wanting to build new packages from their ports tree and manually install them on each of their servers and/or desktops."
But the number of web frameworks, etc. for Rust sucks compared to that of older languages like Go. Go 1.0 was released in early 2012 and Rust 1.0 in May 2015.
Rust is more verbose than Go, but Go's FFI to functions written in C isn't as efficient and since "cgo isn't go", I'm not sure cgo covered by Go 1.0 compatibility guarantee.
On the other hand, Go has tons of "batteries included" plus web frameworks so that is pretty awesome to have on stable platforms (I don't consider Windows a stable platform for Go and got burned several times, but Go works great on FreeBSD & Ubuntu.)
I suspect Go & Swift won't have robust reliability on Windows (compared to other platforms) but they'll be rock solid on the ones they favor. Rust may have better prospects regarding this, but Rust still too new this year for web server language -- wait until MIR is integrated and a couple more releases after that.
Servo would be more compelling for use with commercial software if had MIT or Apache license. The MPL isn't as bad as GPL but still isn't as generous to the developer as MIT or Apache. With the right license, Servo would be a slam dunk for replacing CEF in commercial software that prohibits reversing or tampering.
The license isn't really up for negotiation, but I'm curious what you think there is to gain with more liberal licensing? All the competing engines are either equivalently or more restrictively licensed, no?
The Go programming language doesn't compile to C. Compiling Go is faster than compiling C.
If Go transpiled into C code first, and then had to compile resulting C code, then that entire process would be slower.
The Nim programming language compiles to C, so you may want to reach out and ask their community. It used to be called Nimrod, but is now Nim.
The Rust programming language leverages LLVM instead of transpiling to C, so you may want to take a look at how that is done. A recent post about Rust MIR is well-written and is an enjoyable read for anyone interested in compilers.
1. that post is from Feb 8, 2016
2. nanomsg 1.0 was released on June 10, 2016
After nanomsg 1.0 release, recent activity on github includes:
8 days ago -- fixes #828 Add logical connections to UDP RFC
9 days ago -- fixes #827 nanomsg zerotier mapping rfc errors
11 days ago -- fixes #825 Extra tests in pipe.c gdamore committed 11 days ago
15 days ago -- fixes #800 accept4 not implemented on all systems
15 days ago -- fixes #783 WS transport - not connectable from Firefox
16 days ago -- fixes #821 NN_WS_HANDSHAKE_CRLF is silly
And etc.