88

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.

jwodder
  • 166
  • 1
  • 6
Flamer
  • 859
  • 1
  • 7
  • 5
  • 5
    No one as ever tried this before, because most people know this can't work :). ---- Hint: answer from @d1str0. – dan Feb 24 '16 at 07: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 '16 at 08:46
  • @KlaymenDK: what you refering to with "list"? – Zaibis Feb 24 '16 at 12:28
  • 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 '16 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 '16 at 18:26
  • 1
    google.com isn't a hostname, is a domain. In order to make your webserver be accessible at the URL http://whatever.google.com you need to control Google's DNS, and this is far from trivial. – dr_ Feb 25 '16 at 12:31
  • 1
    Related: [How can I prevent that my users get a certificate issued for my domain on my behalf?](http://security.stackexchange.com/q/53408/12139) – unor Feb 25 '16 at 17:58
  • If OP happens to manage a company proxy server, it's trivial to control where does `google.com` point to, and what certificate does it show. @dr01 – kubanczyk Feb 25 '16 at 19:32
  • 2
    @dr01: `google.com` is indeed a hostname and has A and AAAA records. – Blrfl Feb 26 '16 at 01:29
  • @Zaibis Maybe KlaymenDK meant an array. – Michael Feb 26 '16 at 03:17
  • 1
    " Let's say I pick the cheapest and dodgiest outfit I can find." That's your first obstacle right there. There aren't a lot of dodgy CAs that are trusted. CAs entire business model depends on being trusted, and violating that trust tends to put them out of business. http://www.wired.com/2011/09/diginotar-bankruptcy/ – barbecue Feb 26 '16 at 14:03

4 Answers4

141

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.

Community
  • 1
tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 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? – TMH Feb 24 '16 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 '16 at 15:29
  • Some ISPs might not like DNSSEC. But in case of DANE the DNSSEC records on the SSL certificate needs to be validated by the client rather than the ISP. OTOH there is not much reason for validation of AAAA and A records being done on the client. Such validation would break legitimate mangling of those records like NAT64. And it wouldn't prevent hijacking anyway, because the ISP can hijack connections at the IP layer. It does make sense for the ISP to validate DNSSEC records, and in that case the validation does not prevent the ISP from mangling the records after validation. – kasperd Feb 24 '16 at 23:01
  • 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 '16 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 '16 at 15:33
  • Perhaps worth adding is that even if the CA does its job in verifying ownership, it is perfectly possible for them to issue a certificate without even realizing it, as was the case with Comodo when they got hacked and released certificates for a whole bunch of domains: https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/ – Theik Feb 25 '16 at 23:08
  • Of course, for each of the four ways of verifying ownership, you just have to control the CA's internet connection to fake the ownership. – Paŭlo Ebermann Feb 26 '16 at 19:27
19

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.

d1str0
  • 2,348
  • 14
  • 24
  • 14
    Unless it is literally a [too big to fail CA](https://googleonlinesecurity.blogspot.com/2015/09/improved-digital-certificate-security.html). – user Feb 24 '16 at 14:20
  • 3
    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 '16 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 '16 at 19:19
  • 1
    You mean buying a cert for a domain you don't own? – d1str0 Feb 24 '16 at 19:21
  • 3
    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 '16 at 06:30
4

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.

cowlicks
  • 141
  • 2
2

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.

coteyr
  • 1,506
  • 8
  • 12
  • 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](https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack) – gbjbaanb Feb 25 '16 at 15:15