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

41–50 of 65 posts

Re: What changed in OpenSSL after heartbleed

#41

Post by chasil »

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…

Unused? Ha ha, good one. Our VAX will never die.

    $ set def [.openssl]
    $ run openssl
    WARNING: can't open config file: SSLROOT: 
    [000000]openssl.cnf
    OpenSSL> version
    OpenSSL 1.0.0r 19 Mar 2015
    OpenSSL> quit
    $

Re: What changed in OpenSSL after heartbleed

#42

Post by throw0101a »

duxup wrote: post #29
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?

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

Re: What changed in OpenSSL after heartbleed

#43

Post by chasil »

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…

Apple uses LibreSSL as I understand.

Re: What changed in OpenSSL after heartbleed

#44

Post by chasil »

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…

OpenBSD also changed it's malloc implementation from sbrk to mmap, the net effect being that free returned memory to the OS far more often. It broke a lot of interesting stuff.

Re: What changed in OpenSSL after heartbleed

#45

Post by kbenson »

hoistbypetard wrote: post #32
icefo wrote: post #20

Earlier quoted context omitted.

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…

0. At least a couple did, but they were pretty niche-y. (Void was one, I think?) 1. It's a ton of packaging work even if the API/ABI were compatible (Calling it compatible is a bit of a stretch IMO). 2. One of the things LibreSSL removes is the FIPS validated stuff. Distributions that harbor ambitions of being used in large US corporate and government installations want that. 3. By the time the portable LibreSSL buil…

> 2. One of the things LibreSSL removes is the FIPS validated stuff. Distributions that harbor ambitions of being used in large US corporate and government installations want that.

Sounds like it could have happened if someone went to bat for it. Red Hat deciding to include it (even if they didn't replace OpenSSL with it immediately) and pushing to get it certified and the portability stuff more stable would have done this.

> 3. By the time the portable LibreSSL build system came out, there were already significant improvements afoot within the OpenSSL project.

That's probably the real reason. Although, given the stuff mentioned in that bug/talk and how much seems to have been based on extreme portability, unless OpenSSL decided to just give up on some aspects of that (I doubt it), then some of the problems (code complexity, not to mention ROP helpers) probably survive (not that I know).

Re: What changed in OpenSSL after heartbleed

#46

Post by duxup »

throw0101a wrote: post #42
duxup wrote: post #29

Earlier quoted context omitted.

"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?

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

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

Re: What changed in OpenSSL after heartbleed

#47

Post by mrpippy »

chasil wrote: post #43
icefo wrote: post #34

Earlier quoted context omitted.

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…

Apple uses LibreSSL as I understand.

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.

Re: What changed in OpenSSL after heartbleed

#48

Post by asveikau »

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

Re: What changed in OpenSSL after heartbleed

#49

Post by jcranmer »

duxup wrote: post #46
throw0101a wrote: post #42

Earlier quoted context omitted.

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

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.

Re: What changed in OpenSSL after heartbleed

#50

Post by userbinator »

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 rest can be taken care of by the standard C library.

Post reply on HN