Improper Validation of Consistency within Input vulnerability in Erlang OTP ssl (tlshandshake13, sslhandshake and tlsclientticketstore modules) allows a malicious TLS 1.3 server to cause a denial of service of the ssl application on the client node.
The TLS 1.3 client decodes the extensions of a NewSessionTicket message as if they came from EncryptedExtensions. It therefore accepts a 0-length earlydata extension, a form that is only valid in ClientHello and EncryptedExtensions. With {sessiontickets, auto}, the client stores the ticket in the node-global tlsclientticketstore. On the next automatic resumption, tlshandshake13:getmaxearlydata/1 crashes the store with a caseclause. Repeated crashes can exceed the restart intensity of the ssl supervisors, which use the restforone strategy, and take down ssl for all connections on the node.
This issue affects OTP from OTP 23.3 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to ssl from 10.3 before 11.2.12.14, 11.6.0.7, and 11.7.8.
Improper Certificate Validation vulnerability in the ssl application in Erlang/OTP allows a client that holds a certificate trusted by one SNI virtual host to authenticate to a second SNI virtual host on the same listener by resuming its TLS 1.2 session there. A server that serves several SNI names from one listen socket through snifun or snihosts keeps one pre-TLS 1.3 session cache per listener and does not bind a cached session to the SNI name or client trust policy that established it. When an SNI option set switches to verifypeer without naming reusesessions, sslconfig:updateoptions/3 inherits the base listener's reusesessions value of true, so the default that disables reuse for client-authenticating servers does not apply. On an abbreviated handshake sslsession:isresumable/4 checks only that the cached session uses one of the current server certificates and carries some peer certificate, and never revalidates that certificate against the CA selected for the requested name. The names must share a server certificate, which is common with wildcard or multi-SAN certificates. TLS 1.3 does not use this cache and is not affected. This issue affects OTP from OTP 18.0 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to ssl from 7.0 before 11.2.12.14, 11.6.0.7, and 11.7.8.
Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeyocsp module) allows OCSP designated-responder authorization bypass via missing signature verification.
The OCSP response validation in publickey:pkixocspvalidate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid.
This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the publickey:pkixocspvalidate/5 API directly are also affected, with impact depending on usage context.
This vulnerability is associated with program files lib/publickey/src/pubkeyocsp.erl and program routines pubkeyocsp:isauthorizedresponder/3.
This issue affects OTP from OTP 27.0 until OTP 28.4.2 and 27.3.4.10 corresponding to publickey from 1.16 until 1.20.3 and 1.17.1.2, and ssl from 11.2 until 11.5.4 and 11.2.12.7.