Hacker News new | past | comments | ask | show | jobs | submit login

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)


Neither of these are 'authentication'

You're thinking of how Mastodon does verified links. You could do something similar, provide a verified link on your profile to a file in an S3 bucket, but there's very utility (or risk) in that.

Mastodon also allows you to be discoverable via a custom domain, using .well-known as parent mentioned https://docs.joinmastodon.org/spec/webfinger/ https://www.hanselman.com/blog/use-your-own-user-domain-for-...


I'm thinking, mainly, of how these features are exposed in the UI and how users experience it. What matters is that users take (rightly or wrongly) a verified profile link to mean "I control this webpage". So e.g. if you could verify a Twitter handle on Mastodon, it would mean "if you trust the identity of this Twitter handle, you should also trust the validity of this Mastodon user". That's extremely important to get right no matter what you call it.

I'm not sure what Bluesky was attempting to do here but what they achieved in practice was allowing a user to claim control of a domain by claiming control of a page. But if you allow user generated content on the home page of your site, there's not a distinction (from a Mastodon user point of view) between the two. It's effectively the same problem if I can "verify" yourdomain.com on Mastodon - and my point is that you can do that without using .well-known.


> But if you allow user generated content on the home page of your site, there's not a distinction (from a Mastodon user point of view) between the two.

If you allow UGC with *arbitrary HTML* or explicitly support generating rel=me. Both are you explicitly giving someone control of the site (or at least letting them claim they have it).


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)


The /.well-known/ path prefix is the standard name to use (https://www.rfc-editor.org/rfc/rfc8615) so that any sort of “we’ll host user content from our domain” thing can block it. (Hosting user content from the user’s domain is fine and doesn’t need this restriction.)

A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if you’re running something vaguely like S3, you’ll want to make sure users can’t create files at the top level of your domain matching at least those names.

But nothing new should use anything other than /.well-known/ for domain-scoped stuff, or else you run into exactly this problem.


> A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if you’re running something vaguely like S3, you’ll want to make sure users can’t create files at the top level of your domain matching at least those names.

I also recall /crossdomain.xml as an important one; allowing users to create an arbitrary file matching that name could allow certain kinds of cross-site attacks against your site.


I think crossdomain.xml died with Flash but I could be wrong, does anyone know?


None of the standardized web technologies use crossdomain.xml, but I think Acrobat Reader still uses it for... stuff. And acrobat still has a browser plugin, so I guess it's still a potential vector for abuse.


ah! Reader. That's a fun one. I once encountered an "Acrobat Reader-only" PDF that after filling out and selecting any applicable attachments on your filesystem you then... literally put in your credentials to the website in the PDF so that it could.. submit itself. I lost some braincells seeing that..


Oh man, then you really don’t want to know about a product I once created.

Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run.

I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs.

Because reasons.

That product was live for years. I think we shut it down as recently as 2 years ago.

To be 100% clear, wasn’t my idea.

But it was my mistake to joke about the absurd possibility to build such a thing in front of some biz folks.


oh looooooooooooord. O_O


https://twitter.com/subtee/status/1654858616065732609?s=12

in an interesting coincidence, I found this today!


impressive, but still haha


But no browsers support 3rd-party plugins anymore. (I think the Chromium PDF viewer might be a plugin internally though?)


I learned something new today. I guess .well-known's purpose isn't well known!


The most important people to know about this stuff are the people for whom it's effectively part of how to do their job correctly. I know what it means if there's a flashing single amber light on a railway signal in my country, but it's not important that you know, and wouldn't be important if I'm wrong, however it's very important that the train driver knows what it means.

You'd hope that people doing job X would seek at least some insight into whether there are best practices for doing X, even if it's not a regulated job where you're required by law to have proper training. Not so much unfortunately.

Example: Many years ago now, early CA/B Forum rules allowed CAs to issue certificates for DNS names under TLDs which don't exist on the Internet. So e.g. back then you could buy a cert for some.random.nonsense and that was somehow OK, and people actually paid for that. It's worthless obviously, nobody owns these names, but until it was outlawed they found customers. But, even though the list of TLDs is obviously public information, some CAs actually didn't know which ones existed. As a result some companies were able to tell a real public CA, "Oh we use .int for our internal services, so just give us a certificate for like www.corp-name.int" and that worked. The CAs somehow didn't realise .int exists, it's for International Organisations, like ISO or the UN, and so they issued these garbage certificates.

[Today the rules require that publicly trusted CAs issue only for names which do exist on the public Internet, or which if they did exist would be yours, and only after seeing suitable Proof of Control over the name(s) on the certificate.]


That is basically the idea of .well-known

Webfinger is when you want to multiplex multiple identities on a single domain

E.g. https://example.com/.well-known/webfinger?resource=nick@exam...

Will serve the challenge proving your handle is @nick@example.com


.well-known is basically the same idea https://datatracker.ietf.org/doc/html/rfc5785


Or why not just serve it from www.domain.com/.well-known so we only have one thing to block. :p


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


In fact the path method is deprecated, but I don't know if support will ever be removed, because some (old) buckets have periods in their names, and therefore don't work with the subdomain format.


I use S3 for a simple app landing page and I use .well-known for deeplinks... Unless I'm misunderstanding your comment which I probably am.


Yes, but you don't have access to s3.amazonaws.com/.well-known, only to yourdomain.s3.amazonaws.com/.well-known.


Ah yep. The article is down so I didn't understand the context, ignore me!


Nostr too


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


but it disappears when you add the dot.


They can and probably should but what if they decide not to?

That's the problem with expecting people to agree with and follow standards.


If they decide not to, then they get all the capabilities, responsibilities, and level of participation that come with not following a standard that others are expecting.

You've effectively described what happens when people don't agree.


There's already a strong precedent for something like .well-known being disregarded — the ~/.config directory. It's the same idea, a special directory starting with a dot, and the objection seems to be similar, that it's awkward. In the case of the config directory it's that the storage for an app is spread between multiple directories like ~/.local/share and ~/.cache instead of one directory like ~/.vim

https://wiki.archlinux.org/title/XDG_Base_Directory

I support both well-known and XDG because I think the benefit outweighs that perhaps they could have been designed better. But I don't think that those who opt out of it could only be doing so out of ignorance.


~/.config is an interesting contrast. The difference is .well-known has different producers and consumers, webmasters and web clients, respectively. Whereas the thing that uses an application's config files is the same as the thing that created it.


With .well-known they're sometimes different components of the same tool, like with letsencrypt. That's a good observation though. I hadn't noticed that.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: