6 ms·

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 implementati

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?

jessaustin 9y ago
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.
- sebazzz 9y ago
  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.
  - jessaustin 9y ago
    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".
  - nbsd4life 9y ago
    it's rust code, you can't even compile it without downloading a binary from the internet.
    - steveklabnik 9y ago
      mrustc successfully bootstrapped the compiler; you could compile this with nothing but a C compiler and some elbow grease if you truly desired.
      - nbsd4life 9y ago
        mrustc is stuck at 1.19.0
        steveklabnik 9y ago
        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.
        nbsd4life 9y ago
        been in this movie before with ocaml for bootstrap. it will die
        nbsd4life 9y ago
        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.
        steveklabnik 9y ago
        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.
- tptacek 9y ago
  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".
  - jessaustin 9y ago
    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.
squiguy7 9y ago
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.
- rapsey 9y ago
  BoringSSL is very widely used. I think it is the Android SSL implementation.
  - pfg 9y ago
    Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).
- zdw 9y ago
  Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.
  - richm44 9y ago
    The primary implementation on MacOS and iOS is SecureTransport.
phaer 9y ago
You missed at least https://en.wikipedia.org/wiki/Mbed_TLS https://en.wikipedia.org/wiki/Mbed_TLS and https://en.wikipedia.org/wiki/GnuTLS https://en.wikipedia.org/wiki/GnuTLS
commandlinefan 9y ago
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.
alacombe 9y ago
you forgot about mbedTLS (formerly PolarSSL) which seems to originate from ARM ltd.
brohee 9y ago
s2n: Amazon pet TLS implementation (https://github.com/awslabs/s2n https://github.com/awslabs/s2n). Whose code is actually sane.
- esteer 9y ago
  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-100-percent-of-of-ssl-traffic-for-amazon-s3/ https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...
  - brohee 9y ago
    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.
- p0rkbelly 9y ago
  and formally verified by Galois.
Promarged 9y ago
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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...

jessaustin 9y ago

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.

sebazzz 9y ago
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.
- jessaustin 9y ago
  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".
- nbsd4life 9y ago
  it's rust code, you can't even compile it without downloading a binary from the internet.
  - steveklabnik 9y ago
    mrustc successfully bootstrapped the compiler; you could compile this with nothing but a C compiler and some elbow grease if you truly desired.
    - nbsd4life 9y ago
      mrustc is stuck at 1.19.0
      - steveklabnik 9y ago
        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.
        nbsd4life 9y ago
        been in this movie before with ocaml for bootstrap. it will die
        nbsd4life 9y ago
        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.
        steveklabnik 9y ago
        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.
tptacek 9y ago
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".
- jessaustin 9y ago
  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.

squiguy7 9y ago

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.

rapsey 9y ago
BoringSSL is very widely used. I think it is the Android SSL implementation.
- pfg 9y ago
  Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).
zdw 9y ago
Outside of OpenBSD itself, LibreSSL is used in macOS 10.13 (and one would assume iOS), both of which have sizeable deployments.
- richm44 9y ago
  The primary implementation on MacOS and iOS is SecureTransport.

phaer 9y ago

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

commandlinefan 9y ago

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.

alacombe 9y ago

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

brohee 9y ago

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

esteer 9y ago
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-100-percent-of-of-ssl-traffic-for-amazon-s3/ https://aws.amazon.com/blogs/security/s2n-is-now-handling-10...
- brohee 9y ago
  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.
p0rkbelly 9y ago
and formally verified by Galois.

Promarged 9y ago

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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...