We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
mTLS: When Certificate Authentication is Done Wrong
Discover the hidden vulnerabilities in mTLS certificate authentication, where first-certificate checks fail, clients can send bogus certificates, and certificate stores can be exploited for attacks.
- Certificate verification in MTLS only checks the first certificate and implies trust for the rest of the chain.
- Clients can send as many certificates as they want, but the server only verifies the first one.
- Certificate stores can be exploited for LDAP and SQL injection attacks.
- Lack of basic constraint checking can be used to bypass authentication.
- Certificate chains can be trusted just based on the signature, without requiring the root certificate.
- Attackers can send a list of certificates, including a self-signed one with a username, to gain unauthorized access.
- The issuer field can be used to construct SQL or LDAP queries, leading to injection attacks.
- The subject field can be used to build an LDAP query, making it vulnerable to exploitation.
- Certificate revocation checking can be exploited for SSRF or RCE attacks.
- The CRLDP extension can contain a URL pointing to a Netcat listener, allowing for SSRF attacks.
- The Bouncy Castle library’s use of the CRLDP extension makes it vulnerable to external code execution.
- Imperial CAS uses a custom library for LDAP connections, making it vulnerable to external code execution.
- Certificate stores can be hardcoded into the application or taken from the certificate itself.
- The blame forge extension makes it easy to construct a valid certificate with a different username.
- MTLS can be used as an additional factor for authentication.