Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So this guy is now S3. All of S3

chaos.social

Post reply on HN
Print view View original

141–150 of 522 posts

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

#141

Post by bowmessage »

Nick87633 wrote: post #24
arianvanp wrote: post #8

This is why mastodon , webfinger and ACME uss .well-known uri prefix. .well-known is reserved and you can't e.g. make a bucket named .well-known It's funny the bluesky devs say they implemented "something like webfinger" but left out the only important part of webfinger that protects against these attacks in the first place. Weird oversight and something something don't come up with your own standards

What about serving the challenge file from the root or a near-root of the fully qualified url? Like www.domain.com/mastodon.txt or abc.freehost.com/mastodon.txt? Maybe I'm old but what are some popular use cases for webfinger? (I'm just learning about it now)

s3 supports my-bucket.s3-us-west-2.amazonaws.com style URLs as well

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

#142

Post by yokem55 »

CameronNemo wrote: post #77
bob1029 wrote: 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?

I think people don't want to put DNS admin credentials in places where they might get leaked. Would be cool if a DNS server or provider offered credentials that could only do ACME challenges and not change any other records.

acme-dns[1] is probably what you might want if you are up for running your own bit of infra. Implements a simple rest api for changing the txt records for acme verifications and nothing more. It works nicely as a delegated nameserver.

[1] https://github.com/joohoi/acme-dns

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

#144

Post by steveklabnik »

elliottinvent wrote: post #137
paxys wrote: 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…

> this really belongs in DNS.

And the primary way of identifying yourself is in fact DNS.

> I’ve been working on a solution to this

Your solution is almost identical to the BlueSky one: put a TXT record at _atproto. that resolves to a DID. The difference is that they mandate the DID spec and you do not. Which is totally fine! Just figured I'd let you know :)

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

#145

Post by [deleted] »

bombcar wrote: post #110
sergiotapia wrote: post #91

Mastadon has no chance if every time something becomes a little bit viral it's instance dies over the traffic.

Mastodon is a bunch of individual instances of varying power but maybe they should build in something that detects load and archived itself and redirects to the archive.

[deleted]

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

#146

Post by neogodless »

mal-2 wrote: post #134
olliecornelia wrote: post #70

Earlier quoted context omitted.

Aren’t federated services grand?

[flagged]

Found a similar situation, but I think the key is mostly if you're on one of those servers and seek out the content or if you're logged into one of those servers, it won't forward you (even if you click it from here, assuming same browser/container).

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

#148

Post by pornel »

Pirate-of-SV wrote: post #20

Any domain on the public suffix list should just be ignored I suppose. https://publicsuffix.org/list/

It'd be nice as an extra precaution, but please don't build things that rely on the Public Suffix List for security (this list by its nature is only a laggy incomplete approximation of the actual use of domains).

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

#149

Post by steveklabnik »

efitz wrote: post #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…

As said multiple times in this thread, the primary way of identifying yourself in this protocol is a TXT record in DNS.
Post reply on HN