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.

Improve this question
11
  • 5
    No one as ever tried this before, because most people know this can't work :). ---- Hint: answer from @d1str0.
    – dan
    Feb 24, 2016 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, 2016 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, 2016 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, 2016 at 18:26
  • 2
    @dr01: google.com is indeed a hostname and has A and AAAA records.
    – Blrfl
    Feb 26, 2016 at 1:29

4 Answers 4

Reset to default
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.

Improve this answer
7
  • 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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 15:33
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.

Improve this answer
5
  • 14
    Unless it is literally a too big to fail CA.
    – user
    Feb 24, 2016 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, 2016 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, 2016 at 19:19
  • 1
    You mean buying a cert for a domain you don't own?
    – d1str0
    Feb 24, 2016 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, 2016 at 6: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.

Improve this answer
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.

Improve this answer
1
  • 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, 2016 at 15:15

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.