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...
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.
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.
Note: I'm not a C developer nor do I typically work at this level of the stack, thus my seeking opinions.
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/
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.
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.
I'd love to get away from some of openssl's arcane flags... :-)
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.
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”.
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.
Also, they ripped out a bunch of what they called "exploit mitigation countermeasures" in OpenSSL's memory allocation code.
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.
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.
for example any demo code for me to try out the libtls?
You can read example code use by browsing the source codes of the applications listed in the presentation such as netcat and httpd.
