What changed in OpenSSL after heartbleed • Hacker News Board

Re: What changed in OpenSSL after heartbleed

#61

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

nwallin wrote: post #31

easterncalculus wrote: post #4

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.

It wasn't about one bad vulnerability. Heartbleed was just the last straw. OpenSSL implemented its own memory management system instead of using malloc. It would allocate one pool of memory and then manipulate into that. This meant that static analysis, runtime analysis, fuzzers were incapable of finding memory bugs. Because all pointers into that pool were "valid". LibreSSL stripped out OpenSSL's memory system and r…

Custom allocators are (or were) common enough that Valgrind includes an API for them to use to tell the analysis engine where the valid memory blocks are:

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.me...

I believe the state of the art in generic malloc implementations has improved since this sort of thing was commonplace, though.

Re: What changed in OpenSSL after heartbleed

#62

Post by Gibbon1 » Sat, Jul 18, 2020, 6:25 PM UTC

asveikau wrote: post #48

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…

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…

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.

Re: What changed in OpenSSL after heartbleed

#63

Post by asveikau » Sun, Jul 19, 2020, 3:07 AM UTC

Gibbon1 wrote: post #62

asveikau wrote: post #48

Earlier quoted context omitted.

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…

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…

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.

Re: What changed in OpenSSL after heartbleed

#64

Post by jdsully » Tue, Jul 21, 2020, 1:52 PM UTC

asveikau wrote: post #63

Gibbon1 wrote: post #62

Earlier quoted context omitted.

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…

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.

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.

Re: What changed in OpenSSL after heartbleed

#65

Post by CameronNemo » Sat, Jul 25, 2020, 4:52 AM UTC

icefo wrote: post #34

CameronNemo wrote: post #30

Earlier quoted context omitted.

>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). E…

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

FYI Void recently enabled hardware acceleration for ARM and PowerPC architectures in LibreSSL.