2

I have some questions about certificate pinning.

Supposing that a mobile application has pinned only the root CA, it should be possible to an attacker to redirect in some way the victim to a malicious website with the same Root CA. Am I wrong?

  • What happens, instead, if an app pins the Root CA but verifies the hostname of the server which the app is connecting to?
  • If the attacker owns a website under the same Root CA, can he poison DNS-cache and let the app connect to his website or there are security mechanisms which prevent such behaviour?
0

2 Answers 2

0

... it should be possible to an attacker to redirect in some way the victim to a malicious website with the same Root CA.

This will only be possible if the client blindly believes any certificate signed by this CA. This level of trust should of course not be done if the root CA might also issue certificates to an attacker, as is the case with common public CA. That's why a TLS client is supposed to verify if the subject of the certificate matches the expectation too, i.e. if the specified target hostname or IP is covered by the certificate.

... pins the Root CA but verifies the hostname of the server which the app is connecting to

That's what a properly written app will do.

If the attacker owns a website under the same Root CA, can he poison DNS-cache and let the app connect to his website or there are security mechanisms which prevent such behaviour?

The client should check the subject of the certificate with the intended hostname or IP. While DNS lookup of a domain might result an alias (CNAME) this will not change the intended hostname, but is only an internal step in getting the IP address. This means DNS poisoning against the client cannot be used to change the intended domain and therefore the attacker needs to have a certificate for the intended domain - which the CA should not issue since the attacker cannot proof to own it.

But, DNS poisoning against the CA might be use to fake the proof of ownership in domain validated certificates. In this case the attacker could get a valid certificate for the target domain which then can be used against the client, for example in a DNS poisoning attack against the client.

0

No, provided that the pinning is implemented correctly

Pinning (at least, pinning other than the cert or public key itself[1]) is supposed to be in addition to standard certificate validation. Standard certificate validation (for TLS in particular) consists of the following steps:

  • Verify that the host name is an allowed subject name on the cert
  • Verify that the certificate is issued by a trusted certificate authority (or an intermediate CA that chains to a trusted one)
  • Verify that the certificate's signature is valid (this is technically part of the prior step, since checking the signature is how you verify the issuer)
  • Verify that the cert is within its validity period

Additional steps that should be taken, but that some clients omit (for better or worse reasons):

  • Verify that the certificate usage is correct (there are multiple layers of such validation, depending on which extensions are in use)
  • Verify that the certificate has not been revoked (by checking the CA's CRL or remote or stapled OCSP)
  • Verify that the certificate against the certificate transparency (CT) log, to ensure it was issued by who it says it was (and ideally that there isn't another cert issued by somebody else for the same site, though in practice I don't think any clients prevent connecting in that event)

Notice that these steps already protect against DNS tampering. An attacker can manipulate DNS to make your client connect to the wrong server, but they can't make your client accept a certificate with the wrong name, untrusted issuer, or broken signature (meaning they can't supply a different certificate than the legitimate one and expect it to work), and if they supply the legitimate certificate then (hopefully!) they don't have the corresponding private key so they can't complete the TLS handshake anyhow. As such, so long as you don't turn off the standard certificate validation process, you are already protected against DNS spoofing, cache poisoning, or similar attacks.

Pinning is an additional layer of protection. Unlike any of the seven bullet points above, it's not something that you can realistically expect clients to implement universally, because it requires knowledge not encoded in either the root certificate, leaf certificate, domain name, or basic TLS protocol. The client needs to know, through some additional knowledge source, what pin to expect, at what level. However, in practice, this is common for applications that only communicate with their developers' own servers. Pinning a CA (root or intermediate) rather than the cert (or even pubkey) itself is reasonably popular as a compromise between maximum security and minimal risk of breakage[2]. However, you don't simply verify that the leaf cert was issued by that CA and treat it as valid; matching the pinned CA is necessary but not sufficient for accepting the leaf (server) certificate.


[1] In theory, pinning the certificate itself is sufficiently secure that you don't need to validate the issuer, signature, or any metadata. If the certificate (or at least its hash digest) matches what the client expects, you can be pretty sure it's trusted! In practice, though, this is unsafe; at a minimum, you should also check that the cert is not revoked, and in general it is a very bad idea to turn off any aspect of certificate validation unless you know what you're doing quite well.

[2] The most common worry about fraudulent certs comes from either a compromised CA or one that is controlled by a malicious government. As such, pinning a trusted CA neatly avoids this problem, while still allowing frequent certificate rotation without any risk of being rejected by clients for the pin being invalid. Pinning the certificate itself, or even just its public key, is also possible and arguably more secure, but you should only do it if you include a backup pin that will be used if the primary needs to be revoked for some reason, and if you are sure that you can update all of the clients before both primary and backup will be revoked.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .