
MesaLink: A memory-safe and OpenSSL-compatible TLS library - petethomas
https://github.com/mesalock-linux/mesalink
======
tptacek
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.

~~~
asd2r23dasd
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.

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

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

------
zshrdlu
I laud your efforts. Whenever someone announces a project like this one, one
of the top comments is invariably one that promotes Openssl over other TLS
implementations.

I find this "leave it to the experts" attitude unjustifiable, since it more or
less translates to "trust the experts". Experts? Take a look at the source.
Look up the scrolls of bug reports. Experts indeed.

This tends to hurt efforts to create Openssl alternatives, and makes
crypto/security protocols seem like the black art of a chosen few.

Security is hard - all the more reason to encourage more people to be
involved. And in any case, experts have to start somewhere.

------
kevinis
FYI: some benchmark numbers at
[https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf...](https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf27fc)

------
techwizrd
The Reddit discussion[0] corresponding to this.

0:
[https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...](https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_memorysafe_and_opensslcompatible_tls/)

------
jf
I love seeing projects like this and I hope that a sane alternative to OpenSSL
emerges.

A big dream of mine is that we'll eventually have a comprehensive and hyper-
detailed set of automated tests that we can use to validate cryptographic
libraries [0]. Someday I hope that every new CVE for a cryptographic library
will also come with a corresponding automated test to check for that
vulnerability.

Footnotes: 0: Wycheproof is the closest I've seen to this ideal yet:
[https://github.com/google/wycheproof](https://github.com/google/wycheproof)

~~~
bno1
There is an ongoing project [0] implementing a formally verified and
performant TLS1.3 library. They already have verified and optimized assembly
for AES and SHA256. I think it will be a big game changer if it succeedes.

[0] [https://project-everest.github.io/](https://project-everest.github.io/)

~~~
jf
This is great, thanks for sharing it!

------
nimbius
Honestly the number of TLS library implementations is growing a bit too much
for my taste. so far the playing field is

boringssl: Googles pet TLS implementation forked from openssl. Google has been
a member of the US PRISM program since 2009

Mesalink: Baidus pet TLS implementation. Baidu is beholden to the Chinese
government.

openssl: Patched and functional TLS implementation. Open source and sponsored
by --but not controlled by-- many government organizations.

libressl: functional fork of OpenSSL.

What is anyones impetus to switch?

~~~
jessaustin
Many people have far less to fear from e.g. Chinese government than e.g.
5-eyes governments.

Frankly though this is a pretty shallow criticism. It's open source. Identify
all those backdoors you just know are hiding in plain sight. Then we can
either PR or fork it.

~~~
sebazzz
If reproducible builds are not used for these projects, it is not easily
possible to verify whether end user distributed binaries are equal to the
available source code. Never mind that in many cases actually replacing the
SSL component may not be possible.

~~~
nbsd4life
it's rust code, you can't even compile it without downloading a binary from
the internet.

~~~
steveklabnik
mrustc successfully bootstrapped the compiler; you could compile this with
nothing but a C compiler and some elbow grease if you truly desired.

~~~
nbsd4life
mrustc is stuck at 1.19.0

~~~
steveklabnik
That doesn't matter for the purposes of bootstrapping; it's broken the chain.
1.19 -> 1.25 is much, much, much easier than the thousand-odd builds you'd
need to bootstrap from the OCaml implementation.

This is why I mentioned "elbow grease." It's not trivial, but if it's
something you're concerned about, it is possible.

~~~
nbsd4life
sorry for being ranty on HN, I'm abusing my anonymity to vent.

please support a bootstrap method. I can't use any project in a programming
languages that require downloading a specific binary to use in certain setups.

It's not a hyperbole to bash rust, we're crazy people who make sure our
projects can be bootstrapped like so. I was very interested in mrustc. but
it's going to die very quickly when every version bump is an extra rust (it
took me 9 hours to build rust at some point).

Having to give up projects because they threaten to use rust is painful. It's
a good language and someone went out of their way to fix the bootstrap
problem. please give him a hand.

~~~
steveklabnik
Every project has to pick what problems matter, and can be addressed with the
current resources at hand. People, time, servers, whatever.

At this time, there's just not enough people that care at this degree of
paranoia; all of the Linux distros are fine with this, even Tor is fine with
this. I can appreciate that something like this would be more convenient, but
that's a teeny, tiny group of people this would serve, and it would be so, so,
so much effort to put in. It just doesn't make sense. (Given that you're
anonymous, I don't know who exactly you're asking for here.)

> but it's going to die very quickly when every version bump is an extra rust

It doesn't need to live; by existing it's already broken the boostrap chain.

------
MBlume
> Safe and fast crypto implementations from Google's BoringSSL

I'm a little confused, is this a wrapper on BoringSSL?

~~~
pcwalton
My understanding is that MesaLink uses the low-level crypto from BoringSSL
(transitively via ring) and the high-level protocol code from ring, which is
written in Rust.

Most memory safety problems in TLS implementations come from the higher-level
protocol code, not the implementations of the raw crypto primitives. In fact,
the latter benefit from being written in as low-level of a style as possible
to mitigate timing attacks.

Edit: Brian Smith has an authoritative comment here:
[https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...](https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_memorysafe_and_opensslcompatible_tls/dwqjdyo/)

------
andrewaylett
I'm glad this exists, and I'm sure it's very useful for organisations large
enough to put engineering effort into adopting it, but it seems to me that the
real win from Rust is going to look more like its use in Firefox: incremental
replacement of code in an already-widely-used project, rather than an attempt
at a full reimplementation.

Of course, nothing's stopping MesaLink becoming that replacement in a larger
user of OpenSSL. But I doubt I personally will benefit from it any time soon.

------
teamhappy
Anybody know the ratio of OpenSSL bugs related to memory management compared
to "normal" bugs, TLS state machine weirdness, compiler optimizations, etc.?

~~~
tptacek
I don't but I'd be surprised if it was too far from 1:1, at least if you
narrow it down to the exploitable bugs.

------
fulafel
Part of: [https://github.com/mesalock-linux/mesalock-
distro](https://github.com/mesalock-linux/mesalock-distro) "MesaLock Linux: a
memory-safe Linux distribution"

------
kuwze
I don’t understand why s2n doesn’t get more love. It’s a TLS implementation in
just ~10,000 lines of code! And Amazon is behind it.

------
irundebian
That's cool.

