Extended checks if domain already has a EV certificate

Hello! There's a story on wired about hackers that not only hijacked DNS records of an online bank but also received a certificate from Let's encrypt:

And those sites even had valid HTTPS certificates issued in the name of the bank, so that visitors’ browsers would show a green lock and the bank’s name, just as they would with the real sites. Kaspersky found that the certificates had been issued six months earlier by Let’s Encrypt, the non-profit certificate authority that’s made obtaining an HTTPS certificate easier in the hopes of increasing HTTPS adoption.

“If an entity gained control of DNS, and thus gained effective control over a domain, it may be possible for that entity to get a certificate from us,” says Let’s Encrypt founder Josh Aas. “Such issuance would not constitute mis-issuance on our part, because the entity receiving the certificate would have been able to properly demonstrate control over the domain.”

I agree that domain control is a valid ground to request a DV certificate and it's NOT mis-issuance by Let's Encrypt.

However, my question is: would it be possible to implement an automated check if domain already has (or recently had) a valid EV certificate? Such cases are extremely suspicous and I don't think there're going to be many. Why anyone who spent money and time to get the extended validation would switch to a free DV? This looks like a good reason to put the request on hold and double-check what is the site in question. If it's an online bank, retailer etc then it's 99% chance of a fraud.

[offtopic] I also believe that browsers should warn users when validation level changes even when there's no HPKP. Personally, I'd also look into CA changes which are also rather rare (compared to certificate re-issuance within the same CA).

hi @salmin

That is the whole point of four key initiatives in PKI

I am not going to describe these here as they are well documented and google is your friend

A) Certificate Transparency

B) HTTP Public Key Pinning

C) CAA Records

D) Restricted Domain List - sites like Microsoft.com can only get certificates issued from certain CAs

There is an abundance of technologies to protect from this it’s a matter of customers like banks to implement these

To be honest having worked with several banks I am surprised it was that easy. I am sensing their PCI-DSS auditors and a few other people are going to get the hard word shortly

Andrei

1 Like

as a practical exercise review this post: Domain on Restricted List - LetsEncrypt Not Able to Issue Certificate

also review Certificate Transparency in action here: https://crt.sh/?q=%.mastercard.ro

The reason why this is a good exercise is that it shows someone trying to do something they shouldn’t be able to do.

CA Domain Restrictions coming to play and ultimately them going to Entrust (the CA who is allowed to issue those certs) and getting a certificate under the right process

Andrei

Thank you very much for your reply. It’s not immediately clear though, whether a combination of these techologies completely cover the case of the a stolen DNS record. Roughly speaking, I’m trying to understand if the same thing could happen to the online bank or site that I use.

A) I see a record for my online bank on CRT, but it’s not clear whether existance of such record would automatically block an issuance of a DV certificate by Let’s Encrypt. If it does – then yes, that is exactly what I’m asking for in this topic, but it’s not clear why it didn’t help the brazilian bank. If EV record from different CA in CRT doesn’t automatically block an issuance a new certificate by Let’s Encrypt, then it looks like something worth implementing.
B) I’m aware of key pinning, unfortonately it doesn’t seem to be widely adopted yet. E.g. in my case I don’t see the Public-Key-Pins header in response of my online bank. By the way, if anyone knows the way to view the list of pinned HPKP keys in Firefox or Chrome, please share it.
C) If someone gains control of the DNS record, then he’s likely able to override the CAA. And again, in my case I don’t see the CAA when running dig type257 against the domain of my online bank.
D) While this list is extremely helpful it will never cover 100% of cases.

Long story short, I do realize that they’re many initiatives and techonologies aimed at improving the security of PKI. My question is: does LE block the issuance of a certificate if it sees a EV certificate by a different CA in the Certificate Transparency index?

Long story short, I do realize that they’re many initiatives and techonologies aimed at improving the security of PKI. My question is: does LE block the issuance of a certificate if it sees a EV certificate by a different CA in the Certificate Transparency index?

Absolutely not. There are many people swapping from other CAs to LetsEncrypt and there is no way to automatically check if that is the case. Just like swapping from one paid CA to another.

Think of Certificate Transparency as a tool YOU NEED TO USE not the CA.

Fighting Forgery is a combination of the CA and yourself. A CA like LetsEncrypt does not know whats going on in your organisation and unless specified on a specific list it will issue certificates as long as they pass challenges.

Long lived CAA records can help with DNS hijacking.

There are cases where CAs have ignored the rules

https://wiki.mozilla.org/CA:WoSign_Issues

So overall - use the tools you have to monitor your DNS and Certificate Transparency.

Andrei

a full review of the baseline requirements: https://cabforum.org/baseline-requirements-documents/#Baseline-Requirements

will give you an idea of what most CAs responsibilities are

People switch CAs, that's perfectly normal. I certainly don't propose to ban that.

But how often do people swap an Extended Validation Certificate certificate to a Domain-validated certificate from LE? My guess is "never" or "extremely rarely". If my estimation is correct, then it is reasonable to block such requests until people explain their reasoning on community.letsencrypt.org -- the way it works already with the Restricted Domain List.

Think of Certificate Transparency as a tool YOU NEED TO USE not the CA.".

Well I'm neither a bank nor a browser. So I'm unlikely to check the crt.sh every time I buy something online. I see that connection is encrypted, browser is happy, organization has a good reputation, I'm entering my credit card and ... whoops. Had anyone told me that yesterday this site had an EV certificate and now it shows a DV, I would be very worried and cautious.

So my impression is that at the moment there's a gap in security processes. There're different ways to close it. Browser could warn about EV->DV change, HPKP could be improved to pin certificate properties like EVness ... or CAs could take additional precautions before issuing DV after EV in the first place. I'm not saying this is something LE is obliged to do, no (so references to CA responsibilities are not really relevant here). I'm saying this is something that LE could do for the sake of "more secure and privacy-respecting Web" (c)

have to disagree again

I have worked with clients that have moved from extended validation to domain validation for costs or because their previous IT companies didn’t know the difference

ACME is designed to be automated and LetsEncrypt is limited to DV certificates. Having to check a certificates past and stopping issuance may potentially increase workload (human) on the LetsEncrypt team and circumvent the automated aspect of ACME.

In general all banks usually use Organizationally Valid Certificates so if you are seeing a DV then it should be a warning sign. You can then use CRT.sh to see if there is anything amiss.

Could this be a automated as a service yes but it will probably be best done at the browser level rather than CA level IMHO

Some interesting reading on the challenges involved.

https://www.globalsign.com/en-au/ssl-information-center/telling-dv-and-ov-certificates-apart/

Andrei

I think I get the idea:

  1. Migrations from EV to DV by LE are not that rare and should not be pessimized.
  2. A DV certificate guarantees nothing but the domain control. Rather than putting efforts into extending DV guarantees (which would kill the ability to get them instantly, automatically and freely) we need to put efforts into explaining what DV actually means: it protects connection between you and whoever owns the domain from MitM attacks. If you want more security, you need to look for OV or EV, or for DV with additional features like HPKP, long-lived CAA records, CT background checks etc.
    Did I summarize it correctly?

I can also add that:

  1. Things said above about DV is not what most people expect from the “lock sign in the address bar”. Browsers should probably do a better job to explaing the meaning of certificate level.
  2. I think there should be a protocol that pins a certificate level (e.g. OV or >=OV) for a certain site. This could be a part of HSTS (e.g. site wants https always + a certain cert level) or HPKP (e.g. site pins the cert level, but not the key which scares admins a lot).
  3. CRT.sh (or alike) scans should be intergrated into browsers, you cannot expect an average use to manually run such checks. Perhaps I could try making a plugin to start with. Not sure about usage terms though, the service seems to disallow robot access.

If you’re using Firefox or a fork, Certificate Patrol is a nice extension for what you want. Basically, get an alert when a certificate has changed for a site you go to. It is limited to only sites that you have used before, however. It’s also very annoying as certificates are often very prone to change and between CDN networks and even multiple subdomains using different certificates and providers, it can get very noisy.

Tens of thousands of domains are probably in the process of switching to a new CA given Google's recent announcements regarding the trust and EV status of a certain market-leading CA. There's a good chance many of them won't bother getting another EV certificate, given the already dubious benefits. Manual verification for all these cases is not a viable approach.

I can agree with that. The long-term plan for both Chrome and Firefox is to treat HTTPS with DV the way HTTP is treated now, and mark HTTP the way invalid HTTPS is marked now. Special UI treatment would be reserved for EV (though that's occasionally a topic of discussion as well). Unfortunately all that is not practical before HTTPS adoption reaches a higher percentage, so hopefully we'll see more banks (and other high-profile sites) opt for pinning to EV intermediates (and CAs making this easier by making available a list of their EV-only intermediates and their key rotation policies).

Of course nothing that browsers and CAs can do will be of much use if banks can't even be bothered to even use HSTS (as was the case here), so this is certainly not an easy fix.

1 Like

Hi @salmin

I am also dubious about the reporters claims that the fake certificates issued were from LetsEncrypt

From the article

With that domain hijacking in place, anyone visiting the bank’s website URLs were redirected to lookalike sites. And those sites even had valid HTTPS certificates issued in the name of the bank, so that visitors’ browsers would show a green lock and the bank’s name, just as they would with the real sites. Kaspersky found that the certificates had been issued six months earlier by Let’s Encrypt, the non-profit certificate authority that’s made obtaining an HTTPS certificate easier in the hopes of increasing HTTPS adoption.

A) LetsEncrypt certificates are not OV (which is what you need for the name in the green bar)
B) LetsEncrypt certificates are only valid for 3 months so if their were issued 6 months earlier they would have raised date warning in browsers.
C) Unless Certificate Transparency records have been updated, reviewing the Certificate Transparency records for the top 10 brazilian banks (http://thebrazilbusiness.com/article/the-10-major-brazilian-banks) do not show any LetsEncrypt Certificates being issued

https://crt.sh/?q=%.bradesco.com.br
https://crt.sh/?q=%.caixa.gov.br
https://crt.sh/?q=%.hsbc.com.br
https://crt.sh/?q=%.safra.com.br
https://crt.sh/?q=%.itau.com.br
https://crt.sh/?q=%.banrisul.com.br
https://crt.sh/?q=%.panamericano.com.br
https://crt.sh/?q=%.santander.com.br
https://crt.sh/?q=%.bb.com.br
https://crt.sh/?q=%.citibank.com.br

Andrei

There are two Let’s Encrypt certificates issued roughly six months ago for one of those domain names.

2 Likes

I don’t agree with the OP. If your DNS server is compromised, you should really consider your domain completely compromised. Even if there was a manual check, a fraudster with full access to the domain (including for example, changing the WHOIS or transfer the domain) would ofcourse be able to subdue even the manual checks. (unless the people did have some knowledge about every bank in the world, which I doubt they have).
Remember, hacked server = owned server, so they could of course temporarly change the webpage or DDoS it, or make it unreachable, to not show off that its a bank, just to gain the certificate.

And to not take the problem that the fraudster might just steal the EV certificate’s private key off the server, if the server was hacked.

In this case, they managed to hack the account at the registry, which limited the access, but still, if the bank would use for example two factor authentication, then they wouldn’t be able to carry out the action.

However, the list of EV certificates could instead be used to detect similiar domains and prevent them from Lets-encrypt:ing. So if someone gains a EV certificate, they will get all their similiar domains “protected”, so for example, if thisisabank.com gets a EV, then for example th1s1sabank.com would be “protected”.
There are algoritms out there that can detect such similiarities.

You basically say that a hacker could hack everything and bypass any check. Well, let’s stop validating the domain control then and grant DVs left and right – all checks will be tricked anyways. And big CAs will hand out EVs to everyone, neither they have the “knowledge about every bank in the world”, it’s not fair to expect them to actually validate anything.

Every hack has a cost. Every security measure adds up to the total cost of the intrusion and, once the estimated cost exceeds the expected profit, people start looking for other places to mess with. That’s how security have been working for hundreds of years.

Now, with the particular case of DV certificates I agree that adding more validation (which I initially proposed) is a wrong way to follow. Not because it’s impossible – it’s not. But simply because it will ruin the concept of DV certificates. In that case we’ll end up inventing a new, lower level of certificate that only guarantees the domain control and nothing else (and how to call that if not “DV”).

What’s worth doing is ensuring that all sensitive information (like cc numbers) is protected with higher levels of security than just the domain validation. This is more about browsers though rather than CAs.

You are missing HTTP Public Key Pinning which could have assisted here

HPKP Headers are issued at the server side and a compromised DNS would not have allowed MITM or users to be sent elsewhere to trust a certificate that was badly issued. This assumes the servers were not compromised first to get access to DNS records.

If properly implemented a long lived HPKP will remain in the browser. The Browser will then know that the certificate that is served (even if it is cryptographically valid) has not been issued by the bank.

Vigilance by the bank in terms of looking at DNS records and resolving them on a frequent basis would have also helped as they could have detected their users were being sent to a non bank IP.

Andrei

1 Like

an interesting 101 post read for you: The CA's Role in Fighting Phishing and Malware

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.