OSEC-2026-06

The ocaml-TLS 1.3 client does not validate the KeyUsage and ExtendedKeyUsage extensions of the server certificate. This can lead to impersonation with a certificate issued to a client.

Scenario

Every employee at a major bank carries a smart card. The card holds a clientAuth certificate issued by the bank's corporate PKI: identifying the employee for VPN, for badge access, for signing emails. The certificate's Extended Key Usage field marks it "TLS client, not TLS server" — the bank's own CA states what the cert may and may not do. To an ocaml-tls TLS 1.3 client, the marking is invisible. A laptop pulled from a desk, a smart card left in a coffee shop, malware on a workstation — anyone holding any clientAuth cert from any CA in the trust store, with a SAN naming a hostname an ocaml-tls client connects to, impersonates that hostname as a TLS 1.3 server. The same hole catches public-CA misissuance, codeSigning certs with DNS SANs, S/MIME certs with DNS SANs. Any cert in any non-server class becomes a TLS 1.3 server cert.

RFC 5280 §4.2.1.12 binds a cert with an Extended Key Usage extension to the indicated purposes; RFC 8446 §4.4.2.4 carries the constraint into TLS 1.3. ocaml-tls enforces it on its TLS 1.2 path — validate_keyusage in handshake_client.ml:201 checks for Server_auth, wired to answer_certificate_RSA and answer_certificate_DHE. When TLS 1.3 was added, a separate answer_certificate was written in handshake_client13.ml; the EKU check was not ported.

Detailed description

ocaml-tls clients complete the TLS 1.3 handshake with a server presenting a leaf certificate whose Extended Key Usage extension omits id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1). The probe leaf carries id-kp-clientAuth (1.3.6.1.5.5.7.3.2) and id-kp-codeSigning (1.3.6.1.5.5.7.3.3) only — the cert was issued by its CA for purposes other than TLS server authentication. ocaml-tls accepts the cert, completes ECDHE, verifies CertificateVerify, and delivers application data.

The library has the correct EKU check, in handshake_client.ml:201:validate_keyusage. The TLS 1.3 entry point in handshake_client13.ml:answer_certificate is simply not wired to it. TLS 1.2 handshakes through answer_certificate_RSA and answer_certificate_DHE correctly reject a non-serverAuth cert; the same library accepts it on the TLS 1.3 path.

A sibling finding reports the same class of gap for the KeyUsage extension.

Attack

Numbered attack sequence:

1. Attacker obtains a leaf cert from any CA in the victim's trust store, with EKU including any of clientAuth, codeSigning, emailProtection, etc. — and excluding serverAuth. Practical sources: commercial S/MIME CAs, code-signing CAs, internal corporate PKI that issues clientAuth certs, public-CA misissuance.
2. Attacker stands up a TLS 1.3 server with that cert and binds the leaf's SAN hostname to a network position the victim's client will reach (DNS spoof, BGP hijack, captive portal, off-path redirect).
3. ocaml-tls 1.3 client opens a handshake. Server presents the non-serverAuth cert in its Certificate message.
4. validate_chain returns Ok. The TLS 1.3 path advances toAwaitServerCertificateVerify13 without checking EKU.
5. CertificateVerify is signed correctly (attacker holds the leaf's private key); signature verifies.
6. Handshake completes. Application data flows over the attacker-authenticated session.

ASCII trace:

Attacker                     ocaml-tls client
--------                     ----------------
(holds a cert issued with
 EKU=clientAuth + codeSigning
 from a CA the victim trusts)
ServerHello ------------->
Certificate(EKU=¬serverAuth) -> validate_chain → Ok
CertificateVerify ---------> signature OK
Finished ----------------->
                             ACCEPT
{AppData} <------>           delivered to application

Attack properties:

• The CA-issuance boundary that normally separates "may run a TLS server for this name" from "may sign email" or "may sign code" is erased at the handshake.
• Hostname binding (SAN) is enforced; the attacker still needs the SAN to match the connected hostname. CAs that issue clientAuth or codeSigning certs commonly bind hostnames in the SAN (corporate-PKI clientAuth certs frequently encode the workstation FQDN).
• Public CA misissuance scenarios — accidentally dropping serverAuth from an EKU set, or shipping id-kp-codeSigning alongside SANs intended for TLS — are plausible failure modes given the cert-template surface area; we are not citing a specific documented incident here.

Scope

In scope. All TLS 1.3 client connections through ocaml-tls using x509 cert validation against any trust anchor. Affected populations: MirageOS unikernels, Robur deployments, OCaml apps using mirleft/ocaml-tls for TLS 1.3 client sockets.

Trust model. Production clients trust hundreds of CAs (Mozilla bundle, OS root store, corporate PKI). Many of those CAs legitimately issue certs for purposes other than TLS server auth — S/MIME, code signing, document signing, client auth. Per RFC 5280 §4.2.1.12 the leaf's EKU constrains what each specific cert may be used for. Loading the issuer is the baseline for any TLS handshake to validate at all; ignoring the leaf's EKU is the gap.

Not in scope.

• TLS 1.2 connections via the same library — validate_keyusage is wired to the TLS 1.2 paths and rejects non-serverAuth certs.
• ocaml-tls server-side accepting client certs — separate code path, not exercised by this finding.
• mirage-crypto / nocrypto — pure crypto primitives, not in the cert-validation path.
• "Stolen private key" variants — out of scope; this finding requires only that the attacker hold a legitimately-issued cert for a non-server purpose, not that they compromise a serverAuth cert.

Timeline

• 2026-04-18: vulnerability discovered
• 2026-04-30: vulnerability reported to the OCaml security team
• 2026-05-05: initial patch prepared
• 2026-05-09: additional keyUsage vulnerability reported
• 2026-05-10: final patch prepared
• 2026-05-14: patch approved by reporter
• 2026-05-20: ocaml-tls 2.1.0 released, security advisory published