Hacker News Reader

Hacker News

Comment by danabramov | Hacker News Reader

Parent Full thread

danabramov

>Yes but if I've already hijacked the DNS to point to my own DID, what's stopping me from saying I go by your handle?

The process of establishing "this handle points to this DID" consists of:

1. Resolving handle -> DID via HTTPS/DNS (part you're concerned about)

2. Downloading the DID Document from its host

3. Verifying that the DID Document contains the same handle

Hijacking the DNS does not help you with (2) and (3). The handle isn't considered associated with the DID until (2) and (3) are done.

View on HN

If you did hijack the DNS and say `TXT _atproto.<handle>` points to `did:web:mycontrol.example` then that's a plausible attack, I guess, against did:web, but not against did:plc. And it'd assume that software in between hasn't cached the previous mappings, which typically it has.

This is noted in the did:web spec, which isn't from Bluesky PBC / AT Protocol: https://w3c-ccg.github.io/did-method-web/#dns-considerations

I should note though, that for many implementations, that'd mean poisoning a large DNS provider like google, cloudflare or quad8, since those are the DNS servers typically queried from servers, instead of going directly to the authoritative server itself.

There's more technical details here: https://github.com/bluesky-social/atproto/tree/main/packages...

I'm going off your post here.

1. I hijack the DNS entry so "_atproto.ruuuuu.de" TXT record now returns "did=did:web:iam.evilhacker.de" to the the actor doing the at protocol resolution.

2. To get the DID, the actor doing the at protocol resolution downloads the DID from "https://iam.evilhacker.de/.well-known/did.json", which I have full control over.

3. In the DID document, I put "alsoKnownAs": ["at://ruuuuu.de"], along with my own public key.

Wouldn't this make the actor doing the resolution associate me with your handle?

Again, maybe I'm missing something here. It just seemed to me this would allow me to hijack your posts when they are federated.

(I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667)

That is a risk for did:web, just as loosing control of your domain is a risk; The did method that is most widely used on AT Protocol is did:plc, which is https://web.plc.directory/

There's also did:webvh which isn't yet supported by AT Protocol, but may provide some better security, but is likely still susceptible to DNS poisoning.

However, the resolution of handle to DID happens at many different layers in the stack, so you'd have to manage to attack all of them at once. Handle resolution isn't something that typically happens on the end-users' machine, but rather on a server running a PDS, Relay or AppView. Those environments tend to be much harder to carry out DNS poisoning attacks.

Reply on news.ycombinator.com