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

161–170 of 522 posts

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

#161

Post by ceejayoz »

benatkin wrote: post #122
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

.well-known seems unintuitive Also the penalty isn't very high here. Someone impersonated a domain on a burgeoning protocol for a short while. So what?

> .well-known seems unintuitive

We're talking about folks setting up a custom domain for a personal social media presence. If they can handle nameservers and DNS records, they can handle a folder with a dot in the name.

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

#162

Post by justin_oaks »

throwawaaarrgh wrote: post #116
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?

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

I can get behind registrar-level proof. And I can see why it won't happen, and it isn't because it's a bad idea.

One problem I see is the extra overhead for the registrars. Now they have one more thing to do: verify (sign) certificate requests. That extra work is probably enough to get registrars to push back against such a system.

The registrar would be assuming some of the functions of a CA. This would make it easier for a single entity be both registrar and CA. That would threaten the business model CAs and thus they'd push back against such a system.

If the CA were responsible for getting the registrar's verification for a certificate request then that'd add extra work for CAs, and thus the CAs would push back against it. If the domain owner was responsible for getting the registrar's verification for a certificate before submitting it to a CA, then the domain owners would be against it.

And this is all assuming that people could agree on a common set of protocols or data formats for this new system.

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

#163

Post by brazzy »

throwawaaarrgh wrote: post #116
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?

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

> I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.

Or maybe, just maybe, hear me out on this... maybe your proposal is not as smart as you think it is.

For one thing:

> Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true

What exactly does the registrar verify, and how?

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

#164

Post by mal-2 »

vultour wrote: post #159
mal-2 wrote: post #134

Earlier quoted context omitted.

[flagged]

All of these redirect to web.archive.org. Are they using it to offload traffic? That doesn't seem very nice.

No, all of these redirect to the original server when viewed by not-logged-in users. The original server has chosen to redirect to web.archive.

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

#165

Post by mal-2 »

shawabawa3 wrote: post #158
mal-2 wrote: post #134

Earlier quoted context omitted.

[flagged]

> It looks like these links auto-redirect when I access them from here, but when you access them from the homeserver they are served without redirect "Works on my machine" isn't going to cut it for running a popular social network Nobodies going to go around searching for mirrors, they'll just leave and go back to twitter

[flagged]

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

#166

Post by i_am_jl »

mtae wrote: post #133
bisby wrote: post #115

Earlier quoted context omitted.

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

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

I'm not going to speak for the commenter you're replying to, but I don't think anyone here is talking about the standards-compliant, DNS-based domain verification system. I think we're all talking about the non-standards-compliant, /xrpc/-path verification.

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

#167

Post by elliottinvent »

steveklabnik wrote: post #144
elliottinvent wrote: post #137

Earlier quoted context omitted.

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 :)

Thanks for taking a look and for your comment.

Another key difference is that the _atproto TXT record is discoverable since it’s always at _atproto. Whereas the “verifiable identifier” I use isn’t discoverable because it’s hashed and used as a dns label.

The ultimate goal here would be for these records to be populated by domain registrars upon a domain being registered (with registrant’s permission obviously).

This could create a kind of fast lane for domain verification across providers like Google Ads, Facebook, Office365 and everyone else that requests DNS verification.

The worst thing is that hundreds of providers request domain verification TXTs at the zone apex:

dig target.com TXT

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

#168

Post by steveklabnik »

ec109685 wrote: post #126
mwint wrote: post #42

Earlier quoted context omitted.

Stunning that there are (were) any 4-char bucket names left.

Path based bucket addressing isn't supported anymore, so this must be a legacy bucket: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...

The person who did it is in this thread, and apparently you are not correct. It was created yesterday: https://news.ycombinator.com/item?id=35821113

(I don't know anything about this personally, but since a lot of people are indicating an interest in this detail of the story, figured I'd try and surface that link better!)

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

#169

Post by bscphil »

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

> This is why mastodon , webfinger and ACME uss .well-known uri prefix

This is not how Mastodon does verification (at least not the main method). Mastodon doesn't just link users -> domain. It can link user -> webpage, for example to link social profiles between sites.

If you have a website with user generated content, and a user can set an arbitrary html attribute (rel="me") in a link pointing back to their profile, they can claim ownership of the page on Mastodon. Likewise, if they can set a link tag in the head element of the page for some reason.

Presumably this is somewhat harder to exploit than a (new, poorly thought out) dependency on a static file under /xrpc, but Mastodon does introduce more authentication footguns for sites than just .well-known! https://docs.joinmastodon.org/user/profile/#verification

Edit: authentication -> verification, since Mastodon distinguishes between the two (see below)

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

#170

Post by belltaco »

unethical_ban wrote: post #117
reaperducer wrote: post #96

Earlier quoted context omitted.

Especially for business accounts, the level of friction was STUNNING. Honestly, that's a feature, not a bug.

[flagged]

For representing and verifying identity, it should need director level approval.
Post reply on HN