[DexesTTP]

None of these are true for the MitM threat model that caused this whole investigation:

- If someone manages to MitM the communication between e.g. Digicert and the .com WHOIS server, then they can get a signed certificate from Digicert for the domain they want

- Whether you yourself used LE, Digicert or another provider doesn't have an impact, the attacker can still create such a certificate.

This is pretty worrying since as an end user you control none of these things.

[devvvvvvv]

Thank you for clarifying. That is indeed much more worrying.

If we were able to guarantee NO certificate authorities used WHOIS, this vector would be cut off right?

And is there not a way to, as a website visitor, tell who the certificate is from and reject/distrust ones from certain providers, e.g. Digicert? Edit: not sure if there's an extension for this, but seems to have been done before at browser level by Chrome: https://developers.google.com/search/blog/2018/04/distrust-o...

[tetha]

CAA records may help, depending on how the attacker uses the certificate. A CAA record allows you to instruct the browser that all certs for "*.tetha.example" should be signed by Lets Encrypt. Then - in theory - your browser could throw an alert if it encounters a DigiCert cert for "fun.tetha.example".

However, this depends strongly on how the attacker uses the cert. If they hijack your DNS to ensure "fun.tetha.example" goes to a record they control, they can also drop or modify the CAA record.

And sure, you could try to prevent that with long TTLs for the CAA record, but then the admin part of my head wonders: But what if you have to change cert providers really quickly? That could end up a mess.