1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
<!--
.. date: 2014/05/19 04:20
.. title: Using libressl
-->
I’ve been committing some code to the ressl project. I’ve found it worth to spend some time on that project that aims to make securing your communication more secure. But still people have some misconceptions about whether they can trust the new library and should make their code depend on libressl.
I have prepared a simple FAQ for them:
* Q: Should I base new code on the libressl API?
* A: No.
The reason is as simple as it gets. libressl was designed as a drop-in-replacement for openssl to protect the only asset openssl still has: an API that (even though it’s broken as hell) still is used widely. While they’re doing this, they try to do everything right that can be done right in a 201*-ish project.
Thing is, openssl is not actually there to provide you with secure software, but to implement the “nobody ever has been fired for using openssl”-aspect of your average “crypto”-library. It’s – well it’s there and it has some FIPS certification. But let’s face it: the code is terrible, the “maintainers” haven’t done any maintenance besides reselling their FIPS-asset, the API is terrible, the cipher-defaults are terrible, the interfaces into certificate checking are next to unusable, the core functionally works hard to cloak their badness from any modern bug detection heuristics, covering most of their bugs, and openssl’s maintainers ignore bug reports, because fixing them would break their certification, hurting their business of selling FIPS-consultancy.
Now, the OpenBSD guys were facing a tough challenge: write just another SSL library with a sane API that no one is going to use, or clean up the library that is de-facto standard and hard to rip out of each and every tool that tries to connect to the interwebs securely.
Most users of the openssl library come there, because they stumbled across transport security as an afterthought. Maybe because it’s been another tick on their compliance chart, or because they’ve seen the passwords flowing through their wireshark window – throw some crypto on it, they thought. What they need to realize is, that they actually need three separate libraries in the first place – which openssl conveniently layer-violates into one (and even adds dangerous cruft like kerberos):
a secure and sanely configured certificate exchange-, parser- and checker- library,
a library of sane (and BY DEFAULT SECURE) crypto primitives that can apply ciphers on a data stream,
a set of standard conforming heuristics that will (re-)negotiate cipher suites based on 1) and the availability of ciphers from 2)
openssl fails in every single aspect of this. 99,999 percent of users nowadays do use openssl to secure their socket-based communication on servers or clients talking with each other via TCP. The whole BIO abstraction provided by openssl is wasted on them. The stack-like approach to look at “chains” of certificates falls short on modern setups with several expired and unexpired certs of the same CA in a single key store. You still can – as a MITM – trick most openssl setups into using null ciphers or weak algorithms. Checking CRLs still is a black art done right by no one. openssl still implements each and every memory allocation level bug ever displayed on “software security 101” in your favorite university.
Now I will – judging by the current progress – give ressl a year until they matured enough to acknowledge them having picked all low hanging fruit. Then OpenBSD can proudly (and rightfully) announce that software linked agains libressl on their (and other) platforms is much more secure than before. And after looking into the source code I also understand that fixing it while also inventing a saner API exceeds the OpenBSD team’s capacities. So I urge you to consider what exactly you need secured and what tools provide you exactly what.
If you’re up to implementing secure communication between your app and your server or between your appliances, first check if you really need all the TLS features – like the whole set of X.509 features that openssl gives you (and if so, check back which license of [the available TLS implementations](http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations) could possible also suite your needs) – or if you can just go with a public domain library like [NaCl](http://en.wikipedia.org/wiki/NaCl_(software)) and put a little thought into what cryptographic primitives it gives you and where you need it.
Until then rest assured that securing your application is not just a case of linking in another unreviewed lib.
|
