What changed in OpenSSL after heartbleed

Post by blasdel » Sat, Jul 18, 2020, 2:54 AM UTC

marcinzm wrote: post #39

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.

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

Post by tialaramex » Sat, Jul 18, 2020, 4:55 AM UTC

guidovranken wrote: post #24

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

Post by dcow » Sat, Jul 18, 2020, 6:15 AM UTC

userbinator wrote: post #51

Mountain_Skies wrote: post #38

Earlier quoted context omitted.

During a code review we found recently written Go code using SHA1, which has been functionally obsolete since 2005. It's a bit baffling why Google even included it in Go or at the very least didn't make it throw up a bunch of warnings to only use it for very special edge cases related to backward compatibility. The developer didn't know what algorithm to pick so he just went with one at random, assuming it was ok sin…

Git still uses SHA1, as does a bunch of other not-really-security-critical things (mostly as a much stronger checksum against corruption rather than malice.) If the purpose of the hash in that code was security-critical and compromised by malicious collisions, it would definitely be a problem. Otherwise it shouldn't be --- and jumping at things without understanding the nuance is precisely one of the problems with th…

Post by tptacek » Sat, Jul 18, 2020, 6:48 AM UTC

jcranmer wrote: post #49

duxup wrote: post #46

Earlier quoted context omitted.

What kind of things are we talking about that someone would add to OpenSSL outside of its core functions?

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.

Post by caf » Sat, Jul 18, 2020, 7:36 AM UTC

userbinator wrote: post #50

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…

The platform-specific stuff is not where most of the bugs have been found, so your assertion is misguided. Portability is one of the greatest strengths "keeping crypto freely accessible for all" and the fact that e.g. with a suitable C89 compiler I can create a binary that will run on an original 8088 IBM PC and perform SHA256 or AES should not be underestimated. To a first approximation, crypto is pure maths. The re…