LibreSSL, and the new libtls API | Hacker News Reader

LibreSSL, and the new libtls API

openbsd.org

185 pointsglass-66 comments

I remember so many people in the open source world angry or annoyed with the OpenBSD team for forking LibreSSL. The fact is it's more than a year later, several more high-risk vulnerabilities discovered, and OpenSSL has yet to make any noticable changes. Meanwhile those same vulnerabilities were fixed in LibreSSL due to code cleanup and removal.[1]

No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.

[1] - https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...

I recall a lot of renewed energy a year ago into improving OpenSSL, including funding and support. Has that panned out as I would have hoped? LibreSSL improvements are highly visible (and exciting) but I expect I would have overlooked any OpenSSL improvements.

There has been a whole bunch of changes and cleanups in OpenSSL, it's just stuff like that doesn't seem to pick up as much traction here (they don't really have the blogging / communicating thing down so well, I guess?)

This is the current roadmap. https://www.openssl.org/policies/roadmap.html Picking out a few highlights: * "Objective met (2015): The FIPS code has been removed from the master branch, and will be re-integrated more cleanly during a future validation. " * "Objective met (2015): All use of dynamic memory allocation has been cleaned up and made consistent, and the internal memory pool has been removed. "

Under Coding Style: * "Objective met (2015): All release branches were reformatted using a script included in the release." (so all code now adheres to a consistent style at least, which is a good starting point)

And amongst their targeted goals now: * Legacy platforms that are unlikely to have wide deployment will be removed from the code. .. but .. * Non-supported platforms requiring regular maintenance activities will eventually be removed from the code after first seeking community owners to support the platforms in platform specific repositories.

Not convinced that's necessarily the right route, but I can appreciate where they're coming from.

I'm curious what circles you run in in the open source world. In my little corner of it, most everyone had nothing but excitement and support for LibreSSL.

I do seem to recall some complaining about the tone the OpenBSD developers used, but they where not really getting anywhere by being nice either. Also some complaining about them not helping to fix OpenSSL instead.

I was employed at a large open-source organization at the time of the fork. A conversation I participated in was specifically along the lines of (broad paraphrasing here) "They should be contributing their changes back to OpenSSL versus forking".

While attending a security conference in Vancouver earlier this year, someone commented that they thought the OpenBSD team was childish for forking LibreSSL, and several people chimed in with agreement.

Of course this is all hear-say for you, and your experiences may vary. I've met more than a handful of people who did not like the fork. There are lots of people in the world, and they all have different opinions.

OpenSSL wouldn't have accepted a lot of changes. Dropping legacy OS support or not caring about FIPS for examples.

So, forking is pretty much the only way to do proper code cleanup in a timely fashion, right?

If you don't, people still clamor for legacy support and bug-for-bug compatibility. A fork is the only way of truly signalling "We aren't going to support our old mistakes anymore."

New features don't need forks, but cleaning up raging stupid and cruft does.

IMHO, there is a time an place for everything. Sometimes forking is a good idea sometimes not.

When you want to make idealogcal changes to an existing codebase that does not mesh with the idealologies of the maintainer(s), forking is a great way to make your changes happen. Time will tell if your ideas were good ones. That and how well your maintain and promote your fork. :-)

In the case of OpenSSL vs LibreSSL, it appears the OpenBSD team made a great call and they are making it work really well. As for if anyone else agrees and adopts it, only time will tell.

> "They should be contributing their changes back to OpenSSL versus forking".

I suppose that this attitude comes from people who think the fork happened solely because of Heartbleed, when the real reasons are a little more intricate[0] but the straw that broke the camels back was the discovery that OpenSSL had known about certain bugs and let patches to fix them rot in their bug tracker for years. It's hard to contribute changes back when a project won't take patches.

OpenSSL could have taken LibreSSL's changes if they wanted to, it's all public in the OpenBSD source tree, but they haven't.

[0] http://www.tedunangst.com/flak/post/origins-of-libressl

Great write-up. Thanks for sharing. :-)

One of the big things they did was cut out enormous amounts of legacy code. Code that someone somewhere might be using. Since they were basically just making LibreSSL for themselves they didn't have to care about that and could be much more free with the changes.

The OpenSSL developers would have a much tougher time dropping MSDOS and VMS and OS/360 support because there are still a couple of people who need it.

Having spent years working with openssl code, there's nothing you can do to save it but take a rusty axe to it.

Every horrifying thing in there is justifiable because "someone might be using it". Not enough reason to risk the security of every net-connected Unix over.

How about big-endian x86, in case anyone makes a processor that operates that way? At least OpenSSL is ready!

I think that has more to do with code hygiene.

Problems are easier to spot when there are less underlying assumptions.

Translation: The needs of the few (old corporations) should outweigh the needs of the many (rest of the world).

When you make your money doing consulting work, the yes, the needs of the payee do get a certain priority.

They didn't make it 'just' for themselves - it supports Windows, Linux and and Mac OS X on various (modern) architecture also.

I think at some point, if you've got a legacy application running on such an old platform, the cost of maintaining your own fork of libraries like OpenSSL has to fall on you eventually.

Although OpenSSL themselves continuing to maintain these ancient ports is admirable in a way, the unmaintainability it has caused to the code base as a whole is a serious problem that has reduced security for everyone.

I can only echo your sentiments. There seemed to be some skepticism about their attitude (what with the Comic Sans thing :)), but everyone in my circles at least respects the OpenBSD team's technical competence.

Not to miss:

Less code http://www.openbsd.org/papers/libtls-fsec-2015/mgp00004.html

What's wrong with the OpenSSL API http://www.openbsd.org/papers/libtls-fsec-2015/mgp00007.html

TLS small set of functions http://www.openbsd.org/papers/libtls-fsec-2015/mgp00009.html

read() and write() semantics http://www.openbsd.org/papers/libtls-fsec-2015/mgp00011.html

No need for handling errno EAGAIN/EINTR yay! http://www.openbsd.org/papers/libtls-fsec-2015/mgp00016.html

There's more stuff like event/poll, but I don't want to link more. The presentation is very interesting.

One nice side benefit of their usage of MagicPoint; it's easy to link directly into a specific slide.

> No need for handling errno EAGAIN/EINTR yay!

Yay for EINTR, but you're still handling EAGAIN; it's just called TLS_POLLIN/TLS_POLLOUT now. (Not that this is a bad thing: this is exactly what I'd expect from such an API, as it needs to integrate with the local event loop.)

The "What's wrong with the OpenSSL API" is excellent: a coworker ran into this just recently. A client was failing to connect, and had SSL23_XXX in the stack trace, and he wondered why it was using an outdated version of SSL; since we've long since disabled support for SSLv3 server-side, he figured — reasonably — that the client was failing to connect for that reason.

For those wondering, from the Python docs, which have the best explanation I know of:

> ssl.PROTOCOL_SSLv23

> Selects the highest protocol version that both the client and server support. Despite the name, this option can select “TLS” protocols as well as “SSL”.

> Yay for EINTR, but you're still handling EAGAIN; it's just called TLS_POLLIN/TLS_POLLOUT now.

I think their point is that you just have to check the return value to know how to proceed, you don't have to check the return value and errno.

I'm just curious and,yes, it's a bit off-topic AND forgetting the relevant dates, etc. that are at play here: isn't developing an SSL/TLS library the sort of thing that Rust should excel at? I see all those lines of C code (and clearly other non-C code) and am thinking of all the opportunities for bugs to come up related to pointer and memory management. Would such a library be a good use of Rust from the performance and safety perspective? Seems like it's how the language is being sold.

Note: I'm not a C developer nor do I typically work at this level of the stack, thus my seeking opinions.

Perhaps.

But there's a significant difference between auditing, cleaning up, and fixing up an old code base (which, however crappy, contains a lot of domain knowledge and bug fixes that have built up over the years), and a project to write exciting new bugs from scratch, in whatever language.

No, I wouldn't suggest such a thing for the project that is the subject of this story. But in the theoretical sense or if an upstart were to take a "start-from-scratch" approach starting today or maybe some time from now; that's where I'm wondering what those with better insight than I might think.

Mozilla hosted a Rust Meetup last December on crypto you might be interested in.

Tony Arcieri's talk in particular covers a lot of the areas Rust help prevent some of the recent snafus but also covers the areas Rust might be more dangerous to implement crypto in https://speakerdeck.com/tarcieri/thoughts-on-rust-cryptograp...

Videos: https://air.mozilla.org/bay-area-rust-meetup-december-2014/

Very cool. Thanks for the tip!

The thing about rewrites is they're great if you're happy to wait three to five years to get back to feature parity with what you have today.

The BSD team needed a library that worked pretty much straight away as a drop in replacement, and then they could gradually bring in a new API on the side. If they had rewritten we'd still be waiting.

Also, the OpenBSD guys are really good at writing C. They have far safer versions of the standard memory and string handling functions, better functions for allocating arrays to guard against integer overflows calculating the size, etc., and the skill and strict standards to use them properly.

Thanks to the developers for LibreSSL and libtls. I'm using both in an application I'm working on.

I've been meaning to post on the mailing list, but I have some requests I guess I'll try here:

- For libtls, accept custom read and write callbacks. libuv has no way to poll for writable: https://github.com/libuv/libuv/issues/517

- I wish they would provide (and maintain) the modern cyphersuite from here: https://wiki.mozilla.org/Security/Server_Side_TLS ("secure", "legacy" and "high" are all lacking in various ways)

These are fairly minor issues and overall LibreSSL and (especially) libtls have been a huge step forward. Thanks again.

Doug emailed me personally to follow up with this. Couldn't be happier!

Arch Linux has not switched to libreSSL I suspect this might have been a tounge slip of alpine linux, which has.

Alpine Linux still uses OpenSSL since LibreSSL releases is only supported for 1 year while Alpine releases is supported for 2 years. Void Linux has switched to LibreSSL though.

For those on OS X, `brew install libressl`. Note the actual binary is still called `openssl`, but you can tell because it's half the size.

Is `openssl` a symlink to `libressl`, which acts differently based on argv0?

I'd love to get away from some of openssl's arcane flags... :-)

It's not a symlink, but that's a good idea. Eg, openssl has 'nodes' (no DES) which means 'dont encrypt the file you're about to make' and if you omitted it and did encrypt it wouldn't use DES anymore anyway.

Doesn't iOS 9 use LibreSSL, too, now?

OSX 10.11 seems to ship with it too;

  /usr/bin/ssh -V
  OpenSSH_6.9p1, LibreSSL 2.1.7

The openssl binary in El Capitan (pretty sure this came with OS X 10.11 because of the path) is still on the 0.98 branch. Curious.

    $ openssl version
    OpenSSL 0.9.8zg 14 July 2015

    $ which openssl
    /usr/bin/openssl

Developers link against system OpenSSL, so Apple can basically never upgrade it.

I'm not sure that Apple promised to stay with OpenSSL. Apple developed CryptoCommons wrapper for some OpenSSL methods and I'm sure, that they can make it work with LibreSSL. I was under impression that it was made specifically to be able to drop OpenSSL when they would want it.

Those are the newer libraries you're _suppose_ to use, rather than OpenSSL. It's mostly older applications and codebases that limit Apple. I could imagine a stop-point but Apple obsesses a lot about not breaking backwards compatibility.

Don't forget their version is ancient (API-wise; they back-port fixes) and LibreSSL is much newer, so it's not a drop in replacement for such an old version.

> obsesses a lot about not breaking backwards compatibility

Lo, how times have changed. ;-)

Apple for the longest time shipped OpenSSL as a library that developers could link against in their binaries. Unfortunately OpenSSL even in minor versions could and would change function calls thereby making it almost impossible to keep up to date with OpenSSL for dynamic libraries because each new version required the developer to recompile the binary.

Apple thus stopped shipping OpenSSL and has officially deprecated it, these days you won't find headers for it anywhere in the stock system and there is no official way to link against it anymore either in El Capitan. It just exists for backwards compatibility.

If a developer now wants to use OpenSSL in their binary instead of the Common Crypto framework that Apple provides they will have to provide their own version of the library in their application, and they are then responsible for making sure users get patched in time.

Thanks. It looks like they're still shipping it (eg, it's in /usr/bin on El Capitan which is otherwise protected) but they're not shipping headers. Do you have a link for them deprecating it?

They put deprecation warnings in the headers starting with 10.7, and I'm pretty sure there was a WWDC talk (hopefully still available) mentioning it.

These two links roughly explain the issues/reasoning:

http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-... http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-an...

Yep, they are still shipping the binary, mostly for compatibility for scripts that require it. I have a feeling even that binary is eventually going to get dropped.

Is there a saner version of the slides, a PDF, or something with less jpg?

I'm interested in this but it's in lack of documentation, worse than openssl at the moment.

for example any demo code for me to try out the libtls?

What documentation do you need? Have you read the manual: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

You can read example code use by browsing the source codes of the applications listed in the presentation such as netcat and httpd.

Nice slides, but I would have liked to see how they are making sure there are no memory corruption issues.

I guess you need to look at the general OpenBSD coding guidelines (if they're documented anywhere).

Also, they ripped out a bunch of what they called "exploit mitigation countermeasures" in OpenSSL's memory allocation code.

Well it is still C anyway.

For example, I find worthless the Annex K of C11 as solution for memory corruption, because the functions still require to keep track of a separate pointer and size, while making sure they match. And the Annex is anyway optional.

However OpenBSD coding guidelines do look quite good:

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/...

I like that they request developers to make use of static analysis.

Any chance of getting this into Debian?

Reply on news.ycombinator.com