What prevents me from buying a SSL certificate for a domain I don't control?

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.

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.

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.