Erlang/OTP impact of DST Root CA X3 expiration

Posted 2021-05-18 15:10:47.161830

On September 30 2021, the root CA certificate DST Root CA X3 will expire. This should not have a noticeable impact on the Internet at large, as any recently issued server certificate will have been issued with a different trust chain that’s rooted in a newer root CA.

Let’s Encrypt has relied on the DST Root CA X3 to bootstrap its services, while in parallel working to get its own root CA (ISRG Root X1) included in all OS and browser trust stores. Now that the old root is reaching its end-of-life, it is time for Let’s Encrypt to stand on its own. However, there are still devices and applications out there that do not include Let’s Encrypt’s new root CA, in particular older Android devices. So Let’s Encrypt have arranged for a fall-back solution that will work with those older devices, and it involves an ‘alternate chain’ with a ‘cross-signed’ intermediate CA.

Unfortunately Erlang/OTP applications are likely to experience TLS handshake errors when trying to connect to servers that present the longer chain. Let’s have a closer look at what is likely to happen over the next few months, and why.

Continue reading...

Erlang/OTP ssl-10.2 vulnerability explained

Posted 2021-02-14 11:55:43.909512

Erlang/OTP 23.2.2 was released about a month ago, fixing a severe certificate verification vulnerability. If you are still using OTP 23.2 or 23.2.1, please upgrade now.

In this post I will demonstrate how the vulnerability can be exploited, and I will examine the root cause. But let’s start with a quick demo…

Quick demo

Since you should no longer have a vulnerable Erlang/OTP version installed, we’ll be spinning up a Docker container of Erlang/OTP 23.2.1 for our experiments. We’re going to need a CA trust store, so we’ll install the ca-certificates package before starting an Erlang shell:

$ docker run -it --rm hexpm/erlang:23.2.1-ubuntu-focal-20201008
root@40ccfb8c5f05:/# apt-get update && apt-get install ca-certificates -y
root@40ccfb8c5f05:/# erl
Erlang/OTP 23 [erts-11.1.5] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Eshell V11.1.5  (abort with ^G)

Now let’s connect to a test server with a fake certificate, specifying the “DigiCert Global Root CA” as the trusted root:

1> ssl:start().
2> ssl:connect("", 443, [{verify, verify_peer}, {cacertfile, "/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_CA.crt"}]).

That seems to work, but if you try connecting to with a browser you’ll notice that the server’s certificate was not signed by DigiCert at all. Unaffected OTP versions (23.1 or earlier, 23.2.2 or later) also abort the TLS handshake:

2> ssl:connect("", 443, [{verify, verify_peer}, {cacertfile, "/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_CA.crt"}]).
{error,{tls_alert,{bad_certificate,"TLS client: In state wait_cert_cr at ssl_handshake.erl:1874 generated CLIENT ALERT: Fatal - Bad Certificate\n"}}}

It is time to dig a little deeper…

Continue reading...

Certificate verification vulnerability in Erlang/OTP 23.2

Posted 2021-01-15 12:06:59.472819

The ssl application version 10.2, part of Erlang/OTP 23.2 and 23.2.1, has a regression in the certificate verification logic. This could result in MitM attacks on clients, as well as unauthorized access to servers that rely on client certificates.

The vulnerability is tracked as CVE-2020-35733. A fix is available as part of ssl-10.2.1, in Erlang/OTP 23.2.2. I will post further details in a follow-up post once everyone has had a chance to upgrade.

The purpose of this post is to help you understand how the issue may affect you. The short version: if you are using an affected version of Erlang/OTP, on development machines, build servers and/or deployment targets, you should probably upgrade as soon as possible.


1. Is my application affected?

Certificate verification is primarily used by clients to detect attempts to intercept network traffic or impersonate servers. If your application includes any network clients that use TLS, it is almost certainly affected. Please refer to question 2 for details.

Some servers rely on client certificates to authenticate clients, and they too can be affected. Please refer to question 3 for more information.

2. Are the clients in my application affected?

If the application is running Erlang/OTP 23.2 and it connects to servers using TLS, the answer is almost certainly yes. Some clients do not enable certificate verification, but then such clients would have been susceptible to MitM attacks all along, regardless of Erlang/OTP version.

Some examples of affected clients include:

Clients that build on the SSH protocol, such as SFTP, are not affected.

3. Is my (web) server at risk?

TLS servers, such as web servers, generally do not perform certificate verification, unless explicitly configured to request a certificate from clients (“mutual TLS”). Therefore in practice most servers are not affected.

Servers that delegate the TLS termination to a reverse proxy (e.g. Nginx) or load balancer (e.g. HAProxy) are not affected, even if they do require client certificates.

However, if your server…

…then malicious users may be able to produce fake client certificates that will be accepted by the server. If that is the case, deploy the fix as soon as possible.

4. Is my development/build environment affected?

Possibly. Fetching packages from Hex should be safe, because the Hex client verifies the signature on downloaded packages. But API interactions with the Hex server could be intercepted, which would leak your API credentials. An attacker could then publish malicious modifications to your packages, leading to code execution vulnerabilities for the users of those packages. Do not publish Hex packages until after you have upgraded.

If you are using a tool such as kerl or asdf, uninstall Erlang/OTP 23.2 and 23.2.1, and install 23.2.2 as soon as possible.

Older posts