Solution is also on the works like use /.well-known/, so this is more like funny, rather than a big problem. Key to trick was to have bucket named "xrpc" and store a file there: https://s3.amazonaws.com/xrpc/com.atproto.identity.resolveHa... There is also another funny thing in the image, the user posting about is sending one from "retr0-id.translate.goog", which is odd. Somehow he has got https://retr0-id.translate.…
So this guy is now S3. All of S3
131–140 of 522 posts
Re: So this guy is now S3. All of S3
#132Re: So this guy is now S3. All of S3
#133Earlier quoted context omitted.
It is surely easy to cast stones at a single bug, but I don't think that's the right way to look at things.
"We'll build our own validation instead of using one of the existing standards that make perfect sense." is not just "a single bug". It's a flaw in architecture. A PR of "Change external domain validation to use .well-known (or DNS01, etc)" is not a "bugfix"
Re: So this guy is now S3. All of S3
#134Re: So this guy is now S3. All of S3
#135> 429 Too Many Requests Aight, level with me: Is every mastodon server running on a Raspberry Pi?
This is peak Web 5.0 right here.
Re: So this guy is now S3. All of S3
#136> 429 Too Many Requests Aight, level with me: Is every mastodon server running on a Raspberry Pi?
Re: So this guy is now S3. All of S3
#137This is a terrible implementation of domain verification. dns-01 and http-01 are more or less standardized at this point. Use them, and don't roll your own. Reference: https://letsencrypt.org/docs/challenge-types/ .
The issue with DNS-01 (and HTTP-01 to a lesser extent) as someone else mentioned is that the user friction is really high.
I’ve been working on a solution to this that I’ve been meaning to post to HN and this seems like as good an opportunity as any so here it is: [1]
It’s a method of storing a hashed (and optionally salted) verifiable identifier (think email or mobile) at a subdomain to prove authority for a domain.
Re: So this guy is now S3. All of S3
#138bluesky dev here. whoops. as others mentioned, not a hard fix.
Re: So this guy is now S3. All of S3
#139The ability to serve a file “www.example.com” in no way demonstrates ownership of “example.com”; it demonstrates that you control www.example.com.
If you want to prove ownership of a second level domain you must do it through a record in DNS, or through demonstrating control of something that is publicly known to control the domain such as the administrative contact emails.
This really is a solved problem in the PKI space; they should have borrowed that rather than invent their own.
Re: So this guy is now S3. All of S3
#140Earlier quoted context omitted.
I don't get http-based verification in general. If you want to really prove someone owns a domain, make them change an authoritative DNS record. Everything else feels like it is begging for edge cases to crop up. Why should my social media or SSL certificate vendor care about my web servers?
Both http and dns verification are stupid. Neither of them prove you own the domain. http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer. Both are trivially hacked, multiple ways. By the time someone finds out you did it ( if they closely monitor CT logs, which nobody does) you've already had hours, days,…
> Both are trivially hacked, multiple ways.
I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".