OpenSSL after Heartbleed
lwn.net
OpenSSL after Heartbleed
1–10 of 80 posts
Re: OpenSSL after Heartbleed
#2I recently experienced a bug with OpenSSL 1.1 and the team was pretty reactive!
I'm using OpenSSL 1.1 because it's the only DTLS implementation featuring all the extensions (OCSP stappling) and ciphersuites (AES-CCM-8) I need.
Re: OpenSSL after Heartbleed
#3For 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 of years and a team change to reinspire faith in that brand of security. If we should at all.
Re: OpenSSL after Heartbleed
#4Whenever 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 abstracting IO.
If it was anything other than a security library, it would have died long ago.
Re: OpenSSL after Heartbleed
#5For 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 and critical parts of the infrastructure are developed using languages and tools that don't just allow mistakes to happen that can be prevented but make it easy to make such mistakes. Crypto is affected by this but there are many other areas which are affected by this problem to.
There needs to be a move towards more constrained languages like Rust that limit the potential mistakes, better development processes that prevent bugs from passing through that can be caught by humans and tools for testing that make it possible to test for a wider range of problems and not just those developers anticipate to occur.
Re: OpenSSL after Heartbleed
#6Whenever 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 which is also a pain - today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration.
Another thing I'd like to ramble about a bit is their API/release management. In 1.1 they made a bunch of structures opaque - which is good IMHO - but due to the very inconsistent APIs before they needed to add some utility APIs to handle opaque structs in some places; instead of backporting those to 1.0.x, so that you, as an application developer, don't need to add conditional compilation and shims to every application, they chose not to. Additionally shims posted in the wiki were (maybe still are) wrong.
Forcing application developers to figure out API compatibility code for a crypto library is bad. That code will be tested very little or not at all, additionally it's hard to test.
Cryptography on Linux (or - on most platforms) is still in a bad shape.
Re: OpenSSL after Heartbleed
#7For 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…
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.
Re: OpenSSL after Heartbleed
#8Interesting, 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?
Re: OpenSSL after Heartbleed
#9Earlier 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.
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 user - and moved to OpenSSL.
OpenSSL will also often be the first implementation that has a new TLS feature, it's the internet's demo implementation. New optimizations in algorithms tend to land first in OpenSSL as well etc.
Today there are like ~four or five relevant TLS implementations, and only one is in widespread use on servers.
Re: OpenSSL after Heartbleed
#10Whenever 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…
Gosh, to fix such a problem we'd almost need some kind of machine that can run a different program than its current one. Perhaps with evidence of that as a possibility, we could use a good crypto library instead, eg. https://github.com/jedisct1/libsodium