In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

Affected: opam: tls

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.…