Hacker News Reader

Comment by nimbius | Hacker News Reader

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?

View on HN

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.

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.

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".

it's rust code, you can't even compile it without downloading a binary from the internet.

mrustc successfully bootstrapped the compiler; you could compile this with nothing but a C compiler and some elbow grease if you truly desired.

mrustc is stuck at 1.19.0

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.

been in this movie before with ocaml for bootstrap. it will die

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.

Every project has to pick what problems matter, and can be addressed with the current resources at hand. People, time, servers, whatever.

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.

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".

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.

You missed at least https://en.wikipedia.org/wiki/Mbed_TLS and https://en.wikipedia.org/wiki/GnuTLS

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-crypto...

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.

BoringSSL is very widely used. I think it is the Android SSL implementation.

Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).

Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.

The primary implementation on MacOS and iOS is SecureTransport.

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.

s2n: Amazon pet TLS implementation (https://github.com/awslabs/s2n). Whose code is actually sane.

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-10...

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.

and formally verified by Galois.

you forgot about mbedTLS (formerly PolarSSL) which seems to originate from ARM ltd.

Reply on news.ycombinator.com