Live data from Hacker News

So this guy is now S3. All of S3

chaos.social

131–140 of 522 posts

Re: So this guy is now S3. All of S3

#131
post #5

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

Wait - nobody had ever created a bucket named xrpc before, ever? I would have imagined that short s3 buckets were squatted similar to domain names. (Or maybe they were, and it's this person who did so!)

Re: So this guy is now S3. All of S3

#133
post #115

Earlier 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"

okay so clearly you don't know what you're talking about because they do use existing standards/DNS as the primary way to validate domain ownership. It's free to not say anything and read the comments first before going off about something!

Re: So this guy is now S3. All of S3

#137
post #15

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

They definitely should have used HTTP-01 if they’re doing verification on the web, but since this is about using a domain as identity this really belongs in DNS.

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.

1. https://www.domainverification.org

Re: So this guy is now S3. All of S3

#139
If you want to prove domain ownership, you have to do it at the domain level.

The 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

#140
post #47

Earlier 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,…

> ...dns verification proves you temporarily control name resolution relative to a viewer.

> Both are trivially hacked, multiple ways.

I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".

Post reply on HN