3 ms·

>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

>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.

thisismissem 1y ago
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 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/internal/handle-resolver https://github.com/bluesky-social/atproto/tree/main/packages...
magicalhippo 1y ago
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 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.
- bnewbold 1y ago
  (I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667 https://news.ycombinator.com/item?id=45469667)
- thisismissem 1y ago
  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/ 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.

thisismissem 1y ago

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 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/internal/handle-resolver https://github.com/bluesky-social/atproto/tree/main/packages...

magicalhippo 1y ago

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 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.

bnewbold 1y ago
(I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667 https://news.ycombinator.com/item?id=45469667)
thisismissem 1y ago
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/ 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.