Deno shouldn't use OpenSSL

[rsp]

(Update: Looking at more issues and source code I see that probably only the build process requires OpenSSL, not Deno itself, but still there is some discussion of using other libs that themselves use at least two different TLS libraries so I leave the info below for consideration.)

Looking at #1787 it seems that the consensus is to use OpenSSL in Deno. I think it should be reconsidered for a project that takes security so seriously as Deno, for the following reasons:

1. the number of vulnerabilities in OpenSSL
2. the ratio of OpenSSL related vulnerabilities in Node.js (Deno's future will likely look the same)
3. the problems with Node on systems that don't ship OpenSSL by default (because of its vulnerabilities) and that have problems shipping Node (because it cannot use any other more secure TLS library)

There was a discussion in nodejs/node#428 about 3 years ago, main points to consider:

• OpenSSL is the world record holder for the number of CVE entries
• OpenSSL alone was responsible for 66% of all Node vulnerabilities!
• Gentoo had to maintain their own patches for Node and npm to work with LibreSSL
• VoidLinux: "We at VoidLinux ship over 7000 packages, all build against libressl. Nodejs is the only exception where we're forced to use the bundled openssl."
• Alpine Linux: "I am working on switching alpine over to libressl and got bitten by this. I am not happy with building node with the bundled openssl. What happens if 3rd party modules are built with system libressl and node is built with bundled openssl?"
• in The state of LibreSSL in FreeBSD Node was the only software causing problems: "By looking at the most recent node vulnerabilities, it becomes obvious that most of these are related to OpenSSL itself. Part of the reason is that node comes with a version of OpenSSL bundled, which means that unless you upgrade your node ports on a regular basis and expose node over the internet (using Express or Ghost for example) chances are that your system is vulnerable."
• HardenedBSD was working on adding LibreSSL as alternative provider of libcrypto and libssl (I'm not up to date of how it worked out but back then Node was the only software that couldn't work with LibreSSL)
• OpenBSD had problems with building Node and they added exceptions for Node so that SSL provider cannot be chosen like for other packages, with a TODO to re-add the choice when it works for Node.
• Big Node update in OpenBSD ports: "Build against node's OpenSSL (this one hurts, but is unavoidable currently)."

What we could do:

1. Use a more secure alternative to OpenSSL instead:
   • LibreSSL - "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014, with goals of modernizing the codebase, improving security, and applying best practice development processes."
   • wolfSSL - "The wolfSSL embedded SSL library is a lightweight, portable, C-language-based SSL/TLS library targeted at IoT, embedded, and RTOS environments primarily because of its size, speed, and feature set. " (license could be an issue)
   • BoringSSL by Google (used in Chrome/Chromium and Android)
   • GnuTLS - "The project strives to provide a secure communications back-end, simple to use and integrated with the rest of the base Linux libraries." by GNU (LGPL lincense)
   • RusTLS - "Rustls is a modern TLS library written in Rust. It's pronounced 'rustles'. It uses ring for cryptography and libwebpki for certificate verification."
2. Use a well defined abstraction for all functionalities that we need from a TLS library and make Deno portable to multiple libraries (instead of being so tightly coupled with OpenSSL as Node)

I think this is something to be seriously considered looking at the experience of Node.
One of the main features of Deno is security. It would be a pity if Deno wouldn't be able to run without problems on the operating systems that take security most seriously.

[rsp]

More context to consider:

• BoringSSL is used by quiche
• RusTLS is used by quinn and hyper-rustls

(quiche and quinn are QUIC implementations considered in #1558)

(hyper-rustls was used in PR #1147 referenced in denoland/std#153)

There are pros and cons for using each of those. The question is, should deno core use more than one TLS library? (Another question is about including the library in the deno binary vs using the OS-installed one - also pros and cons here - but that is an entirely different problem.)

[yorkie]

More TLS alternative: mbed TLS (formerly known as PolarSSL) makes it trivially easy for developers to include cryptographic and SSL/TLS capabilities in their (embedded) products, facilitating this functionality with a minimal coding footprint.

[ry]

We are already using rustls and ring (outgoing fetch requests can do TLS - this is not yet exposed elsewhere). AFAIK we don't depend on OpenSSL (besides the bits that are forked from OpenSSL inside Ring).