OpenSSL after Heartbleed

The first date that Archive.org has that page is August 2015, after heartbleed. Do you know for sure that they offered this service before heartbleed?

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

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

Having worked with Windows and OS X crypto layers, OpenSSL, CryptoPP and libtomcrypt, I think that generally cryptography is in bad shape almost everywhere.

The libraries that are trying to improve the cryptography aspects tend to run into the issue that algorithms in heavy use are unsupported. The libraries that do support algorithms in heavy use tend to have poorly written code, convoluted APIs, or bad documentation.

I have a huge amount of respect for everyone doing work in this space. When things are working, most people ignore it, but when sometimes goes wrong, everyone is mad at you. I would imagine there isn’t a whole lot of motivation for most.

libsodium is not an OpenSSL replacement and doesn't want to be. It's a cryptographic primitive library and generally doesn't implement cryptographic protocols (eg. TLS, X.509, CMS, CRLs, OCSP, ...).

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.

> it was created as a direct response to Heartbleed

The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes.

https://youtu.be/GnBbhXBDmwU?t=308

I haven’t paid much attention to LibreSSL since the project started but I recently downloaded the source code for OpenSSH and was very impressed with how clean and readable the code for ssh-keygen is. After seeing that, I’d have a more confidence in the OpenBSD team; they already have a great reputation for security but looking at their actual output impressed me more. (Maybe, some day I’ll explore free Unix-like operating systems other than GNU/Linux.)

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.

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.

> There needs to be a move towards more constrained languages like Rust that limit the potential mistakes

It's happening: https://github.com/ctz/rustls

Rust guarantees safety under certain conditions. That's it. It doesn't guarantee good design, bug free code, or code that never behaves badly. This is the kind of gratuitous maligning of code written in other languages that some Rust fans engage in that I find off-putting. Rust isn't The Solution To All Our Problems.

I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of the potential users. The Rust community doesn't have to implement all the functionality of Open SSL, but if it would produce at least just a proof of concept (e.g. just a minimal set of algorithms) which would prove both the capability to achieve the same speed and the provably higher security, that would be, I think, a huge start.

That would mean not wrapping the whole OpenSSL library in Rust calls but having some as minimal as possible, the tightest of the tightest loops implemented in ASM and everything else in clean and "secure" (not downgraded to the C freedom) Rust which would also pass the benchmarks and be capable to be called "on the high level" from the C code to which that library could be linked (probably the Rust code would not use GC or if it would it would have to be some so simple and minimal one that it would work by eventually calling the C malloc for bigger blocks and cause no different delays than the good written C). Not easy but I think theoretically possible for Rust. Once it would be achieved, implementing other algorithms would be possible to be done by different people and organizations.

I guess in order to achieve these goals the language designers would have to directly decide to support them, but I'd be glad if the status is already different. But I really believe that would be a huge argument for Rust: being provably more secure than C and achieving ability to implement effective drop-in replacements for C security libraries. Is it too high a goal?

I don't know how far we are from something like that, but maybe some Rust insider can estimate? What's still missing and how far we are from the point where what I described would be possible to implement?

They can even use a typed, assembly language if they want to have handwritten ASM and prove memory safety. Just no interest outside CompSci types.