10 ms·

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

193 points by petethomas 9y ago

irundebian 9y ago
That's cool.
nimbius 9y 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?
- jessaustin 9y 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 9y 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.
    - jessaustin 9y ago
      Sure, but that amounts to a criticism of particular devices or clients that can't be verified. If it was meant as a criticism of this repo, the answer is still "PR and fork".
    - nbsd4life 9y ago
      it's rust code, you can't even compile it without downloading a binary from the internet.
      - steveklabnik 9y ago
        mrustc successfully bootstrapped the compiler; you could compile this with nothing but a C compiler and some elbow grease if you truly desired.
        nbsd4life 9y ago
        mrustc is stuck at 1.19.0
        steveklabnik 9y ago
        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 9y ago
        been in this movie before with ocaml for bootstrap. it will die
        nbsd4life 9y ago
        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.
  - tptacek 9y 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".
    - jessaustin 9y ago
      We have different understandings of threats from "FVEY". I don't assume that e.g. FBI uses China's putative backdoors when trolling for subjects to oppress. In comparison, China is using them for precisely that purpose; this is the hypothesis from which this discussion started. There simply isn't much intersection between the two sets of oppressed subjects. FBI might know of some such backdoors, if they exist, but there is no structural reason to expect that they do. FVEY is not a monolith. If there were a "national security" reason to be interested in some target, that might inspire enough cooperation to generate a Baidu vuln. Most subjects, however, are simply targets of opportunity for law enforcement, with no real connection to national security. Sure, YOLO, but TFA is a repo. That is a pure thing, the worth of which is totally unrelated to all this other stuff.
- squiguy7 9y 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.
  - rapsey 9y ago
    BoringSSL is very widely used. I think it is the Android SSL implementation.
    - pfg 9y ago
      Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).
  - zdw 9y ago
    Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.
    - richm44 9y ago
      The primary implementation on MacOS and iOS is SecureTransport.
- phaer 9y ago
  You missed at least https://en.wikipedia.org/wiki/Mbed_TLS https://en.wikipedia.org/wiki/Mbed_TLS and https://en.wikipedia.org/wiki/GnuTLS https://en.wikipedia.org/wiki/GnuTLS
- commandlinefan 9y 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 9y ago
  you forgot about mbedTLS (formerly PolarSSL) which seems to originate from ARM ltd.
- brohee 9y ago
  s2n: Amazon pet TLS implementation (https://github.com/awslabs/s2n https://github.com/awslabs/s2n). Whose code is actually sane.
  - esteer 9y 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-100-percent-of-of-ssl-traffic-for-amazon-s3/ https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...
    - brohee 9y ago
      It was in kind of the parent post. I don't get his disdain for some implementations, especially when a monoculture proved so troublesome. He also missed NSS, which is quite an important one.
  - p0rkbelly 9y ago
    and formally verified by Galois.
- Promarged 9y 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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...
techwizrd 9y ago
The Reddit discussion[0] corresponding to this. 0: https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_memorysafe_and_opensslcompatible_tls/ https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...
MBlume 9y ago
> Safe and fast crypto implementations from Google's BoringSSL I'm a little confused, is this a wrapper on BoringSSL?
- deleted 9y ago
  [deleted]
- pfg 9y 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 9y 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_memorysafe_and_opensslcompatible_tls/dwqjdyo/ https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...
teamhappy 9y ago
Anybody know the ratio of OpenSSL bugs related to memory management compared to "normal" bugs, TLS state machine weirdness, compiler optimizations, etc.?
- tptacek 9y 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.
tptacek 9y 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.
- pfg 9y ago
  Would you recommend going with Go's crypto/tls if you can get away with it?
  - tptacek 9y ago
    If you're using Go, you should use crypto/tls.
    - kodablah 9y ago
      What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?
      - zaarn 9y ago
        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.
        kodablah 9y ago
        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.
jf 9y 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 https://github.com/google/wycheproof
- bno1 9y 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/ https://project-everest.github.io/
  - jf 9y ago
    This is great, thanks for sharing it!
- extrapickles 9y 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.
  - jf 9y 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 9y ago
FYI: some benchmark numbers at https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf27fc https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf...
andrewaylett 9y 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 9y 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 9y ago
Part of: https://github.com/mesalock-linux/mesalock-distro https://github.com/mesalock-linux/mesalock-distro "MesaLock Linux: a memory-safe Linux distribution"
kuwze 9y 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.

193 points by petethomas 9y ago

That's cool.

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 9y 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 9y 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.
  - jessaustin 9y ago
    Sure, but that amounts to a criticism of particular devices or clients that can't be verified. If it was meant as a criticism of this repo, the answer is still "PR and fork".
  - nbsd4life 9y ago
    it's rust code, you can't even compile it without downloading a binary from the internet.
    - steveklabnik 9y ago
      mrustc successfully bootstrapped the compiler; you could compile this with nothing but a C compiler and some elbow grease if you truly desired.
      - nbsd4life 9y ago
        mrustc is stuck at 1.19.0
        steveklabnik 9y ago
        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 9y ago
        been in this movie before with ocaml for bootstrap. it will die
        nbsd4life 9y ago
        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.
- tptacek 9y 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".
  - jessaustin 9y ago
    We have different understandings of threats from "FVEY". I don't assume that e.g. FBI uses China's putative backdoors when trolling for subjects to oppress. In comparison, China is using them for precisely that purpose; this is the hypothesis from which this discussion started. There simply isn't much intersection between the two sets of oppressed subjects. FBI might know of some such backdoors, if they exist, but there is no structural reason to expect that they do. FVEY is not a monolith. If there were a "national security" reason to be interested in some target, that might inspire enough cooperation to generate a Baidu vuln. Most subjects, however, are simply targets of opportunity for law enforcement, with no real connection to national security. Sure, YOLO, but TFA is a repo. That is a pure thing, the worth of which is totally unrelated to all this other stuff.
squiguy7 9y 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.
- rapsey 9y ago
  BoringSSL is very widely used. I think it is the Android SSL implementation.
  - pfg 9y ago
    Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).
- zdw 9y ago
  Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.
  - richm44 9y ago
    The primary implementation on MacOS and iOS is SecureTransport.
phaer 9y ago
You missed at least https://en.wikipedia.org/wiki/Mbed_TLS https://en.wikipedia.org/wiki/Mbed_TLS and https://en.wikipedia.org/wiki/GnuTLS https://en.wikipedia.org/wiki/GnuTLS
commandlinefan 9y 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 9y ago
you forgot about mbedTLS (formerly PolarSSL) which seems to originate from ARM ltd.
brohee 9y ago
s2n: Amazon pet TLS implementation (https://github.com/awslabs/s2n https://github.com/awslabs/s2n). Whose code is actually sane.
- esteer 9y 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-100-percent-of-of-ssl-traffic-for-amazon-s3/ https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...
  - brohee 9y ago
    It was in kind of the parent post. I don't get his disdain for some implementations, especially when a monoculture proved so troublesome. He also missed NSS, which is quite an important one.
- p0rkbelly 9y ago
  and formally verified by Galois.
Promarged 9y 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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...

techwizrd 9y ago

The Reddit discussion[0] corresponding to this. 0: https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_memorysafe_and_opensslcompatible_tls/ https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...

MBlume 9y ago

> Safe and fast crypto implementations from Google's BoringSSL I'm a little confused, is this a wrapper on BoringSSL?

deleted 9y ago
[deleted]
pfg 9y 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 9y 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_memorysafe_and_opensslcompatible_tls/dwqjdyo/ https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...

teamhappy 9y ago

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

tptacek 9y 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.

tptacek 9y 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.

pfg 9y ago
Would you recommend going with Go's crypto/tls if you can get away with it?
- tptacek 9y ago
  If you're using Go, you should use crypto/tls.
  - kodablah 9y ago
    What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?
    - zaarn 9y ago
      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.
      - kodablah 9y ago
        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.

jf 9y 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 https://github.com/google/wycheproof

bno1 9y 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/ https://project-everest.github.io/
- jf 9y ago
  This is great, thanks for sharing it!
extrapickles 9y 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.
- jf 9y 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 9y ago

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

andrewaylett 9y 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 9y 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 9y ago

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

kuwze 9y 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.