LibreSSL languishes on Linux

Posted Jan 5, 2021 2:49 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: LibreSSL languishes on Linux by djc
Parent article: LibreSSL languishes on Linux

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.

to post comments

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.