Conversation

Unless I'm mis-reading the domain history, this domain was (and is) DNSSEC signed and that did not prevent the takeover. The attackers move is to hi-jack the HTTP endpoints instead of DNS servers, get the cert through HTTP upload verification, and then MiTM.

Quote Tweet

Michal Špaček

@spazef0rze

Feb 15

Replying to @danielcormier and @campuscodi

Good question. With BGP hijack in progress, seems the hackers were able to obtain a valid TLS cert for developers.kakao.com, see crt.sh/?q=developers. (now revoked).

Replying to

I don't know whether it was, but currently, if I'm looking at these results right, the domain doesn't seem to be signed: en.internet.nl/site/developer & hardenize.com/report/develop Also, not MitM but modified source on a different server using a fake cert where traffic was redirected to.

Replying to

You're seeing them right, and I'm seeing something different and now wonder if they are rolling out DNSSEC and I caught an experiment? It doesn't really change the dynamic ... hi-jack to HTTP works regardless :(

Replying to

and

CAA and datatracker.ietf.org/doc/html/rfc86 is integration of DNSSEC and WebPKI issuance. If they aren't using that, they aren't trying to secure WebPKI issuance with it. DANE is an alternative to WebPKI or a pinning method to use alongside it, which they weren't using. DNSSEC isn't DANE.

Replying to

and

CAA would not have helped: it doesn't specify validation methods

Replying to

and

datatracker.ietf.org/doc/html/rfc86 which was linked in the tweet that you're responding to. There's a standard for specifying validation methods (which can be limited to DNS) and making HTTP validation secure via pinning a key. Not every CA supports HTTP/SMTP validation in the first place.

Replying to

and

If you CAA down to one CA that doesn't support HTTP validation yes. Other fix would have been RPKI

Replying to

and

CAA doesn't really need to permit even one CAA most of the time, only when you're doing renewal. Ideally you have a CA which supports accounturi/validationmethods. I don't understand why Let's Encrypt still has those features in staging. Can have secure HTTP validation with it.

Replying to

Let's Encrypt has supported accounturi/validationmethods for something like 2 years on their staging server. It works fine from our testing and we deployed it already ourselves for both their staging/production infrastructure. It doesn't do anything for production yet though...

5:55 AM · Feb 17, 2022Twitter Web App

Replying to

Look at the CAA records for our infrastructure for an example: grapheneos.org time.grapheneos.org matrix.grapheneos.org attestation.app etc. Have tested that it properly works for their staging CA infrastructure. Very unfortunate it's limited to that...

Replying to

It pins your account which is authenticated via an ECDSA key and it doesn't matter that HTTP(S) validation is insecure. You can make an account with certbot, update CAA to pin new account and then get your certificate. Wish they'd finally ship this since it actually helps a lot.