Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What changed in OpenSSL after heartbleed

arxiv.org

Post reply on HN
Print view View original

21–30 of 65 posts

Re: What changed in OpenSSL after heartbleed

#21

Post by 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.

Re: What changed in OpenSSL after heartbleed

#22

Post by cordite »

icefo wrote: post #3

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

Google Tink is an encryption library providing a high level API for common cryptography problems. Such as authenticated encryption with associated data (AEAD). In a similar vein to libsodium, it's designed to not let you shoot yourself.

OpenSSL and it's forks expose the primitives directly, but as is the usual advice, don't roll your own crypto and say "We're using RSA 2048" because you copied an example from stack overflow without padding.

Re: What changed in OpenSSL after heartbleed

#23

Post by cordite »

leeoniya wrote: post #19
icefo wrote: post #3

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

there is also https://www.wolfssl.com/

https://bearssl.org/ is kinda cool too.

Re: What changed in OpenSSL after heartbleed

#24

Post by guidovranken »

zdw wrote: post #7

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

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

Re: What changed in OpenSSL after heartbleed

#25

Post by throw0101a »

rshnotsecure wrote: post #18

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 To be honest, maybe it's a good idea. It depends on how much support Huawei is willing to give OpenSSL.

In case anyone is curious:

> The OMC voted this week to update our security policy [1] to include the option of us giving prenotification to companies with which we have a commercial relationship. (Edited to clarify: the vote was to allow notification to our Premium Support customers and this does not include lower support levels, sponsors, or GitHub sponsors.)

* https://www.openssl.org/blog/blog/2020/05/12/security-prenot...

* https://www.openssl.org/support/contracts.html#premium

Re: What changed in OpenSSL after heartbleed

#26

Post by yjftsjthsd-h »

icefo wrote: post #3

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

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

How's that a FOSS thing? Do you think there would be fewer TLS implementations running around if they were proprietary?

Re: What changed in OpenSSL after heartbleed

#27

Post by my123 »

sigstoat wrote: post #15
easterncalculus wrote: post #12

Earlier quoted context omitted.

This is a fair point, but it is being used as standard on other operating systems. I remember people switching to Void Linux en masse after they made it their standard mostly as a result of Heartbleed.

> but it is being used as standard on other operating systems ...so even more people are looking at it? not sure what problem you think is happening here.

Note that Windows ships with LibreSSL since a while too. (present in System32/LibreSSL on remotely modern Windows 10 installs, OpenSSH relies on it among other things)

Re: What changed in OpenSSL after heartbleed

#28

Post by dijit »

evh wrote: post #17
uluyol wrote: post #13

Earlier quoted context omitted.

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 > 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 bu…

> though I think there is a YouTube video somewhere "LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU

I seem to recall him giving a live feed of his findings while spelunking into the codebase.

I think I actually got grey hairs from that...

Then I realised that OpenSSL is quite entrenched, I'm still running it to this day, in production.

Re: What changed in OpenSSL after heartbleed

#29

Post by duxup »

juanbyrge wrote: post #21

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…

"dumping ground for their pet research projects, that are enabled by default, of course"

How does that work? How does anyone even approve it if it isn't going to be used?

Admittedly I'm out of the loop as far as contributing to such projects, maybe letting that stuff in is the norm?

Re: What changed in OpenSSL after heartbleed

#30

Post by CameronNemo »

icefo wrote: post #20
uluyol wrote: post #13

Earlier quoted context omitted.

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 > 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 bu…

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 won…

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

Post reply on HN