Hacker News Reader

Comment by tptacek | Hacker News Reader

A while back I wrote a "Cryptographic Right Answers" document that recommended people use BoringSSL if they could get away with it, otherwise stick to OpenSSL. Today, I'd write "just use OpenSSL". It's a different, better project than it was just a few years ago, and it gets much more attention than alternate libraries.

If you're already using Rust, this looks neat. I'm not sure OpenSSL API compatibility is that much of a win? But if you're porting C code to Rust, sure.

View on HN

If you're already using Rust, you should use Rustls directly and jump on the opportunity to avoid having the absolutely fucking insane OpenSSL API in your stack at all.

Ideally such a misdesigned API would not exist at all. Library interfaces should be engineered to prevent mistakes. Here are a handful of the problems I've run into recently when dealing with legacy OpenSSL code (legacy being the reason it uses OpenSSL, not the reason it was bad):

Some error codes are `int`s, other are `long`s. Different error codes need to be passed to different stringification functions, and these have different allocation and string-loading semantics. Why on earth do I have to manually load error strings in the first place? I don't pass a string-table handle into the stringification, so I don't even get context isolation (multiple instances of OpenSSL in one thread have conflicts)!

The entire BIO framework is insanely overcomplicated and could be stripped down to a minimal buffer-based encryption API (c.f. the BSD libtls API).

Then you have API like `SSL_CTX_set_verify` which simply ignores irrelevant flags rather than returning an error about them. This is terrible.

Nobody should use OpenSSL for new projects.

ABI compatibility, or even just source compatibility, with the OpenSSL C API (as bad as that API is) is a huge win as there is an enormous base of OpenSSL-using applications. Being able to remove the vast majority of bugs from OpenSSL in those apps is a big win. Of course, the quality of Mesalink is important, but there are many bugs it may be immune to by dint of being coded in Rust.

I agree that OpenSSL is likely the most robust library out there, and if you're talking about provisioning your web server / doing some https from a high-level language then it's definitely the sane choice. (fwiw, I had some work looking at a BouncyCastle TLS server and...eek)

The one counter-example is the embedded space, particularly where code addition/modification for hardware integration is required. Here OpenSSL's footprint and APIs are a tad unwieldy compared to some alternatives.

Basically I just wanted to give mbedTLS a shout-out as, IMO, the clear winner in that particular space.

Also notable in embedded: bearSSL (free) and wolfSSL (commercial)

Note that wolfSSL is also open source (GPLv2) and you don't need commercial license to use wolfSSL.

> and it gets much more attention than alternate libraries.

Compared to BoringSSL I don't think so. Lots of huge players are using it on their devices and it's the Android SSL implementation.

OpenSSL is the de facto standard TLS implementation for most of the Internet. It gets more research attention than BoringSSL.

Wasn't "research attention" the problem before though? Lots of hacked in support for fancy new features, not enough serious maintenance.

Yes, that was the problem before.

> If you're already using Rust, this looks neat.

If you're already using Rust, you should probably not use this but rustls directly. As I understand, this is a wrapper intended to provide the same API that OpenSSL for easy integration with existing C projects.

Out of curiosity, where has LibreSSL sat in relation to OpenSSL and BoringSSL, in your mind?

I would use OpenSSL before I used LibreSSL at this point, but that's more a statement about how much more serious I perceive OpenSSL to have gotten as a project.

Would you recommend going with Go's crypto/tls if you can get away with it?

If you're using Go, you should use crypto/tls.

What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?

Check if the language/runtime/ecosystem you picked brings a default crypto lib and use that.

Go's C FFI support does exist and there are OpenSSL bindings. But CGo, which will be used in this case, kinda sucks, and you'll have a lot of pain getting the two sides, OpenSSL and the go HTTP lib, to talk properly to eachother.

I think my comment wasn't clear. I am saying, given that I can choose any lang/platform for my new project, and crypto lib quality is the most important, which lang/platform + crypto lib should I choose? Ignoring other factors, what is the best implemented crypto lib out there right now (specifically for TLS or in general)?

For me at least, I chose Go on a recent network project specifically because of the blessed, quality crypto impl for things I needed.

C. It has the widest range of support for crypto libraries, basically any reference implementation of modern crypto algorithms happens in C. Almost all existing libraries are either written in C or support C FFI.

So the most widely supported platform for crypto libs would be C.

But C is probably not a good choice due to other factors outside crypto lib support.

I think the best implemented crypto lib out there atm is NaCl (djb). It has very few functions that take obvious parameters with which you can't blow your leg off (the only danger is repeating a nonce but generating a random nonce or sequential nonce is within the realm of "I expect most people to be able to read /dev/random".)

Second would be any crypto library that is implemented similar: few leg-blow-off-safe functions that do all the hard parts for you.

> If you're already using Rust, this looks neat

I'll take part of this praise :) Thanks.

I haven't really followed those developments too closely. Do folks think that OpenSSL gets enough attention these days to overcome the structural deficiencies relative to NSS?

Reply on news.ycombinator.com