Live data from Hacker News

OpenSSL after Heartbleed

lwn.net

21–30 of 80 posts

Re: OpenSSL after Heartbleed

#21
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…

You can read certificates via the BIO system with PEM_read_bio_X509() or straight from a buffer with d2i_X509().

Re: OpenSSL after Heartbleed

#22
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…

phk had a talk (at fosdem I believe) a few years ago in which he stressed that the easiest way for the NSA to "create" vulnerable code is to push out bad, unnatural APIs with horrendeous defaults into OpenSSL.

Re: OpenSSL after Heartbleed

#23
post #14
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.

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

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: OpenSSL after Heartbleed

#24
post #20
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…

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.

So? Nobody disagrees on the fact that there is a problem. Putting blame on people won't solve the problem. It will piss people off. People you want on your side, enthusiastically solving the problem. Your attitude is actually dangerous and counterproductive to solving the problem.

This toxic culture is a big part why we are in this mess. Who in their right mind would want to try work on OpenSSL to improve it while being called an idiot? Who'd be willing to stand up for the project as a representative? Speak out for the project?

Re: OpenSSL after Heartbleed

#25
post #24
post #20

Earlier quoted context omitted.

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.

So? Nobody disagrees on the fact that there is a problem. Putting blame on people won't solve the problem. It will piss people off. People you want on your side, enthusiastically solving the problem. Your attitude is actually dangerous and counterproductive to solving the problem. This toxic culture is a big part why we are in this mess. Who in their right mind would want to try work on OpenSSL to improve it while be…

It's not a case of blaming. Its a case of choosing https://www.libressl.org/ or https://www.openssl.org/

Applying best practice development processes or Pretending someone else can do it all for you, and you can "bolt it on" at the end.

The article lists: Future plans and lessons learned: At the top of the list for future development is support for TLS 1.3.

Like adding yet another protocol to the already hacked mess of protocols is a "good" thing.

Re: OpenSSL after Heartbleed

#26
How come the biggest names in IT don't work towards creating a modern, better security library?

It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

Re: OpenSSL after Heartbleed

#27

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed).

BoringSSL[1] is Google's attempt.

[0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/

Re: OpenSSL after Heartbleed

#28

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

I would think they don't want to do it because they don't want to support it. Even though they are capable of creating it, they are then responsible for keeping it updated.

Re: OpenSSL after Heartbleed

#29
post #27

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/

LibreSSL is OpenSSL with some of the ugly bits stripped out. It's still aiming for compatibility, and so it retains many of the warts and will continue to do so. It's not a modern library though it may be a bit better than OpenSSL.

BoringSSL is similar, except there you additionally have the problem that google strongly discourages its use by third parties, as they consider it an internal library and semantics can change.

A better example of a modern library would be NaCL or libsodium.

Re: OpenSSL after Heartbleed

#30
post #27

Earlier quoted context omitted.

There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/

LibreSSL is OpenSSL with some of the ugly bits stripped out. It's still aiming for compatibility, and so it retains many of the warts and will continue to do so. It's not a modern library though it may be a bit better than OpenSSL. BoringSSL is similar, except there you additionally have the problem that google strongly discourages its use by third parties, as they consider it an internal library and semantics can ch…

That's not accurate - the LibreSSL developers have overhauled the internals fairly substantially in a lot of ways, and they are also making a sensible API on top of it (libtls).
Post reply on HN