MesaLink: A memory-safe and OpenSSL-compatible TLS library
github.com
github.com
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.
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.
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.
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.
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.
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.
For me at least, I chose Go on a recent network project specifically because of the blessed, quality crypto impl for things I needed.
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.
I'll take part of this praise :) Thanks.
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.
0: https://www.reddit.com/r/rust/comments/89aiyw/mesalink_a_mem...
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
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.
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?
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.
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".
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.
This is why I mentioned "elbow grease." It's not trivial, but if it's something you're concerned about, it is possible.
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.
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.
[0]: https://blog.mozilla.org/security/2017/09/13/verified-crypto...
[0] https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...
I'm a little confused, is this a wrapper on BoringSSL?
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...
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.