14 ms·

What changed in OpenSSL after heartbleed

158 points by gnu 6y ago

caiobegotti 6y ago
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 6y ago
  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.
icefo 6y ago
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 6y ago
  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 6y ago
    If Windows is the dominant desktop computing platform, is it the only one the matters?
- zdw 6y ago
  OpenSSL recently changed licenses to Apache 2.0, which is a unacceptable in some of the BSDs, which made the LibreSSL fork more valuable from a licensing perspective for them. Tink isn't really a rename, but an API wrapper to prevent misuse that happens to use BoringSSL internally.
- Rafert 6y ago
  BoringSSL is still alive, Tink is something completely separate.
- leeoniya 6y ago
  there is also https://www.wolfssl.com/ https://www.wolfssl.com/
  - cordite 6y ago
    https://bearssl.org/ https://bearssl.org/ is kinda cool too.
- cordite 6y ago
  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.
- yjftsjthsd-h 6y ago
  > 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?
  - riffraff 6y ago
    IIUC the point was that the ability to fork projects (and then potentially merge back) is one of the strengths of OSS, even if it means some duplicated effort.
- mrweasel 6y ago
  The duplicated effort is needed. The OpenSSLs mono-cultur was one of the reason Heartbleed, and other OpenSSL security issues, where such huge problems and affected so many.
easterncalculus 6y ago
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.
- kzrdude 6y ago
  Eyes doesn't make a project, but the development process
- sigstoat 6y ago
  > jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
  - easterncalculus 6y ago
    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.
    - sigstoat 6y ago
      > 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.
      - my123 6y ago
        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)
        protomyth 6y ago
zdw 6y ago
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 6y ago
  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-cryptofuzz https://github.com/guidovranken/cryptofuzz#bugs-found-by-cry...
  - DyslexicAtheist 6y ago
    > 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!!
dyingkneepad 6y ago
What's the current market share of OpenSSL vs LibreSSL vs alternatives?
rshnotsecure 6y ago
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.
- throw0101a 6y ago
  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-prenotifications/ https://www.openssl.org/blog/blog/2020/05/12/security-prenot... * https://www.openssl.org/support/contracts.html#premium https://www.openssl.org/support/contracts.html#premium
- marcinzm 6y ago
  So, being realistic here, that means the Chinese government is given 7 days advance notice?
  - blasdel 6y ago
    https://xenproject.org/developers/security-policy/#organizations-on-the-pre-disclosure-list https://xenproject.org/developers/security-policy/#organizat...
juanbyrge 6y ago
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.
- duxup 6y ago
  "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?
  - throw0101a 6y ago
    > How does that work? How does anyone even approve it if it isn't going to be used? How do you know it won't be used if it isn't put in in the first place?
    - duxup 6y ago
      What kind of things are we talking about that someone would add to OpenSSL outside of its core functions?
      - jcranmer 6y ago
        Extensions to SSL, such as the SSL heartbeat extension (RFC 6520)... the one where the Heartbleed bug was found in. Other cipher suites would be another example. The criticism here is that OpenSSL wasn't particularly choosy in which features of SSL (or other crypto in general) that it supported; it supported all of them, even if they were of more questionable utility.
        6y ago

158 points by gnu 6y ago

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 6y ago
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.

icefo 6y ago

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 6y ago
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 6y ago
  If Windows is the dominant desktop computing platform, is it the only one the matters?
zdw 6y ago
OpenSSL recently changed licenses to Apache 2.0, which is a unacceptable in some of the BSDs, which made the LibreSSL fork more valuable from a licensing perspective for them. Tink isn't really a rename, but an API wrapper to prevent misuse that happens to use BoringSSL internally.
Rafert 6y ago
BoringSSL is still alive, Tink is something completely separate.
leeoniya 6y ago
there is also https://www.wolfssl.com/ https://www.wolfssl.com/
- cordite 6y ago
  https://bearssl.org/ https://bearssl.org/ is kinda cool too.
cordite 6y ago
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.
yjftsjthsd-h 6y ago
> 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?
- riffraff 6y ago
  IIUC the point was that the ability to fork projects (and then potentially merge back) is one of the strengths of OSS, even if it means some duplicated effort.
mrweasel 6y ago
The duplicated effort is needed. The OpenSSLs mono-cultur was one of the reason Heartbleed, and other OpenSSL security issues, where such huge problems and affected so many.

easterncalculus 6y ago

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.

kzrdude 6y ago
Eyes doesn't make a project, but the development process
sigstoat 6y ago
> jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
- easterncalculus 6y ago
  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.
  - sigstoat 6y ago
    > 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.
    - my123 6y ago
      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)
      - protomyth 6y ago

zdw 6y ago

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 6y ago
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-cryptofuzz https://github.com/guidovranken/cryptofuzz#bugs-found-by-cry...
- DyslexicAtheist 6y ago
  > 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!!

dyingkneepad 6y ago

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

rshnotsecure 6y ago

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.

throw0101a 6y ago
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-prenotifications/ https://www.openssl.org/blog/blog/2020/05/12/security-prenot... * https://www.openssl.org/support/contracts.html#premium https://www.openssl.org/support/contracts.html#premium
marcinzm 6y ago
So, being realistic here, that means the Chinese government is given 7 days advance notice?
- blasdel 6y ago
  https://xenproject.org/developers/security-policy/#organizations-on-the-pre-disclosure-list https://xenproject.org/developers/security-policy/#organizat...

juanbyrge 6y ago

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.

duxup 6y ago
"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?
- throw0101a 6y ago
  > How does that work? How does anyone even approve it if it isn't going to be used? How do you know it won't be used if it isn't put in in the first place?
  - duxup 6y ago
    What kind of things are we talking about that someone would add to OpenSSL outside of its core functions?
    - jcranmer 6y ago
      Extensions to SSL, such as the SSL heartbeat extension (RFC 6520)... the one where the Heartbleed bug was found in. Other cipher suites would be another example. The criticism here is that OpenSSL wasn't particularly choosy in which features of SSL (or other crypto in general) that it supported; it supported all of them, even if they were of more questionable utility.
      - 6y ago