LibreSSL languishes on Linux

Posted Jan 4, 2021 22:38 UTC (Mon) by djc (subscriber, #56880)
Parent article: LibreSSL languishes on Linux

I hope we can move away from TLS libraries written in unsafe languages and instead use something like rustls, via MesaLink if need be:

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

to post comments

LibreSSL languishes on Linux

Posted Jan 5, 2021 2:49 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (4 responses)

That objective makes good sense. But I'm not sure that MesaLink (if I understand what it is correctly) is a useful way to get there though. While the OpenSSL APIs have improved over time, they're still not a great fit for what you should be doing either in a client or a server, and it seems like preserving the OpenSSL APIs is the MesaLink goal right?

Also, it's not entirely clear to me exactly _how_ much safer this is. rustls uses ring, which is derived from BoringSSL which of course is ultimately OpenSSL plus maintenance work. So at least some of the time the actual code running is (or could be?) literally identical. This is a contrast to some projects that weren't so performance critical and were able to entirely replace C with Rust like-for-like. Is it worth it anyway? Maybe.

LibreSSL languishes on Linux

Posted Jan 5, 2021 14:02 UTC (Tue) by wqweto (guest, #143975) [Link] (2 responses)

It seems rustls does not want to support AES in CBC mode (and everything they deem "insecure") so they focus only on new AEAD ciphers which makes the library pretty incompatible with most of the TLS 1.2 universe while OpenSSL has complete support for all TLS versions by definition.

No one in fancy languages camp wants to deal with backward compatibility obviously.

cheers,
</wqw>

LibreSSL languishes on Linux

Posted Jan 5, 2021 14:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

TLS 1.2 supports AEAD just fine. Moreover, all the significant TLS 1.2 implementations have been supporting AES-GCM for at least a decade.

So AES-CBC is something that you'd want to use with >10 year old code that hasn't been upgraded since then.

LibreSSL languishes on Linux

Posted Jan 5, 2021 20:17 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

TLS 1.2 specifies TLS_RSA_WITH_AES_128_CBC_SHA as Mandatory To Implement. In theory a TLS 1.2 client that can't do TLS_RSA_WITH_AES_128_CBC_SHA is not compliant. (In principle an application profile could specify something different, but they don't)

Of course the IETF does not have an enforcement arm, if you don't want to implement arguably unsafe choices like TLS_RSA_WITH_AES_128_CBC_SHA then nobody will actually force you to do so. A TLS 1.2 client that only does ECDHE will work on a lot of the web today, and avoids any concerns with how unsafe RSA kex is, but it would not be compliant with the standard and isn't compatible enough that you could say, ship it in a mass market web browser today, likewise for AEAD suites.

LibreSSL languishes on Linux

Posted Jan 6, 2021 21:10 UTC (Wed) by njs (subscriber, #40338) [Link]

Moving all the X.509 and protocol parsing, state machine, etc. into a safe language seems like a pretty significant benefit. Plus from a quick skim, it looks like ring is almost all asm+rust, with C only for a few low-level crypto primitives on platforms that don't have asm implementations. And some of that C code is from fiat-crypto.

LibreSSL languishes on Linux

Posted Jan 15, 2021 15:41 UTC (Fri) by sandsmark (guest, #62172) [Link] (4 responses)

The problem, for me, with rust is everything other than the language itself. And in that project you linked to, I'm not sure I'd trust it anymore than something written in modern memory safe C++ (e. g. looking at the places they use "unsafe").

But the npm style approach that rust projects seem to take wrt. dependencies makes it harder to trust rust projects for me, for example.

LibreSSL languishes on Linux

Posted Jan 15, 2021 15:48 UTC (Fri) by sandsmark (guest, #62172) [Link] (3 responses)

Just a concrete example of what I mean: this here (including how the rust-based dependencies are handled) almost looks like a joke in the context of a security related project: https://github.com/mesalock-linux/mesalink/tree/679dac128...

LibreSSL languishes on Linux

Posted Jan 18, 2021 8:23 UTC (Mon) by laarmen (subscriber, #63948) [Link] (2 responses)

Out of curiosity, besides the curl | sh, what do you think is wrong there? I'm not being snarky, just trying to learn :-)

LibreSSL languishes on Linux

Posted Feb 2, 2021 11:08 UTC (Tue) by sandsmark (guest, #62172) [Link] (1 responses)

It was the piping some random URL to a shell script that has been a running joke for a while.

The rest of the code doesn't seem particularly defensively written, compared to something like Botan (which nicely illustrates how using C++ and not C impacts security, all of their issues would have been just as or more likely to happen with mesalink: https://botan.randombit.net/security.html).

And looking at their code, mesalink seems more prone to raw memory issues than Botan: https://github.com/mesalock-linux/mesalink/search?q=unsafe

LibreSSL languishes on Linux

Posted Feb 2, 2021 18:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Most of unsafes in mesalink are there to deal with the external interface that is unsafe because it's a compatibility shim for OpenSSL.