Generally yes, but there is a slight mitigating factor that certificate transparency makes it very public who you are attacking.
In theory, if it was just your site ip that was attacked and not your dns provider, CAA record can protect you. Probably one of the few cases where dns-sec is actually useful. All that though is an edge case that probably doesn't apply 99% of the time.
Hijacking the IP would indeed allow you to respond to ACME HTTP-01 validations. That can be protected against by using RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (https://datatracker.ietf.org/doc/html/rfc8657). RFC 8657 extends the CAA record to say "Only this specific CA account may request certs for this domain" and/or "Only this specific validation method may be used when requesting certs for this domain".
Well, the new certificate shows up, but so what? CT logs aren't like "Barry Shitpeas got a certificate for hugecorp.example" they just tell you what was issued, not why, not who in any useful sense was issued it, and they take up to 24 hours to do that.
What is the overlap between the set of people who think "pass1234" is a good password and the set of people who have great oversight of their cert issuance and would flag unexpected issuances ? I'd expect it to be approximately empty.
… they just tell you what was issued, not why, not who in any useful sense was issued it …
They give you the certificate, which contains the issuer's CPS. If it's an issuer that you (the domain owner) don't recognize, you have at least a starting point for reaching out.
… and they take up to 24 hours to do that.
Indeed, the Maximum Merge Delay is 24 hours. But in practice, by monitoring multiple CT logs, it takes just a minute from successful issuance to having the certificate show up in at least one CT log (see https://utcc.utoronto.ca/~cks/space/blog/web/WebProbeSpeedNe...).
Comments
Encryption on higher level protocols (https) can do a lot to reduce potential impact.
Big impacts that come to mind (depending on what is being hijacked):
- dos attack
- pasive eavesdropping (not of encrypted contents, but who is connecting to who)
- hijacking plain http
- hijacking things like ssh where nobody pays attention to the mitm warnings
- potentially creating a new tls certificate to further do a later attack
Hijack the ip or dns entry and you break https as it’s trivial to get a new certificate and prove ownership of the DNS address adult the time.
Generally yes, but there is a slight mitigating factor that certificate transparency makes it very public who you are attacking.
In theory, if it was just your site ip that was attacked and not your dns provider, CAA record can protect you. Probably one of the few cases where dns-sec is actually useful. All that though is an edge case that probably doesn't apply 99% of the time.
The same could be said for many necessary security measures.
Hijacking the IP would indeed allow you to respond to ACME HTTP-01 validations. That can be protected against by using RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (https://datatracker.ietf.org/doc/html/rfc8657). RFC 8657 extends the CAA record to say "Only this specific CA account may request certs for this domain" and/or "Only this specific validation method may be used when requesting certs for this domain".
Let's Encrypt has supported RFC 8657 for over a year now: https://community.letsencrypt.org/t/enabling-acme-caa-accoun...
But then you show up on certificate transparency logs pretty quickly, no?
Well, the new certificate shows up, but so what? CT logs aren't like "Barry Shitpeas got a certificate for hugecorp.example" they just tell you what was issued, not why, not who in any useful sense was issued it, and they take up to 24 hours to do that.
What is the overlap between the set of people who think "pass1234" is a good password and the set of people who have great oversight of their cert issuance and would flag unexpected issuances ? I'd expect it to be approximately empty.
They give you the certificate, which contains the issuer's CPS. If it's an issuer that you (the domain owner) don't recognize, you have at least a starting point for reaching out.
Indeed, the Maximum Merge Delay is 24 hours. But in practice, by monitoring multiple CT logs, it takes just a minute from successful issuance to having the certificate show up in at least one CT log (see https://utcc.utoronto.ca/~cks/space/blog/web/WebProbeSpeedNe...).
I imagine letsencrypt is checking if any certs were issued from the hijacked IP-range during the outage, and is moving to revoke those certs?
Presumably the site owner would be the one monitoring CT. If they see there's a rogue certificate, they can take steps to get it revoked.