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

OpenSSL after Heartbleed

lwn.net

Post reply on HN
Print view View original

11–20 of 80 posts

Re: OpenSSL after Heartbleed

#11

Post by Leynos »

__david__ wrote: post #8

Interesting, I had no idea the changes that were happening to OpenSSL. It's sad that it took Heartbleed to kick it in the butt, but it's heartening that they appear to be heading in a better direction now. I'm also curious how LibreSSL is doing—I haven't heard much about it lately. Did it fizzle, or is it still making good progress?

LibreSSL is part of the OpenBSD base system, and that is their primary target AIUI. They also maintain a portable version with support for a wider range of operating systems.

There's a good summary of LibreSSL's track record over the past two years in comparison with OpenSSL on the LibreSSL Wikipedia page (https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...).

There was also news a few days ago (https://news.ycombinator.com/item?id=12691733) that Alpine Linux is adopting LibreSSL Portable in place of OpenSSL.

Re: OpenSSL after Heartbleed

#12

Post by cheiVia0 »

mSparks wrote: post #3

For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple…

The problem was bigger than that, basically no-one cares about their open source infrastructure and so it (including OpenSSL) is continually under-resourced.

Re: OpenSSL after Heartbleed

#13

Post by zAy0LfpBZLC8mAC »

> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream.

... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too old":

https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/

https://mta.openssl.org/pipermail/openssl-dev/2016-October/0...

Re: OpenSSL after Heartbleed

#14

Post by DasIch »

dijit wrote: post #7
DasIch wrote: post #5

Earlier quoted context omitted.

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…

I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.

I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues.

I agree that this is a difficult problem but I don't think that's really the barrier here. AI is also difficult and there is no shortage of improvement in that area. The real problem isn't the difficulty of implementing a TLS library, the real problem is inertia and an unwillingness to change.

Re: OpenSSL after Heartbleed

#15

Post by my123 »

dom0 wrote: post #9
dijit wrote: post #7

Earlier quoted context omitted.

I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.

Another facet is that full compatibility to OpenSSL is required on the internet. Ten years ago plenty of projects were using alternative SSL implementations (eg Peter Gutmann's cryptlib), many of which had slight interop problems with OpenSSL (which one to blame is impossible to say). In turn many projects switched away from these libraries - they had to, interop issues making software unreliable are vexing for every…

Windows' crypt32 also matters, and has a much cleaner API compared to OpenSSL, with backwards compat.

Re: OpenSSL after Heartbleed

#16

Post by lmm »

dijit wrote: post #7
DasIch wrote: post #5

Earlier quoted context omitted.

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…

I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.

There are options now though. My production services terminate SSL with a non-C implementation. (ocaml-ssl may be beta and unaudited but my judgement call is that I trust it more than any C implementation).

Re: OpenSSL after Heartbleed

#17

Post by cristinamillion »

dom0 wrote: post #6
TwoBit wrote: post #4

Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstr…

I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20…

> Cryptography on Linux (or - on most platforms) is still in a bad shape.

libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms.

> today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration.

True, but there are some nice-looking AEAD candidates in the CAESAR competition, some of which out-perform AES-GCM and CHACHA20 by a good margin. We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre initial license (which took a few iterations to get in a sane state and still require you to pay him something like $70,000 USD for use in commercial embedded systems).

Re: OpenSSL after Heartbleed

#18

Post by akira2501 »

zAy0LfpBZLC8mAC wrote: post #13

> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream. ... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too…

That was something else that irked me in the article, where they decry the small $2,000 a year they receive in donations; but they don't address how much their commercial support contracts[1] bring in. OpenSSL seems to be both an open source project and a cottage industry all wrapped in one.

[1] https://www.openssl.org/support/contracts.html

Re: OpenSSL after Heartbleed

#19

Post by dom0 »

cristinamillion wrote: post #17
dom0 wrote: post #6

Earlier quoted context omitted.

I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20…

> Cryptography on Linux (or - on most platforms) is still in a bad shape. libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms. > today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including thos…

NaCl/libsodium doesn't really work for a lot of cases, partly since it only supports AES-(GCM) if the hardware supports it, which just ain't going to work for anything that uses encryption for storage ("You can't open this file on this computer, please go to a computer with AES-NI, thank you"), and partly because it's opinionated approach doesn't work for some software (AES-GCM is actually an instance of this).

Otherwise it's a nice library. So if it works for a project I highly recommend it.

--

I really hope that CAESAR moves the state of AEAD forwards. By all accounts it already has.

Re: OpenSSL after Heartbleed

#20

Post by mSparks »

DasIch wrote: post #5
mSparks wrote: post #3

For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple…

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…

Tell that to your bank manager when they make a mistake....

It is NOT the bug itself that is at issue here.

It is the "mistake" of an ENTIRE INDUSTRY relying on a security module with haphazard, proven flawed development process, and impenetrable code.

Then trying to pretend the exact opposite.

Unfair, attract me down votes - sure. True - without doubt.

Post reply on HN