MesaLink: A memory-safe and OpenSSL-compatible TLS library

https://github.com/mesalock-linux/mesalink

by petethomas • 8 years ago

193 64 8 years ago

github.com

irundebian• 8 years ago

That's cool.

nimbius• 8 years ago

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?

jessaustin3• 8 years ago

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• 8 years ago

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.

tptacek7• 8 years ago

While I agree that Chinese sponsorship is not a good reason to avoid a library, every part of the reasoning in this comment is bad.

For most people, the threat model that focuses on FVEY includes China (China is a key part of FVEY's remit). If China has backdoored something, the FVEY threat model assumes FVEY has it too.

In particular: while FVEY governments theoretically have local legal limitations to their collection capabilities, they have no formal limitations to foreign collections --- foreign collections are the entire point of SIGINT agencies. Moving your data overseas to hide it from the NSA is thus, ceteris paribus, an extremely dumb idea.

Further, it is extremely difficult to extract cryptographic weaknesses from software, and relative to the scale of the whole problem, source code availability is a marginal factor. If you're going to say "identify all those backdoors", you might just as well say "YOLO".

squiguy7• 8 years ago

I understand some people's motive to fork OpenSSL but don't hear much about the success of these forks in the wild. Does anyone have any information on how BoringSSL or LibreSSL is used? It'd be great to hear from maintainers or anyone who has a large deployment with them.

rapsey2• 8 years ago

BoringSSL is very widely used. I think it is the Android SSL implementation.

zdw• 8 years ago

Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.

phaer• 8 years ago

You missed at least https://en.wikipedia.org/wiki/Mbed_TLS and https://en.wikipedia.org/wiki/GnuTLS

commandlinefan• 8 years ago

One upside I can see to this implementation is that it ONLY supports TLS 1.2 and 1.3, so there's significantly less danger of downgrade attacks. I believe you can build OpenSSL without TLS 1.1 and below, but the code is still there, so there's some non-zero risk.

alacombe• 8 years ago

you forgot about mbedTLS (formerly PolarSSL) which seems to originate from ARM ltd.

brohee2• 8 years ago

s2n: Amazon pet TLS implementation (https://github.com/awslabs/s2n). Whose code is actually sane.

esteer• 8 years ago

I wouldn't call it a pet implementation. It currently backs S3[0] and a wide variety of AWS services.

[0] https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...

p0rkbelly• 8 years ago

and formally verified by Galois.

Promarged• 8 years ago

One of the most interesting advances is formally verified cryptography [0] using F*. Unfortunately that's only for NSS (Firefox TLS engine).

[0] https://blog.mozilla.org/security/2017/09/13/verified-crypto...

techwizrd• 8 years ago

The Reddit discussion[0] corresponding to this.

0: https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...

MBlume• 8 years ago

Safe and fast crypto implementations from Google's BoringSSL

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

pfg3• 8 years ago

MesaLink relies on ring for its crypto operations. Ring is written in a mix of Rust, C and assembly, with most of the C and assembly code coming from (Boring|Open)SSL.

pcwalton• 8 years ago

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

teamhappy• 8 years ago

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

tptacek7• 8 years ago

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.

tptacek7• 8 years ago

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.

pfg3• 8 years ago

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

tptacek7• 8 years ago

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

asd2r23dasd• 8 years ago

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• 8 years ago

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

rapsey2• 8 years ago

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.

tptacek7• 8 years ago

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

cryptonector• 8 years ago

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.

haldean• 8 years ago

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

tptacek7• 8 years ago

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.

ctz• 8 years ago

If you're already using Rust, this looks neat

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

gue5t• 8 years ago

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.

amalcon• 8 years ago

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?

littlestymaar• 8 years ago

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.

jf3• 8 years ago

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

bno1• 8 years ago

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/

jf3• 8 years ago

This is great, thanks for sharing it!

extrapickles• 8 years ago

Some of the vulnerabilities are harder to test as they are side channels specific to the hardware the code is running on.

Sure you can check that basic timing side channels don’t exist, but the more esoteric ones would require a bunch of hardware to make sure they aren’t leaking data via power use and other channels.

jf3• 8 years ago

Can you go into more details on situations that would be hard to test? This has all only been a thought experiment for me so far, and in my thought experiment I handwave these sort of issues away by thinking "that's what emulation/simulation is for" – but I hadn't considered leading data via power use, so clearly I need to learn more there.

kevinis• 8 years ago

FYI: some benchmark numbers at https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf...

andrewaylett• 8 years ago

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.

zshrdlu• 8 years ago

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.

fulafel• 8 years ago

Part of: https://github.com/mesalock-linux/mesalock-distro "MesaLock Linux: a memory-safe Linux distribution"

kuwze• 8 years ago

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.

MesaLink: A memory-safe and OpenSSL-compatible TLS library

Related Stories