There hasn’t been a lot of noise coming out of the LibreSSL camp recently. Mostly there’s not much to report, so any talks or presentations will recover a lot of the same material. But it’s an election year, and in that spirit, we can look back at some promises previously made and hopefully make a few new ones.

scorecard

First part of any campaign is to tout one’s record. And shift blame for any missteps.

Starting from the beginning is LibreSSL - The First 30 Days. On the positive side, most of the cleanup has been a success. We promised to delete support for obsolete systems and we did. We promised to delete obscure compat layers and build on posix and we did. We promised not to appease FIPS and we didn’t. We promised “If your Operating System can not provide you with a good source of entropy, it will NOT be LibreSSL’s job to fake it. Fix your Operating System. Not the SSL library.” and we... oh, hm. Time to call in the equivocator.

Thirty seconds inspection inside the getentropy file for some operating systems will reveal that the no faking promise didn’t hold up. Ultimatums aside, it’s rather difficult to actually change other people’s operating systems. On the bright side, the noise generated and ensuing ruckus did lead to some useful changes. A somewhat sad chapter all around, but in the end, we all came through it better off than before. I, personally, would have liked to stick to our guns but sometimes compromise is better than obstruction.

We also promised to maintain API compatibility with OpenSSL. This has been hit and miss, depending on the API in question and when you ask. In most cases, code dependent on a removed function could be easily fixed to do things a better way. We might retroactively “clarify” this promise to be that it will remain possible to write applications that readily work with both OpenSSL and LibreSSL. (In much the same way, one can easily write software that runs on Linux and OpenBSD, but this task is complicated by adding gratuitous includes of sys/linux.h.)

Next up is LibreSSL - More Than 30 Days Later. I’m a little more conservative with my promises, so I think I came out alright. Less code, less features. Check, check.

I made an implicit promise about releases and patches. Instead of shipping security fixes mixed inline with thousands of lines of other unrelated changes, we’d make incremental security releases that differ only as necessary. So far so good. I do note the releases page is somewhat unclear on this point. We’re doing exactly the right thing, but we haven’t communicated what that is.

I also introduced the ressl (now tls) API, noting that it was a work in progress. We’ve made quite a bit of progress on that front, with even more OpenBSD programs using the API. We even ship a TLS netcat now in the portable distribution to show people how it works. More details in this talk about libtls.

promises

With an eye to the future, what new promises can we make? Some time ago I joked that we only promised to make a better TLS implementation, not a better TLS. Remains true, but fortunately there are people working on that, too. TLS 1.3 support is on the short term watchlist. The good news is we may be ahead of the game, having already removed compression. How much more work can there be?

LibreSSL integrated the draft chacha20-poly1305 construction from BoringSSL. The IETF has since standardized a slightly different version because if it were the same it wouldn’t be different. To stay up to date, we switched to support for standard variant, and the beginning of deprecation for the existing code. Incidentally, some people got bent out of shape because shipping chacha20 meant exposing non IANA approved numbers to Internet. No promises that won’t happen again.

To keep LibreSSL relevant, we’ll continue to integrate a few other useful features that have progressed beyond the experimental stage. But only as they prove themselves and garner industry support. ALPN is an example on one such feature already added. In terms of nitty gritty, there’s an ongoing effort to mitigate some side channels and leaks. Find more places where secret data is copied and erase it from there, too. Continue encouraging people to try out the libtls API.

I’ll also do what I can to continue talking up LibreSSL, even though I don’t contribute otherwise. Credit for doing work should go to Bob, Brent, Doug, Joel, Miod, and many other contributors. BoringSSL and OpenSSL have also been an invaluable source of code and inspiration.