As I understand it, with any encryption system based on a trust chain / CAs (eg SSL, TLS, S/MIME), it would be possible for a nation-state adversary (such as the NSA) to compel the CA to issue them with fraudulent certificates enabling the adversary to perform a MITM attack against all visitors to that website.

Is this correct, or do protocols such as SSL and S/MIME protect in some way against this major flaw? If so, how do they protect against it?

If my understanding is correct, and this type of attack is possible, is there anything stopping organisations such as the NSA from compelling a CA such as Versign to issue them with duplicates of all certificates, and performing a general MITM attack against all SSL secured websites (and S/MIME emails, etc)?


Yes, a nation-state adversary can get a valid certificate for any site from any CA which they have power over. Whether it's legal or not is probably another question which I'm not qualified to answer.

Keep in mind that, even if a hijacked CA starts signing certificates with CNs of popular websites like google.com in order to MITM their traffic, it will be a different certificate and thus a noticable change. One can essentially notice this change by some form of "pinning" -- i.e., associating a specific certificate or public key with a specific website.

Basic vendor-supplied pinnings have existed in Chrome for a while, but now we're seeing more interesting solutions such as TACK and Public Key Pinning, which aim to make it possible for any server admin to temporarily pin keys to their domains.

| improve this answer | |
  • 1
    Is there any reason why it would have to be a different cert? In other words, couldn't the CA issue identical certs to both Google and the NSA (for example)? Such as by duplicating the cert when they originally generate it, and handing a copy to the NSA? Clearly this would require prearrangement, but is there any technical reason why it wouldn't be possible? (Also, if you could go into more detail about "interesting solutions such as TACK and Public Key Pinning, which aim to make it possible for any server admin to temporarily pin keys to their domains", that would be great.) – Caesar Jun 30 '13 at 1:39
  • 7
    CAs do not give out private/public key pairs. They sign them. The CA never sees the private key of the certificate, all they see is the Certificate Signing Request. So the NSA would not be able to get the private key from the CA. – Darius Jahandarie Jun 30 '13 at 2:33
  • Ah yes, of course, my mistake. Still, I guess they could get hold of the private key of a specific site by subpoenaing the operators of the site for it (and requiring them not tell anyone). But at least this can't be done as a "generic" attack on all sites. – Caesar Jun 30 '13 at 3:51
  • 1
    I would suggest that you may want to change the answer from yes, to kind of. You answer that yes they can mitm, but then you explain why it would be noticeable to anyone that has been to the site before, which really means that no, it can't MITM, at least not for all cases. – AJ Henderson Jun 30 '13 at 4:47
  • @AJHenderson Good point, thanks; I clarified the opening sentence. – Darius Jahandarie Jun 30 '13 at 5:02

The EFF's SSL Observatory has generated a map of all Certificate Authorities. This map is so massive, there is a very high likelihood that one of these is compromised at any given time. The principle of the weakest link makes me quite wary of our PKI. Furthermore, it is trivial for a nation-state to afford that cost of becoming a delegate authority.

A good defense against the broken nature of our PKI is certificate pinning.

| improve this answer | |
  • Ironically, I got an SSL error when visiting the page, but I'm on an old XP netbook at the moment. – Manishearth Jul 1 '13 at 3:47

Yes, but this would be difficult to do without it being discovered.

From a purely technical standpoint you're correct, there's nothing stopping a nation-state from compelling a Certificate Authority under their jurisdiction from issuing them a fraudulent certificate, and most TLS clients (including web browsers) will silently accept that certificate without warning the user.

However, there are several factors which make this method completely infeasible for governments to use for mass surveillance, and risky even for targeted attacks.

The risk of discovery

First, it's important to note that if a CA were ever discovered to have issued fraudulent certs like this, especially for the purposes of allowing governments to conduct MITM attacks, that CA would almost certainly have their root certificates distrusted by browser vendors and other trust stores. That would put that CA out of business, and render the fraudulent certificates useless. So if a nation state wanted to compel a CA to issue fraudulent certs in this way they'd have to do so secretly, without the public being aware of it. In practice, that would be very difficult.

Discovery through Linus's Law

In the case of mass surveillance, using fraudulent certificates without being discovered would be nearly impossible. Even if web browsers didn't automatically detect that their connection was being hijacked by a fraudulent certificate (we'll cover some ways that could happen in a moment), those certificates would still necessarily be different from the ones issued to the legitimate site operators, and could therefore be detected manually. If millions of users were all being served fraudulent certificates, it's almost certain that somone would notice (maybe the site operators themselves) and the whole scheme would quickly be uncovered. It's essentially Linus's Law ("given enough eyeballs, all bugs are shallow") applied to TLS certificates.

For targeted attacks against individual users, using fraudulent certificates without being discovered is much more feasible. Only the targeted users would have an opportunity to notice that the certificates had changed, and the average user is very unlikely to even check for something like that. There is still a significant risk the fraudulent certificates would be detected through other means, however.

Discovery through HPKP

The most likely way that an average user might detect that they're using a fraudulently issued certificate is by visiting a site which uses HTTP Public Key Pinning (HPKP). HPKP is a feature of modern browsers that lets sites tell a browser "future visits to this site should only be secured using one of these known keys". If a user previously visited a site before the government started spying on them, a later visit would result in a warning message if the site presented a fraudulent certificate. This might raise the user's suspicions, and if they were to investigate why the warning message was appearing, they might discover and report the fraudulent certificate.

Discovery through leaks

It's also possible that the government agency, the CA, or one of their employees might leak the fraudulent certificates to a third party. You might assume this is unlikely, but such leaks are always a possibility, and the fraudulent certificates themselves are strong cryptographic proof that the CA that issued them is somehow compromised, so even a completely anonymous leaker would have no trouble convincing security experts of the legitimacy of their story.

The future: Certificate Transparency

But what if the nation-state only targets a small number of users, avoids spying on sites which use HPKP, and is careful to ensure that nobody leaks the fraudulent certificates to the public? Then they'd be able to get away with it, right? At the moment; yes, probably. However, there is one other way fraudulently-issued certificates might be discovered which will make this much harder in the near future: Certificate Transparency.

Certificate Transparency (CT) is a publicly-auditable logging system for TLS certificates which CAs may use to log all certificates they sign. If a fraudulent certificate were submitted to a CT log, it's likely that someone would notice. For now, it'd be easy for a government to avoid detection by simply not submitting the certificate to a log, but starting in April 2018 at least one browser (Chrome) is going to start enforcing logging for all new certificates. This means that at least 2 trusted logs would need to cryptographically sign a statement claiming they've logged a given certificate in order for it to be considered valid.

Browsers and other third-party auditors will hold the CT logs to their word by periodically checking that the certificates they claim to have logged really are in the log (though Chrome has not yet implemented this), and that the logs are consistent for all parties viewing them. (So a Certificate Transparency log can't just tell the client it logged a certificate, but pretend that certificate doesn't exist when contacted by a third party.)

Graphical illustration of the relationship between Certificate Transparency auditors, monitors, and logs.

Image source: https://www.certificate-transparency.org/how-ct-works#TOC-Typical-System-Configuration

In order to bypass these checks, a nation-state would need to compromise or coerce multiple Certificate Transparency logs and independent third-party auditors and monitors, some of which might be outside their jurisdiction, all without any of those parties leaking the nation-state's actions to the public. This would be very difficult. Difficult enough, in fact, that even a nation-state would most likely give up at this point and start considering completely different methods for surveilling their targets instead.

To summarize

Yes a government could coerce a CA into issuing them fake certificate for a site. But in order for this to work, they'd have to keep the fact that they'd obtained the certificate a secret. This means they'd have to keep their surveillance targeted at a relatively small number of users, avoid spying on sites that use HPKP, make sure nobody leaks any of their certs to the public, and, starting in April 2018, compromise a significant number of certificate transparency logs and third-party monitors and auditors all at once. In short, it's not very likely.

| improve this answer | |
  • 2
    Wow, an old question, but thanks for the really detailed new answer. One thought though: you allude to the fact that someone would notice that the key for a certain site wasn't consistent. In my experience though, many sites use inconsistent keys due to having geographically distributed servers or a CDN. For example Google uses different keys on almost every page load. In Google's case they have their own CA, but this isn't the case with (for example) Cloudflare. So for a site where certs were inconsistent anyway, it might be less likely that an additional 'rogue' cert would be noticed. – Caesar Oct 29 '17 at 3:11

It depends if the CA is behaving properly when issuing certificates and if the person has been to your site before. If a CA is behaving properly when you get your certificate, they should not keep your private key. In fact in many cases, you can actually form your own private key if you wish.

Provided that you have the only copy of the private key, all the CA can do is issue another certificate (for a different private key) that will be trusted as your domain. Any CA could in fact do this. It doesn't have to be yours. It just has to be some CA that is trusted in your visitor's browser.

However, when someone first visits a site protected with SSL, the browser remembers the fingerprint of the certificate. If the SSL cert changes from one visit to another, then the browser should give a warning. Thus, if a government entity gets a certificate signed by a trusted CA saying that it is your domain, it would still have a different fingerprint and while new users wouldn't be aware of them being in the middle, any previous users should be able to detect the man in the middle attack.

| improve this answer | |
  • 3
    Most browsers do not actually give warnings for certificate changes. – Darius Jahandarie Jun 30 '13 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.