Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can I simply build a webserver, make its hostname "google.com", create a CSR off that server, and send that to a Certificate Authority for signing? Let's say I pick the cheapest and dodgiest outfit I can find.

Will that work? What mechanisms are in place to stop people from doing this?

I am well aware that I won't receive any traffic destined to google.com due to the DNS records pointing to the real Google, but I could MitM attack any Google traffic using this method. I could also redirect local traffic to my own server without the users knowing any better.

share|improve this question
4  
No one as ever tried this before, because most people know this can't work :). ---- Hint: answer from @d1str0. – daniel Azuelos Feb 24 at 7:36
8  
Unless you want to "end up on a list", you should consider changing the "can I do ..." form to a "could one do..." form. ;-) – KlaymenDK Feb 24 at 8:46
5  
I'm sure this question is merely a mental exercise, but he makes it sound as if he actually intends to do a MITM attack on Google's domain. It was a tongue-in-cheek comment about the ever-watchful eye of the powers that be. – KlaymenDK Feb 24 at 12:34
3  
You could even sign your csr yourself. The problem is to get signed by a CA that is in the list of standard root CAs trusted by the major applications (typically, the major browser vendors). – Hagen von Eitzen Feb 24 at 18:26
1  
google.com isn't a hostname, is a domain. In order to make your webserver be accessible at the URL whatever.google.com you need to control Google's DNS, and this is far from trivial. – dr01 Feb 25 at 12:31
up vote 136 down vote accepted

This is more of a problem than you think, particularly for a company like Google, because they're a frequent target for this type of shenanigans. But there are several layers of safeguards, and our protection is getting better over time.

Your first line of defense is the Certificate Authority.

They shouldn't let certificates be signed inappropriately. Each CA has its own mechanism for verifying your entitlement to purchase a cert for a given domain, but typically it includes having you do one or more of the following:

  • Verify ownership of the email address listed in the WHOIS info for the domain.
  • Verify ownership of an email address that follows one of several predetermined patterns on the domain (e.g. "administrator@{domain}")
  • Create a specific DNS record on the domain
  • Make a specific change to the website hosted at that domain

But with as many CAs as we have, a surprising number of inappropriate certs get issued. This is a case of, "you had literally ONE job," but we have to accept that mistakes will happen.

Certificate Transparency was created to help audit the CAs

There's a surprising lack of accountability and transparency on the part of CAs, so Google decided to do something about it with Certificate Transparency.

This is a public log of every certificate that the CA signs; if a cert doesn't show up in the log then it's not valid, and the log is append-only; you can't go back and scrub your history. It's still relatively new, but Chrome already requires it on certain CAs, including all EV CAs. The idea is that you can follow the log and see if your domain shows up when it shouldn't. Tools are still evolving to make this simpler, but it's a very promising technology.

Your final line of defense is key pinning

The more secure browsers will allow domain owners to "pin" one or more public keys to their domain. This is an end-around the whole PKI system and injects the trust directly into the browser. Domain owners can, via HTTP header, tell the browser to only allow certs with specific public keys, and can in fact ship that assertion pre-installed on the browser itself. This prevents an unauthorized certificate from being used, even if it has a valid CA signature.

DNSSEC and DANE is where this is eventually going to go

Probably. With DNSSEC, you can sign your DNS records, which means that you can put your public key signature right there in DNS. Which means you don't need a third-party certificate authority to sign your keys. That's a pretty elegant solution, but DNSSEC is a way off still; you can't use it with a number of OSes, and adoption is positively glacial.

share|improve this answer
1  
Just wondering, you say adoption of some of these things is slow, do you know why that might be? Could it be parties don't believe in the solution / there hard to implement / not tested yet / unknown side affects / company X doesn't want to do something company Y came up with / something else / all of the above? – Tom Hart Feb 24 at 11:09
33  
@TomHart generally adoption of security measures is slow when it would force more honesty onto a party than they want. CAs don't like Certificate Transparency because it makes their mistakes public. Some ISPs don't much like dnssec because it prevents them from "customizing" DNS responses. Any debate about the protocols themselves gives uninterested parties an excuse to drag their feet. – tylerl Feb 24 at 15:29
    
Ahh that makes sense, thanks! – Tom Hart Feb 24 at 15:42
1  
Incidentally pinning only works for a limited number of big boys - eg Chrome pins Google's key to alert you to rogue or fake Google domains, but does nothing if you're visiting a fake Microsoft domain. DNSSEC is certainly the answer to what is currently a "fingers-crossed and hope" system. – gbjbaanb Feb 25 at 15:18
2  
@gbjbaanb Anyone can enable pinning on their cert, but the site operator has to turn it on and, optionally, opt-in to distributing their key signatures with the browser. – tylerl Feb 25 at 15:33

You need to prove DNS ownership before someone will sign a certificate for a given domain name.

Just creating a CSR with the domain of Google won't be enough.

If a certificate authority actually provided you a valid Cert for a domain you did not prove ownership of, that CA would be distrusted by people immediately and their root certs would be removed from trust stores.

share|improve this answer
13  
Unless it is literally a too big to fail CA. – Michael Kjörling Feb 24 at 14:20
2  
Your last statement is far too strong. For the CA to be distrusted, it would first have to be discovered. Unless the site is massively used and monitored like Google, it's unlikely to be discovered. – Steve Sether Feb 24 at 18:47
2  
Also, "buying a CA cert for a certificate you don't own" is exactly what happened when TrustWave sold a subordinate CA cert to some business (not a CA). Trustwave rightly deserved to be distrusted. But they weren't. Rules are only as good as the people who choose to follow them, and the browsers aren't doing a good job of this. – Steve Sether Feb 24 at 19:19
1  
You mean buying a cert for a domain you don't own? – d1str0 Feb 24 at 19:21
    
I buy certs for a very large corporation all the time from several CAs.... I fill out a form and really the only "proof" is using my corporate email. Is this what you think is proof? – blankip Feb 26 at 6:30

In theory, for current certificate authorities this is possible. But there are many safegaurds in place. But this has been answered already.

However this is not possible with the letsencrypt certificate authority. Because it uses the ACME protocol to prove domain name ownership.

Basically you run the letsencrypt client which talks to the letsencrypt certificate authority's servers using the ACME protocol to prove you own the domain name which you claim. Once this is proven you are issued a new certificate, for free, and automatically.

share|improve this answer

Short answer; YES, it could work

Given the way certs work, if you could find a CA that was crappy enough to do it, you could end up with a cert that says your Google.com.

The problem is that CA's are supposed to verify your identity. That's their whole purpose. One that does a bad job at it is not going to be around long.

Usually these less then trust worthy CAs are 4th and 5th level in a trust chain, and usually they are identified and removed from the trust chain swiftly.

That said, when looking at just certs, the CA is the last line of defense, so if you can find one that will certify that your are google.com without the proper research, then you will end up with a certificate proving you are google.com. (again probably for a very short time)

It's important to note that this is a serious vector for attack, and a problem for larger servers. It's also a possible (but less used) vector of attack if you can add a root cert to a client via malicious code.

There are some "fixes" in the works, like DNSSEC, but it will be a while before that is widely used.

Today the best protection is making sure that your clients root certificates are sane, and not adding to them.

share|improve this answer
    
what do you mean "could" - it has worked, if you recall someone managed to buy a certificate registered to Microsoft several years back on the live.fi domain (which is pretty low-tech attack but nevertheless worked), or the hacks that had valid certificates for Google, Microsoft and Nokia issued by DigiNotar – gbjbaanb Feb 25 at 15:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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