# X509 Cert exploit CA check

## Assumptions

Let's theoretically assume that a browser skips the check that a certificate it receives belongs to the stated CA (that's an exercise).

How could I exploit this in order to impersonate to a server? In other words, if some client requests site A, and I have MitM capabilities, can I redirect the user to my evil site?

## My idea

I thought about forging a certificate for my evil site, and then sign the forged certificate with another forged one of a CA that I also forge, which signs the initial certificate for me (in other words: I sign for myself).

In the forged cert, I'd state that I am site A, attach my public key and in then (hash and) sign the cert with my own made up sign key $K_s$ (let's say RSA but it doesnt actually matter).

Now I'd put $K_v$ which is the public validation key as the public key of the CA cert I forge, and attach this CA cert to the server cert.

Now, when the user requests site A, I return him my evil site with the two certs I fogred.

The browser then skips the CA check and just validates the signature with the previous CA cert public key (extracting the hash and then comparing the hashes), and it's OK. I also assume here that the Trust Anchor check is also skipped, thanks to the base assumption.

Is my idea correct?

When you connect to a secure site the certificate validation happens. Certificate validation failure can happen when:

• Fields CN or SAN dont't match the site's domains. That means that the certificate was issued for a different domain.
• Invalid digital signature. Certificate has been altered.
• Unknown certificate issuer, thus unknown intermediate CA or root CA.
• Other common errors such expiration, revocation etc

Notice that an error here will warn the end-user via the browser. So the end-user has the power to trust a forged certificate if possible.

Now, in the case that you suggest, if the browser skips the root CA validation, it will only validate the digital signature in the certificate chain validation process, so it stops when reaching the CA Root. This means that the end-user will only validate digital signatures according to the certificate's Issuer public key until you hit the root CA, then process stops here without checking the key ring/trusted anchors.

This has happened in some crypto libraries among non-browser applications allowing an attacker to MITM a TLS session with forged certificates. Take a look at https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

• Thanks for the detailed explanation. So if I understand you (you haven't written it boldly) I'm right? – Jjang May 29 '16 at 12:35
• Certainly yes. The above conditions must happen in order to trick the end-user for accepting the forged certificate. In the PDF that I linked you will find apps that neither validate correctly the CA Root nor the certificate chain (any cert will fit here). For example many time ago I found some issues with Tapatalk SSL/TLS implementation where I could impersonate/forge the certificate, the result was that I deciphered all the captured sessions (they didn't validate the chain correctly). – kub0x May 29 '16 at 12:56