
What changed in OpenSSL after heartbleed - gnu
https://arxiv.org/abs/2005.14242
======
zdw
I'd be more interested in a comparison in the strategies used to harden the
codebase in the forks like BoringSSL and LibreSSL, and how well those
strategies have panned out.

There has historically been some crowing from the LibreSSL crowd about how
their work avoided CVE's later discovered in OpenSSL:
[https://undeadly.org/cgi?action=article&sid=20150319145126](https://undeadly.org/cgi?action=article&sid=20150319145126)

~~~
guidovranken
I've been doing differential fuzzing of many major cryptographic libraries. It
currently tests symmetric crypto, some elliptic curve crypto, bignum
arithmetic, message digests and MACs, KDFs, but not TLS, X509, ASN1 etc (yet).
The list of bugs it has found so far can be viewed here [1].

The bug count per library can not be used as an absolute metric and not all
bugs are security vulnerabilities (though many can be under specific
circumstances).

BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One
of the reasons for this could be that the bug count is proportional to the
complexity/SLOC: BoringSSL is smaller in terms of functionality (# of message
digests, ciphers, ...) than LibreSSL, which is smaller than OpenSSL. OpenSSL
sometimes commits new buggy code whereas BoringSSL does not, but OpenSSL has a
higher commit frequency than BoringSSL, and BoringSSL might be aiming for a
production-safe master branch where OpenSSL might not.

So it's not easy to derive a reliable metric from this, but with that said,
you can't really go wrong with BoringSSL if it offers what you need.

[1] [https://github.com/guidovranken/cryptofuzz#bugs-found-by-
cry...](https://github.com/guidovranken/cryptofuzz#bugs-found-by-cryptofuzz)

~~~
DyslexicAtheist
> but not TLS, X509, ASN1 etc (yet)

then this may interest you:

[https://blog.doyensec.com/2020/05/14/asn1fuzz.html](https://blog.doyensec.com/2020/05/14/asn1fuzz.html)

^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G
etc and doesn't get enough love in other domains. It's a high learning curve
but once you get beyond the _" standardese"_ language in the docs it's opening
doors to opportunities in so many industries.

> BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL.
> One of the reasons for this could be that the bug count is proportional to
> the complexity/SLOC

the openSSL codebase is notorious but I think it's also because it has been in
existing for so long. if I look around today I see 2 camps: cryptographers and
software engineers. letting sw-engineers do crypto is usually a bad idea but
it's often worse when cryptographers start coding. it's almost like a
variation of the old joke of _" the 2 most dangerous things in Tech are a sw-
engineer with a soldering iron and a hw-engineer with a sw-patch"_ ... apart
from complexity leading to bugs I'd also say there is another downside which
is stronger in openssl: people end up using it wrongly which makes it a
proverbial foot-gun for implenters.

> [1]
> [https://github.com/guidovranken/cryptofuzz](https://github.com/guidovranken/cryptofuzz)

very cool thanks!!

------
juanbyrge
Code quality and hygiene mean absolutely nothing if you have a large number of
academic types who use OpenSSL as the dumping ground for their pet research
projects, that are enabled by default, of course.

Also, OpenSSL supports all kinds of ancient esoteric platforms that are
essentially unused, yet were kept in the code base for sentimental reasons.

The real metric they should be looking at is the number of
features/platforms/LOC removed from the project. Less code = less surface
areas for exploits.

~~~
asveikau
I think the multiplatform support is an interesting criticism but
misunderstood.

I happened to be reading some OpenSSL code around the time of heartbleed and
statically linking some of it in a project. I found a lot of the portability
ifdefs were poorly done even for the standards of the 90s. It wasn't
portability itself that was the issue, it was actual quality and in many cases
the wrong abstractions in place.

One example that sticks out in my memory... There was a logger that had a
Win32 ifdef. If you ran on Win32 it fed log messages directly to MessageBox().
Unless it detected the current process was an NT service, in that case it used
another logging mechanism without asking. It wasn't actually "windows
portability" or "windows support". _The whole thing wasn 't appropriate for a
library._ It could have had a mechanism to give the log lines to the
application as a C string and be done with it. Instead, it was mixing of
library layer stuff and application layer stuff, or just ordinary library
bloat.

The other huge example I recall was compliance with older configurations that
were pre-C99. C99 is much more universal now vs 20 years ago, although there
are a few things Microsoft still doesn't support. But again, a bunch of these
things seemed to be handled with ifdefs at the call site, rather than put in a
proper compatibility layer that only an older configuration gets.

It does seem that in the years since then, cruft has been removed not only in
forks but also in the upstream project.

~~~
Gibbon1
An aside my feeling about Microsoft and their lack of C99 support is the
community was inexplicably too nice to them. As well as compilers defaulting
to C89 instead of the latest.

Also as someone that has a code base that targets a dozen different pieces of
hardware ifdef madness is a strong indication that your program architexture
is broken. Sometimes it's unavoidable but you should think of ifdef's as
another name for FIXME.

~~~
asveikau
Microsoft has gotten a bit better at it after many years of zero progress.
Vs2010 introduced stdint and stdbool. Vs2015 finally allowed mixed
declarations and code. I think the most lacking piece lately is the named
struct member initializers.

~~~
jdsully
Almost all the progress made was necessary to support modern C++ standards,
although it is nice they enabled it in the C compiler. They haven't added any
C only features in a very long time.

------
easterncalculus
I'm glad there have been changes to the project. Heartbleed was certainly bad,
but I personally never understood getting behind LibreSSL. Seeing one bad
vulnerability from an established project and immediately jumping ship to a
brand new one with less eyes and reputation seemed hasty to me.

~~~
uluyol
As the LibreSSL devs have said, heartbleed was not the cause of the fork. They
forked the project because they believed the OpenSSL project repeatedly made
bad decisions.

From
[https://www.openbsd.org/papers/eurobsdcon2014-libressl.html](https://www.openbsd.org/papers/eurobsdcon2014-libressl.html)

> Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs
> have resulted in remote code execution. Anybody remember the Slapper worm?
> That worm exploited an OpenSSL bug (which was apparently titled the SSLv2
> client master key buffer overflow) which revealed not only encrypted data or
> your private key, but also gave up a remote shell on the server, and then it
> propogated itself. Yeah, I'd say that's worse. But no headlines.

> I mention this just to reinforce that LibreSSL is not the result of "the
> worst bug ever". I may call you dirty names, but I'm not going to fork your
> project on the basis of a missing bounds check.

> why fork

> Instead, libressl is here because of a tragic comedy of other errors. Let's
> start with the obvious. Why were heartbeats, a feature only useful for the
> DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And
> why was this entirely useless feature enabled by default? Then there's some
> nonsense with the buffer allocator and freelists and exploit mitigation
> countermeasures, and we keep on digging and we keep on not liking what we're
> seeing. Bob's talk has all the gory details.

You can see "Bob's talk" here:
[https://www.openbsd.org/papers/bsdcan14-libressl/](https://www.openbsd.org/papers/bsdcan14-libressl/)
though I think there is a YouTube video somewhere.

Also I would like to point out that Google also forked OpenSSL. So it seems
that the LibreSSL folks are not the only ones who thought a fork was
necessary.

~~~
icefo
Damn OpenSSL sounds a lot worse than I thought after reading those slides. The
custom malloc, the function that allow you to jump anywhere in OpenSSL, the 17
layer deep IFDef, the dubious entropy that openSSL try to generate if the OS
doesn't provide it, the bugs that sit in the issue tracker for years.

A lot of that uglyness seems to come from the fact that OpenSSL wants to
support all environments (even DOS). I wonder why distributions haven't
switched since LibreSSL was made to be API/ABI compatible with openSSL and
target a POSIX OS. This would be much more justified than the ffmepg / libav
thing imo.

~~~
CameronNemo
>LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS

LibreSSL is neither API compatible with newer OpenSSL versions, nor is it ABI
compatible. In fact, they break ABI every six months. Furthermore LibreSSL
upstream only targets OpenBSD, with the portable version existing as an
afterthought.

The only linux distribution using LibreSSL is Void Linux (Alpine switched to
OpenSSL some time ago). Even Void is considering switching to OpenSSL:
[https://github.com/void-linux/void-
packages/issues/20935](https://github.com/void-linux/void-
packages/issues/20935) .

~~~
icefo
Thank you ! That was interesting read. The main problems with LibreSSL are
software compatibility since most software only build against OpenSSL and
performance because the portable version doesn't include optimisations for
other platforms than x86_64

The slides came out in 2014 so the API / ABI thing was probably true then but
not anymore.

Maybe things would have been different if LibreSSL was backed by a major Linux
distribution and OpenBSD. Even then Unix/Linux is not the only target of a lot
of software and I doubt a lot of developer would have put the time to support
both.

[Edit] I just saw in an other comment that LibreSSL is used in MacOSX and
windows for openSSH. Maybe developers will consider it if it becomes available
on major platforms

~~~
chasil
Apple uses LibreSSL as I understand.

~~~
mrpippy
Yes, but it’s only for use by system libraries. The header files aren’t
shipped, and applications should use their own copy rather than trying to use
the system’s.

------
icefo
This made me think of BoringSSL and LibreSSL again.

Looking up on Wikipedia it seems that LibreSSL is focused on OpenBSD and
removed lots of legacy code. BoringSSL (Google) got renamed to Tink but I
couldn't not find much more.

It's sad to see that duplication of effort but it's also the force of open
source

~~~
not2b
The paper points to data showing that OpenSSL is still the dominant SSL
implementation on the net, so it's the one that matters.

~~~
zdw
If Windows is the dominant desktop computing platform, is it the only one the
matters?

------
caiobegotti
For random reasons I can't read the full article but I wonder if they discuss
the impact of LibreSSL on OpenSSL itself. Would anyone who moved to LibreSSL
actually look back to OpenSSL today in 2020? Honest question as I'm not a
crypto professional myself.

~~~
not2b
It's just a PDF link. The paper mentions the existence of LibreSSL but that is
pretty much it; the focus of the paper is on the extensive efforts to improve
OpenSSL.

------
rshnotsecure
OpenSSL recently passed a change in their vuln announcement policy to give a
major firm, which everyone here knows I think, 7 days advance notice of any
zero-day that they were made aware of.

This was the engineer who helped set up the new policy:
[https://awe.com](https://awe.com)

To be honest, maybe it's a good idea. It depends on how much support Huawei is
willing to give OpenSSL.

~~~
marcinzm
So, being realistic here, that means the Chinese government is given 7 days
advance notice?

~~~
blasdel
[https://xenproject.org/developers/security-
policy/#organizat...](https://xenproject.org/developers/security-
policy/#organizations-on-the-pre-disclosure-list)

------
dyingkneepad
What's the current market share of OpenSSL vs LibreSSL vs alternatives?

