An attack on public key infrastructure

By John Viega
December 30, 2008 | Comments: 3

About three years ago I was having breakfast with a friend of mine, who was talking about a particular appliance product that claimed to be able to transparently/silently intercept all SSL/TLS traffic, so that it could be inspected. He was asking me how this might be done.

In the SSL/TLS protocol, the client is supposed to validate the server. The server presents a certificate that is digitally signed, possibly with multiple signatures. The client is supposed to look at all the signatures, and try to trace the lineage back to a trusted source so they know all the endorsements on the certificate have been validated. To this day, many applications don't do this check at all, and just ignore the server certificate. Or, they do insufficient validation of the certificate (for instance, looking to see that Verisign has endorsed it, but not looking to see if it is the expected vendor's certificate).

Well, you can certainly do it if all the clients are set up to talk SSL/TLS through a proxy server. Or, you could install a root certificate on all your clients, and lie to them about who they're talking to. Or, you could just replace the valid certificate with one of your own, and most applications won't notice (though, web browsers will generally prompt the first they see the certificate). Probably the appliance in question was taking one of these approaches. But, it struck me that there was another, more devious way.

The trick is to start your own certification authority that is tied in to the main hierarchy, the certification authorities (CAs) that are already firmly rooted at the top of the PKI (public key infrastructure) trust hierarchy. If you want to start your own CA, you can go to other CAs and pay a lot of money for your own signing certificates. The certificates you sign would be endorsed by you. You wouldn't be known directly to all the client apps out there, but your credentials would be endorsed by another CA, perhaps one they do know about (and if not, somewhere up the line will be one they do know about). This establishes trust with the client in the certificates you endorse.

What can you do if you start up your own CA and get it hooked into the main trust hierarchy like this? Let's look at what can happen if a client wants to browse to, and an attacker is in the middle. The attacker can generate his own certificate for and endorse the certificate with his own CA, and present it to you. Your browser will validate it, and everything will look good, even though it is not the legitimate Citibank certificate. You won't get any warnings, or anything like that.

It's not all that hard to start your own CA, if you have the money for it. If you're going to do this, accountability is the big issue. You don't want to get caught. But, in order to start a CA, you need to go through a validation process from one of a small few CAs that have the ability to bless a new CA, which (in an ideal world) means that you have to have a legitimate front. And you'll probably have to meet people in person.

That's not an insurmountable obstacle by any means. Let's pretend I'm some nefarious middle eastern government, intent on spying on US interests in this manner. Or, the NSA, intent on spying on nefarious middle eastern governments, take your pick. Just get an intermediary to fund someone else to set up a legitimate CA, but keep enough access to the operation where you can get a copy of the signing credentials. Set up some unsuspecting stooges to take the fall if something ever goes wrong. Or, there are a few countries where you can register a corporation where the directors are anonymous. Run a legitimate ISP in that country for a small while, then go through the process.

All told, it would cost maybe $150K to launch this attack. That's not a lot for a government, or a computer mafia. And this all assumes that CAs that have the ability to bless other CAs are going to be doing their jobs when it comes to validation. In reality, there is a good chance things will be even easier to game.

Is there anything that can be done to prevent this attack? You could hardcode the certificates you're going to accept, or the CAs you're going to trust. Or, you can point out every change in a certificate. That is, if you've seen before, and you notice the change in CA, you can complain about it. But, frankly, nothing else looks wrong, and people are probably just going to click through any warning you give them.
The bigger the potential user base, the more likely it is that there will be avenues for people to game the system. I'd rather see a lot of smaller, more definitive registries that have even more stringent audit requirements, like a registry of big financial institutions, and then local registries for smaller players, and similar structures for other industries. Or, even better (though probably less usable), people and businesses could establish direct trust relationships with each other. But that's just a pipe dream... any major changes to the way we establish trust are probably too big to actually happen.

That leaves the Internet fundamentally broken.


If you want to complain or discuss, feel free to message me on twitter, @viega.

You might also be interested in:


Hey John,
Read your article and found it kinda interesting. The problem I see is why would anyone just go through the whole loop of getting a CA when they probably wouldn't get very far with malicious activities? The process in becoming a public SSL CA is a very stringent process and outweighs the gains of obtaining one. You can't just pick these things up overnight.

The reason you don't see this happening all the time is that when someone does spend $100+ k on a certificate and then has to wait through the process. The amount of damage they can do before someone really stops them would seem minimal. Do you know of any untrusting CA’s out there?

The scenario you mention where a man-in-the-middle attack could possibly destroy the integrity of information flowing to by intercepting the packets, sending the packets back to the client and impersonating the Citibank organization is a far reach (but possible). But you can crack anything depending how much money and time you want to spend.

Now, if you want something bad enough, sure you can do it but it better be worth a lot and you might want to plan for spending a lifetime on the run when you get detected (not if). My belief is probably the same as yours. The Internet is not 100% safe. With technologies such as DPI (deep packet inspections, malicious attacks, sniffing devices, etc…) you can only make it as difficult as possible to be compromised. I think that is the best you can do.

Hi John,
I really liked your article. Maybe Federated Authentication
is an aswer to all problems that PKI is facing? Here's an article describing a real life example of Federated Authentication usage:

News Topics

Recommended for You

Got a Question?