(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:
- the number of vulnerabilities in OpenSSL
- the ratio of OpenSSL related vulnerabilities in Node.js (Deno's future will likely look the same)
- 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:
- 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."
- 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.