Erlang/OTP 20.1.7

This release of Erlang/OTP can be built from source or installed using pre-built packages for your OS or third-party tools (such as kerl or asdf).

docker run -it erlang:20.1.7
Patch Package OTP 20.1.7
Git Tag OTP-20.1.7
Date 2017-11-22
System OTP
Release 20

public_key-1.5.1 #

The public_key-1.5.1 application can be applied independently of other applications on a full OTP 20 installation.


Hostname verification: Add handling of the general name iPAddress in certificate's subject alternative name extension (subjAltName).


Correct key handling in pkix_test_data/1 and use a generic example mail address instead of an existing one.

Full runtime dependencies of public_key-1.5.1: asn1-3.0, crypto-3.8, erts-6.0, kernel-3.0, stdlib-2.0

ssl-8.2.2 #

Note! The ssl-8.2.2 application can *not* be applied independently of other applications on an arbitrary OTP 20 installation. On a full OTP 20 installation, also the following runtime dependency has to be satisfied: -- public_key-1.5 (first satisfied in OTP 20.1)


TLS sessions must be registered with SNI if provided, so that sessions where client hostname verification would fail can not connect reusing a session created when the server name verification succeeded.

Thanks to Graham Christensen for reporting this.


An erlang TLS server configured with cipher suites using rsa key exchange, may be vulnerable to an Adaptive Chosen Ciphertext attack (AKA Bleichenbacher attack) against RSA, which when exploited, may result in plaintext recovery of encrypted messages and/or a Man-in-the-middle (MiTM) attack, despite the attacker not having gained access to the server’s private key itself. CVE-2017-1000385

Exploiting this vulnerability to perform plaintext recovery of encrypted messages will, in most practical cases, allow an attacker to read the plaintext only after the session has completed. Only TLS sessions established using RSA key exchange are vulnerable to this attack.

Exploiting this vulnerability to conduct a MiTM attack requires the attacker to complete the initial attack, which may require thousands of server requests, during the handshake phase of the targeted session within the window of the configured handshake timeout. This attack may be conducted against any TLS session using RSA signatures, but only if cipher suites using RSA key exchange are also enabled on the server. The limited window of opportunity, limitations in bandwidth, and latency make this attack significantly more difficult to execute.

RSA key exchange is enabled by default although least prioritized if server order is honored. For such a cipher suite to be chosen it must also be supported by the client and probably the only shared cipher suite.

Captured TLS sessions encrypted with ephemeral cipher suites (DHE or ECDHE) are not at risk for subsequent decryption due to this vulnerability.

As a workaround if default cipher suite configuration was used you can configure the server to not use vulnerable suites with the ciphers option like this:

{ciphers, [Suite || Suite <- ssl:cipher_suites(), element(1,Suite) =/= rsa]}

that is your code will look somethingh like this:

ssl:listen(Port, [{ciphers, [Suite || Suite <- ssl:cipher_suites(), element(1,S) =/= rsa]} | Options]).

Thanks to Hanno Böck, Juraj Somorovsky and Craig Young for reporting this vulnerability.


If no SNI is available and the hostname is an IP-address also check for IP-address match. This check is not as good as a DNS hostname check and certificates using IP-address are not recommended.

Thanks to Graham Christensen for reporting this.

Full runtime dependencies of ssl-8.2.2: crypto-3.3, erts-7.0, inets-5.10.7, kernel-3.0, public_key-1.5, stdlib-3.2