It's true that HSTS could be a way for someone who can set up a seemingly valid but nonetheless fake HTTPS listener on a domain to prevent people from later communicating with a genuine HTTP service on that domain.
Three remedies for this, with different degrees of applicability to different sites:
* Put a CAA record for your domain into your DNS (see https://tools.ietf.org/html/rfc6844) to prevent legitimate certificate authorities from issuing the cert to the impostor. (This only provides protection if the attacker doesn't control your DNS zone.)
* Actually switch to HTTPS!
* If this attack happens to you and you don't want to switch to HTTPS, run a legitimate HTTPS listener on your domain that clears the HSTS status and then redirects users back to HTTP.
Comments
This DoS risk is documented in section 14.5 of the HSTS standard.
https://tools.ietf.org/html/rfc6797#section-14.5
It's true that HSTS could be a way for someone who can set up a seemingly valid but nonetheless fake HTTPS listener on a domain to prevent people from later communicating with a genuine HTTP service on that domain.
Three remedies for this, with different degrees of applicability to different sites:
* Put a CAA record for your domain into your DNS (see https://tools.ietf.org/html/rfc6844) to prevent legitimate certificate authorities from issuing the cert to the impostor. (This only provides protection if the attacker doesn't control your DNS zone.)
* Actually switch to HTTPS!
* If this attack happens to you and you don't want to switch to HTTPS, run a legitimate HTTPS listener on your domain that clears the HSTS status and then redirects users back to HTTP.