DST Root CA X3 expiration update

Posted 2021-08-29 11:47:43.370644

A few things have happened since my previous post:

This post corrects a few statements I made in the original post, in particular regarding the impact on Hackney: if you are a Hackney (or HTTPoison, or Tesla-with-Hackney) user you’ll find some good news further below.

I won’t cover the background again in this post, so please refer to the original post to learn more about how the DST Root CA X3 expiration on September 30th may impact BEAM TLS clients that connect to servers with Let’s Encrypt certificates.

Patch packages

The Erlang/OTP team have improved the handling of alternate certificate chains and released the following patch packages:

If you are on OTP 23.3 or 24.0 I would strongly recommend you upgrade to a patched version before the end of September. Older versions are not impacted in the same way, so no patch is available. However, those versions may still experience issues after September: keep reading for details.

Note that the new logic makes the partial_chain hook used by many TLS clients superfluous in most cases: shorter chains are now recognized and selected by the built-in certificate chain verification logic.

Continue reading...

Erlang/OTP impact of DST Root CA X3 expiration

Posted 2021-05-18 15:10:47.161830

Update: please check out this post for updates, especially regarding the impact on Hackney!

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("demo.voltone.net", 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 https://demo.voltone.net/ 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("demo.voltone.net", 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...

Older posts