Why can't a hacker just obtain a new SSL certificate for your website?

Question

SSL is meant to protect your website from a man-in-the-middle attack.

But if someone is able to do that, couldn't that just request a new certificate from a CA and then modify the traffic sent from the CA to the server (which obviously can't be encrypted) to pass whatever test the CA requires as verification of ownership?

Related: [*How to stop/detect someone else registering a certificate for my domain*](http://security.stackexchange.com/q/36826/12139) · [*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, Dec 20 '16 at 12:10
Why do you say "which obviously can't be encrypted"? Presumably the CA has a certificate and encryption only requires one side to prove its identity to the other. — David Schwartz, Dec 20 '16 at 22:36
@DavidSchwartz: I mean that since a certificate request is usually done by someone who doesn't have one yet, a man-in-the-middle attack would be impossible to detect by the CA. — , Dec 20 '16 at 23:36
The person submitting the certificate request can trivially detect that they're not talking to the CA since the CA has a certificate. — David Schwartz, Dec 20 '16 at 23:44
The actual domain owner is not submitting any certificate request. Only the hacker submits a request and then, if he's able to MitM, intercepts any mail, DNS requests, or HTTP requests sent by the CA to the server as verification of ownership. (But, as I've learnt, this is impossible since ownership is in fact verified by changing a DNS entry on example.com, which is stored on the .com TLD server) — , Dec 21 '16 at 00:18

score 42 · Accepted Answer · answered Dec 19 '16 at 22:10

42

Being able to MitM a certificate authority is perhaps not as trivial as you imagine. You don't know what machine they're using to evaluate ownership, and hopefully they aren't doing this over Starbucks wifi.

Certificates apply to domain names, not machines or IP addresses, and thus ownership is generally not verified by testing responses given by a certain HTTP server. For instance, taking a look at Mozilla's requirements for CAs,

We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:

all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate;

for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;

for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant’s behalf;

for certificates to be used for and marked as Extended Validation, the CA complies with Guidelines for the Issuance and Management of Extended Validation Certificates version 1.4 or later.

So you would need to either MitM the connection between the CA and a DNS server, or compromise the site's DNS (the more likely one).

answered Dec 19 '16 at 22:10

Xiong Chiamiov

9,384
2
34
76

1

I think I understand. Let's Encrypt gives an example of this on https://letsencrypt.org/how-it-works/. To pass their automated domain validation, you need to be able to either place a file, such as https://www.example.com/8303 (over HTTPS, which means that you already have a valid certificate from another CA) or add a DNS record to example.com, which, as you said, can only be done if you can MitM the CA or the TLD's DNS server. – Dec 19 '16 at 22:46
I have another question: Let's Encrypt supports certificates for third-level domains, which means that a MitM on example.com's DNS server (not .com's DNS server) would allow someone to create something.example.com and an SSL certificate for it, right? Or is something such as DNSSEC used when checking the third level domain? – Dec 20 '16 at 01:54
4

@Runemoro: Generally third level domains belong to the person who owns the second level domain. So the fact that I can create a certificate to server1.slebetman.com from the certificate of slebetman.com is not considered a security issue because I own both domains. However, there are cases where third parties use a subdomain (the proper name for N-level domains) that's a part of someone else's domain. For example if you have a runemoro.blogger.com blog then blogger.com can create an ssl certificate to your blog. But in such cases you also run your blog on someone else's server – slebetman Dec 20 '16 at 06:30
2

And I'm not aware of any DNS providers that allow you to resell a subdomain in a way that you don't retain control over it. I mean, I *could* sell you "maybe.programmingismagic.com", but I can still choose what IP that points to. So if you're worried about security, maybe you shouldn't be doing that, unless you trust me. – Wayne Werner Dec 20 '16 at 13:44
2

@Runemoro When requesting a certificate for foo.bar.example, you will (for the http-01 challenge) need to make a file reachable at ``http://foo.bar.example:80/.well-known/acme-challenge/…``. This also helps with subdomain resellers or domains like ``co.uk`` which would otherwise need to be special cased. – Jonas Schäfer Dec 20 '16 at 14:36
3

@Runemoro: For the purpose of public domain name system, the real owner of the domain also owns the subdomains below it. You may think you have subleased a subdomain from someone else, but certificate authorities and public domain name registrars do not acknowledge that subleases. Resale of subdomains is a private matter between the subleasee and the domain owner. – Lie Ryan Dec 20 '16 at 15:14
2

"Certificates apply to domain names, not machines or IP addresses, and thus ownership is generally not verified by testing responses given by a certain HTTP server." Pretty sure a lot of common CAs do exactly that. For example, [Comodo](https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/0/alternative-methods-of-domain-control-validation-dcv) and [Let's Encrypt](https://letsencrypt.github.io/acme-spec/#rfc.section.7.1) both allow this. – Ajedi32 Dec 20 '16 at 16:20

Jasen · Answer 2 · 2016-12-20T00:47:28.750

The certificate issuer promises to only issue a certificate for your domain name to people who can prove they have control of that domain

I guess a man in the middle attack against both HTTP and SMTP could be used to deceive the issuer and thus get a "domain-control validated" certificate to which the attacker is not entitled, this fraudulent certificate could then be used to impersonate your site in a man-in-the middle attack against HTTPS traffic. if the HTTP ans SMTP servers are different then two MITM attacks will be needed.

The extended validation certificates (like used by banks) that display a long green message in the address bar require more steps than just proving control of the domain name, and could probably not be fraudulently acquired as easily.

score 2 · Answer 3 · edited Dec 20 '16 at 20:26

HPKP (HTTP Public Key Pinning) is a security policy delivered via an HTTP response header that:

allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future

protects a host website from a security compromise at a Certificate Authority where rogue certificates may be issued

allows a host to deliver a set of fingerprints to cryptographic identities that the User Agent (UA) should accept for the site going forwards

is a Trust On First Use (TOFU) mechanism and the UA must establish at least one secure session with the host to receive the header intact. Once the header has been received, the UA will cache and apply the policy as per the directives included in the header

Answering your question: a host that implements HPKP prevents hackers of using new/rogue SSL certificates.

HPKP may be easy to setup, but it should be carefully done and it is "essential" to have backups:

the most ideal solution is to include the fingerprint of the current TLS certificate and at least one backup

the backup can be the fingerprint of a Certificate Signing Request (CSR), thus avoiding the need to purchase a backup certificate

if the private key of the certificate were ever compromised, a CSR could be used in order to request the signing of a new public key (for this to work, the CSR has to be created with a brand new RSA key pair and stored securely offline)

as the fingerprint of the CSR was already in the HPKP header, switching out to the new certificate can be accomplished without a problem

using this method, if any CA was ever compromised, even your own CA, any rogue certificates that were issued for your domain would not be accepted by a browser that had received the HPKP header

because the fingerprint of the rogue certificate has not been received and cached by the browser, it will be rejected and a connection to the site won't be allowed

This means that if all your backups are lost then:

you only have until your current certificate expires to get a new policy out to all of your visitors!

Perhaps this is why not many websites currently implement HPKP (scan for a few examples in securityheaders.io and you may find that most online banks do not, e.g. JP Morgan), but it does specifically address/solve the problem raised by your question.

score 0 · Answer 4 · edited Dec 21 '16 at 00:21

The basis of certificate security is that a third party (the issuer) certifies that the certificate has been delivered to someone having appropriate rights on the domain.

If as a client I trust the issuer, I can trust any certificate it has signed.

The possible frauds are:

someone comes with fake documents showing that he owns the domain. Could be done, but issuer must be very cautious about that because that part is their real job, and if they can easily be cheated nobody will trust them any more
someone hacks an issuer and gets a valid private key allowing certificate signing. The security rules in serious certificate issuers tends to make this extremely hard, and it is likely that the stolen certificate will soon be revoked

In fact, it is generally assumed that the cost of obtaining a fake certificate will not be worth it. There are plenty other simpler ways to steal information on the web, on in real life.
Never forget what can be done with a $5 wrench…

Of course things may be different when you think of government agencies. I have no real proof whether it is true or not, but I think that is state security was really concerned, they could ask a valid certificate for a third party domain to do legal interceptions.

Why can't a hacker just obtain a new SSL certificate for your website?

4 Answers4