TLS Support Questions

Specific Domains Web Stack
1

Currently HTTP.jl hard-codes a dependency on MbedTLS.jl for TLS support; it has served us decently over the years, but there have always been a lingering set of errors that crop up that are very difficult to debug; either because mbedtls library is a “black box” or the bindings around it (in MbedTLS.jl) are also tricky to get right.

What do people generally think around TLS in Julia going forward? It doesn’t seem like there’s an appetite to do something native (though go and rust both have implementations we could leverage), so what about the best TLS shared libraries that could be leveraged? OpenSSL? BoringSSL? I’ve had my eye on bearssl for several years, but it’s been very slow going in terms of getting out of “beta” status. There’s also the rustls project that has an ffi-package we could leverage.

Personally, I’m just a little tired of these little mbedtls errors that always pop up without a good way to address them. One option is to “overhaul” the MbedTLS.jl package with an aim to modernize, simplify, and make the code more robust since it was mainly written some 5-7 years ago. On the other hand, there’s only so much we can fix without diving into the mbedtls C source code, which I definitely don’t have an appetite for. It would be pretty easy to make the choice of TLS configurable in HTTP.jl, but I’m just wondering what other options people think it’s worth pursuing.

1 Like
2

https://twitter.com/search?q=openssl%20from%3Aariadneconill&src=typed_query&f=live

2 Likes
3

https://www.gnutls.org/ served me well some time ago. But I don’t have deep experience, just user level, on this.

4

It’s not clear to me we want to support any TLS/SSL library (that is except by a small wrapper library, deferring to what the OS provides).

What do you want as a minimum from the library? You want TLS 1.2, and preferably TLS 1.3 (and you don’t need older TLS or any SSL), but what I’m after, do you/your library need all that, or just some subset of TLS (1.3)? [And we want the much lower-latency HTTP/3, just recently standardized, but I’m not sure if it changes any other answers.]

The problem is, it doesn’t support TLS 1.3, thus seem unmaintained, and you want something that’s maintained, since security is a moving target, making it a very high priority.

We can multiply two integers, and it’s very fast, since it compiles down to one assembly instruction, but that isn’t safe, so we want to reuse secure code (none of Julia, C, Rust, Go even assembly instructions etc. are secure if used naively). See here very intriguing info how (not) to multiply numbers safely for crypto: BearSSL - Constant-Time Mul

In BearSSL, the “i31” big-integer code (used for RSA and elliptic curves) internally uses a macro called MUL31(), that takes as inputs two 31-bit words (represented in uint32_t values) and outputs the 62-bit result (in an uint64_t). […]
On “normal” data the short cycle count will be quite rare (about one in a billion invocations for full-width operands) but it may happen much more often on the top bits (e.g. when using 1024-bit integers with 31-bit limbs, the top limb contains only 1 bit of data, since 31×33 = 1023). How to leverage it in an actual attack is still an open question at this point; normal caution dictates that the M3 should be avoided for now. […]
A more general strategy is to implement big integers with 15-bit words, not 31-bit; thus, a multiplication of two 15-bit words can be implemented as:

#define MUL15(x, y)   ((uint32_t)((x) | (uint32_t)0x80000000) \
                       * (uint32_t)((y) | (uint32_t)0x80000000) \
                       & (uint32_t)0x3FFFFFFF)

BearSSL now implements that macro, both in the “slow” version shown above, and the “fast” version which is a simple multiplication. As in the case of MUL31, the slow version must be activated with a specific compile-time macro called BR_CT_MUL15.
[…]
Compilers can be an additional source of trouble.

That’s why I don’t trust Haskell :slight_smile: for low-level [security] code, or maybe not even the Julia compiler. I at least suggest not trying to reimplement TLS in Julia, also because there’s no reason to (we want to reuse [secure] code, and Julia has excellent interop with C and Rust).

5

Sort of off-topic. To answer my question:

at least you do NOT want to implement (Dual_EC_DRBG and) the (then-proposed) “Extended Random TLS extension” BSAFE - Wikipedia

was found enabled on some Canon printer models, which use the RSA BSAFE library, because the extension number conflicted a part of TLS version 1.3

To me and some of my colleagues, however, it was like that scene in X-Files where Mulder and Scully finally learn that aliens are real. […]
confirmed a theory we’d developed in 2014, but had been unable to prove: namely, the existence of a specific feature in RSA’s BSAFE TLS library called “Extended Random” — one that we believe to be evidence of a concerted effort by the NSA to backdoor U.S. cryptographic technology. […]
The RSA drama didn’t quite end there, however. In late 2013, Reuters reported that RSA had taken $10 million to backdoor their software.
[…]
Specifically, we found that BSAFE supports a non-standard extension to the TLS protocol called “Extended Random”.

The Extended Random extension is an IETF Draft proposed by an NSA employee named Margaret Salter (at some point the head of NSA’s Information Assurance Directorate, which worked on “defensive” crypto for DoD) along with Eric Rescorla as a contractor.

…hilarious…:

E. Rescorla RTFM, Inc.
M. Salter National Security Agency
Intended status: Informational

That Rescoria is now “Chief Technology Officer, Firefox at Mozilla” since 2013, and his company no more “RTFM, Inc. 1998 - Dec 2020”. Note it’s unproven, and unclear if Rescoria was in on it, since:

It’s important to note that Extended Random by itself does not introduce any cryptographic vulnerabilities. […]

The only thing that’s interesting about Extended Random is what happens when that random data is generated using the Dual EC algorithm.

6

For those interested, I’ve started an OpenSSL.jl package (New package: OpenSSL v1.0.0 by JuliaRegistrator · Pull Request #67323 · JuliaRegistries/General · GitHub) that initially is showing very good performance compared to mbedtls. I can share a bit more the journey I went through before settling on OpenSSL.jl and alternatives considered, but this is showing promise as the best current option for Julia + production settings.

4 Likes