
LibreSSL, and the new libtls API - glass-
http://www.openbsd.org/papers/libtls-fsec-2015/mgp00001.html
======
neoCrimeLabs
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...](https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities)

~~~
LukeShu
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.

~~~
neoCrimeLabs
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.

~~~
jandrese
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.

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

~~~
mariuolo
I think that has more to do with code hygiene.

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

------
alecco
Not to miss:

Less code [http://www.openbsd.org/papers/libtls-
fsec-2015/mgp00004.html](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](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](http://www.openbsd.org/papers/libtls-
fsec-2015/mgp00009.html)

read() and write() semantics [http://www.openbsd.org/papers/libtls-
fsec-2015/mgp00011.html](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](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.

~~~
deathanatos
> _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”._

~~~
ben0x539
> 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.

------
sbuttgereit
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.

~~~
inquisitiveio
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...](https://speakerdeck.com/tarcieri/thoughts-on-rust-
cryptography)

Videos: [https://air.mozilla.org/bay-area-rust-meetup-
december-2014/](https://air.mozilla.org/bay-area-rust-meetup-december-2014/)

~~~
sbuttgereit
Very cool. Thanks for the tip!

------
btrask
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](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](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.

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

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

~~~
uggedal
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.

------
nailer
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.

~~~
scott_karana
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... :-)

~~~
nailer
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.

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

------
sthustfo
How does LibreSSL compare with boringssl (google's fork)?

------
ausjke
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?

~~~
zmyrgel
What documentation do you need? Have you read the manual:
[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man3/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man3/tls_accept_fds.3?query=tls_init&sec=3)

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

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

~~~
gpvos
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.

~~~
pjmlp
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/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man9/style.9?query=style&arch=i386)

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

------
davidgerard
Any chance of getting this into Debian?

