[james-revisoai]

It probably isn't too different from other access methods: 1) Get access to port 80 for > 60 seconds. Point it at your temporary VM. 2) Use any cert authority, and for verification, choose a file-specific location verification (you can choose amongst DNS records, an email to admin@domain, or a specific file location on your site with many of them) 3) On your VM, Quickly paste the file-specific location into a django GET route. 4) Run the Django site on port 80. 5) The cert authority verifies you, and emails your account the cert, the website author being none the wiser. You can now use it later to fool future visitors for a deeper attack or email-related attacks.

[Spivak]

This doesn't work unless the attacker happens to be in between your servers and the cert authority. The ISP that's in-between your laptop and the site can't pull this trick.

Also LE actually knows this attack is possible and mitigates it by validating the challenge from multiple sources so the attacker would need to be in the middle of all the LE validators and your servers.

https://portswigger.net/daily-swig/lets-encrypt-deploys-new-...

[james-revisoai]

Yes that's true, but I was just talking about the scenario of having access to port 80 of a server DNS pointed at by some domain.

You might have access through editing a proxy rewrite rule, for example.

In the attack above you use your own SSL provider for a cert (LE not involved) and you overwrite the cert in a sense that existed before. You choose a provider that just validates with a file location. It's an attack which already requires compromise.

[snowwrestler]

> The cert authority verifies you, and emails your account the cert, the website author being none the wiser.

It’s not hard to monitor cert transparency logs, which will show this new cert.