
OpenSSL after Heartbleed - Halienja
https://lwn.net/SubscriberLink/702751/e6605e55ce15f67d/
======
zAy0LfpBZLC8mAC
> Needless to say, OpenSSL is looking for contributors. Beyond contributing
> patches, interested developers can test the pre-releases, report bugs, and
> help to close bugs. The presenters concluded by saying that they would like
> users to get in touch, especially those who are distributing OpenSSL further
> downstream.

... and just a few days later they closed ~ 150 bugs, some with patches
attached, "because they were too old":

[https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-
github/](https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/)

[https://mta.openssl.org/pipermail/openssl-
dev/2016-October/0...](https://mta.openssl.org/pipermail/openssl-
dev/2016-October/008638.html)

~~~
akira2501
That was something else that irked me in the article, where they decry the
small $2,000 a year they receive in donations; but they don't address how much
their commercial support contracts[1] bring in. OpenSSL seems to be both an
open source project and a cottage industry all wrapped in one.

[1]
[https://www.openssl.org/support/contracts.html](https://www.openssl.org/support/contracts.html)

~~~
vtlynch
The first date that Archive.org has that page is August 2015, after
heartbleed. Do you know for sure that they offered this service before
heartbleed?

~~~
LukeShu
Yes.

[https://web.archive.org/web/20120805001248/http://www.openss...](https://web.archive.org/web/20120805001248/http://www.openssl.org/support/funding/contract.html)

August 2015 is just when they did a website redesign, which caused some URLs
to change.

~~~
vtlynch
Good find. This is an excellent question. Knowing how much OpenSSL made
through this is certainly important.

------
TwoBit
Whenever there's an article about OpenSSL, I get on my soapbox to talk about
how shitty it is. The design is terrible, both internally and in the public
API. Building it is a PITA. It is almost completely unaware of this thing
called multithreading. It still is hard-coded to be able to read certificates
only via disk files with fopen, despite having a screwy BIO system which is a
half baked attempt at sometimes abstracting IO.

If it was anything other than a security library, it would have died long ago.

~~~
dom0
I contribute to some software that's relatively widely deployed and needs
crypto primitives. Sadly on Linux there are few choices that support common
algorithms and is usually available. The alternatives sometimes exhibit
performance issues due to missing optimizations as well, or simply don't
support the needed algorithms. On the other hand OpenSSL took it's sweet time
to implement eg. 25519 based crypto or chacha20 which is also a pain - today
Chacha20-Poly1305 is the _only_ viable AEAD crypto system for embedded/low-
computing-capability devices, including those with AES acceleration.

Another thing I'd like to ramble about a bit is their API/release management.
In 1.1 they made a bunch of structures opaque - which is good IMHO - but due
to the very inconsistent APIs before they needed to add some utility APIs to
handle opaque structs in some places; instead of backporting those to 1.0.x,
so that you, as an application developer, don't need to add conditional
compilation and shims to _every_ application, they chose not to. Additionally
shims posted in the wiki were (maybe still are) wrong.

Forcing application developers to figure out API compatibility code for a
crypto library is bad. That code will be tested very little or not at all,
additionally it's hard to test.

Cryptography on Linux (or - on most platforms) is still in a bad shape.

~~~
cristinamillion
> Cryptography on Linux (or - on most platforms) is still in a bad shape.

libsodium addresses the non-TLS part of this pretty well, doesn't it? I know
it doesn't have any native password-based KDF that won't DOS your device under
anything but simple load, but otherwise it uses good algorithms.

> today Chacha20-Poly1305 is the only viable AEAD crypto system for
> embedded/low-computing-capability devices, including those with AES
> acceleration.

True, but there are some nice-looking AEAD candidates in the CAESAR
competition, some of which out-perform AES-GCM and CHACHA20 by a good margin.
We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre
initial license (which took a few iterations to get in a sane state and still
require you to pay him something like $70,000 USD for use in commercial
embedded systems).

~~~
dom0
NaCl/libsodium doesn't really work for a lot of cases, partly since it only
supports AES-(GCM) if the hardware supports it, which just ain't going to work
for anything that uses encryption for storage ("You can't open this file on
this computer, please go to a computer with AES-NI, thank you"), and partly
because it's opinionated approach doesn't work for some software (AES-GCM is
actually an instance of this).

Otherwise it's a nice library. So if it works for a project I highly recommend
it.

\--

I really hope that CAESAR moves the state of AEAD forwards. By all accounts it
already has.

------
jvermillard
I recently experienced a bug with OpenSSL 1.1 and the team was pretty
reactive! I'm using OpenSSL 1.1 because it's the only DTLS implementation
featuring all the extensions (OCSP stappling) and ciphersuites (AES-CCM-8) I
need.

------
__david__
Interesting, I had no idea the changes that were happening to OpenSSL. It's
sad that it took Heartbleed to kick it in the butt, but it's heartening that
they appear to be heading in a better direction now.

I'm also curious how LibreSSL is doing—I haven't heard much about it lately.
Did it fizzle, or is it still making good progress?

~~~
Leynos
LibreSSL is part of the OpenBSD base system, and that is their primary target
AIUI. They also maintain a portable version with support for a wider range of
operating systems.

There's a good summary of LibreSSL's track record over the past two years in
comparison with OpenSSL on the LibreSSL Wikipedia page
([https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...](https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities)).

There was also news a few days ago
([https://news.ycombinator.com/item?id=12691733](https://news.ycombinator.com/item?id=12691733))
that Alpine Linux is adopting LibreSSL Portable in place of OpenSSL.

------
iUsedToCode
How come the biggest names in IT don't work towards creating a modern, better
security library?

It's pennies for them, they wouldn't even see it on the balance. Having
security issues slows down business significantly. Non-geeks keep hearing
about major bugs in basic security and it surely has a negative effect on the
spread of internet and services based on it.

~~~
yalooze
There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD
team (it was created as a direct response to Heartbleed).

BoringSSL[1] is Google's attempt.

[0] [https://www.libressl.org/](https://www.libressl.org/) [1]
[https://boringssl.googlesource.com/boringssl/](https://boringssl.googlesource.com/boringssl/)

~~~
throwaway7767
LibreSSL is OpenSSL with some of the ugly bits stripped out. It's still aiming
for compatibility, and so it retains many of the warts and will continue to do
so. It's not a modern library though it may be a bit better than OpenSSL.

BoringSSL is similar, except there you additionally have the problem that
google strongly discourages its use by third parties, as they consider it an
internal library and semantics can change.

A better example of a modern library would be NaCL or libsodium.

~~~
stephen_g
That's not accurate - the LibreSSL developers have overhauled the internals
fairly substantially in a lot of ways, and they are also making a sensible API
on top of it (libtls).

------
mSparks
For me, Heartbleed was much much more than: ->At its core, Heartbleed was a
simple bug, a missing buffer-length check

It was a catastrophic failure of a critical internet component that
highlighted the truth that these supposed crypto security experts didnt have a
clue.

We're talking about the kind of "simple bug" analogous to a television with
bare wires as a power switch.

Imho it will take a lot more than a couple of years and a team change to
reinspire faith in that brand of security. If we should at all.

~~~
DasIch
I think that's somewhat unfair. People make mistakes, that's unavoidable and
shouldn't be seen as an issue. Instead of blaming people for making mistakes
we should consider what we can learn. We need to identify which mistakes
happened, why they happened and what measures we can take to make such
mistakes impossible or unlikely in the future.

It turns out that the industry is really bad that problem. Many libraries and
critical parts of the infrastructure are developed using languages and tools
that don't just allow mistakes to happen that can be prevented but make it
easy to make such mistakes. Crypto is affected by this but there are many
other areas which are affected by this problem to.

There needs to be a move towards more constrained languages like Rust that
limit the potential mistakes, better development processes that prevent bugs
from passing through that can be caught by humans and tools for testing that
make it possible to test for a wider range of problems and not just those
developers anticipate to occur.

~~~
dijit
I see the same sentiment all the time here on HN.

"Just reimplement it in rust"

Well, why do you think openssl is so pervasive? It's everywhere and it's not
due to marketing or ease of use or code quality.

It's because nobody in their right mind wants to implement a TLS library.
Openssl itself was only conceived because the original author was teaching
himself C.

~~~
dom0
Another facet is that _full_ compatibility to OpenSSL is _required_ on the
internet.

Ten years ago plenty of projects were using alternative SSL implementations
(eg Peter Gutmann's cryptlib), many of which had slight interop problems with
OpenSSL (which one to blame is impossible to say). In turn many projects
switched away from these libraries - they had to, interop issues making
software unreliable are vexing for every user - and moved to OpenSSL.

OpenSSL will also often be the first implementation that has a new TLS
feature, it's the internet's demo implementation. New optimizations in
algorithms tend to land first in OpenSSL as well etc.

Today there are like ~four or five relevant TLS implementations, and only one
is in widespread use on servers.

~~~
my123
Windows' crypt32 also matters, and has a much cleaner API compared to OpenSSL,
with backwards compat.

------
zeveb
> The code was hard to maintain and hard to contribute to, especially for
> developers in the US due to crypto export issues.

That's not really true: per [https://www.bis.doc.gov/index.php/policy-
guidance/encryption...](https://www.bis.doc.gov/index.php/policy-
guidance/encryption/registration#One), publicly available software (which
includes free software) just requires a notification under exception TSU. All
you have to do, per
[https://www.law.cornell.edu/cfr/text/15/740.13](https://www.law.cornell.edu/cfr/text/15/740.13),
is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of
the source code. As long as you don't change the location, you never have to
worry about it again.

The regulation even notes that simply providing source code on a public
website does not constitute export to a prohibited country.

It's really not a big deal.

(Note: I am not a lawyer; this does not constitute legal advice)

------
cm3
The original NaCl had assembly implementations, I believe generated with a
Perl script (not unlike OpenSSL's asm generator), and looking around libsodium
I cannot see assembly implementations of the loops. Does anyone know why that
is? I believe the Linux kernel implementation of ChaCha20 carries asm
versions.

------
zengid
>A recently added tool will modify the code to invert the sense of the
conditions in if statements to see whether the test suite catches the
resulting bug; if it doesn't, there is a coverage gap in the test suite.

Does anyone have any info on this tool? I'm intrigued.

