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…
OpenSSL after Heartbleed
21–30 of 80 posts
Re: OpenSSL after Heartbleed
#22Whenever 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…
Re: OpenSSL after Heartbleed
#23Earlier 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…
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
Re: OpenSSL after Heartbleed
#24Earlier 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.
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
#25Earlier 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…
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
#26It'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
#27How 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.
BoringSSL[1] is Google's attempt.
[0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/
Re: OpenSSL after Heartbleed
#28How 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
#29How 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/
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
#30Earlier 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…