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

201–210 of 522 posts

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

#201

Post by iudqnolq »

belltaco wrote: post #170
unethical_ban wrote: post #117

Earlier quoted context omitted.

[flagged]

For representing and verifying identity, it should need director level approval.

That's an overly technical way of looking at things. This issue is a whoopsie, not a catastrophic failure at AWS. It doesn't actually represent identity that much because anything critical has humans in the loop. The bank won't accept this as proof of identity. NYT won't accept this as proof of identity: if this bluesky account confessed AWS murders puppies NYT would call somebody they know at Amazon to check.

A company blog is a much bigger vulnerability when it comes to representing and verifying identity. Rather than let somebody fake identify to a computer system it allows faking identity to humans reading it. Yet I don't think most places require director signoff to post.

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

#203

Post by jesprenj »

JdeBP wrote: post #189

Things to learn about the FediVerse from the 429 error: * The FediVerse is lots of WWW sites. Some are WWW-hosting companies showing off, with all of the acoutrements of high-end WWW sites, including CloudFlare protection and lots of tweaking of the back end stuff. Others are one-person sites where someone has just set up the vanilla Mastodon/Pleroma/Pixelfed/Friendica/whatever software on a cheap hosted VM somewhere…

So server software is not written with high performance in mind?

I've read somewhere that federation is done via regular HTTP requests which ends up really hogging down servers if someone has a lot of followers.

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

#205

Post by neoromantique »

shawabawa3 wrote: post #154
weglasern wrote: post #81

Earlier quoted context omitted.

Not really: h https://leah.is/posts/scaling-the-mastodon/ They just got 6 times the normal requests: https://chaos.social/@ordnung/110312089838674624

unfortunately this is exactly why mastodon won't work I already don't trust mastodon links because 9 times out of 10 they simply don't work. Everyone's tiny hobby server falls over when one post gets big, and obviously not everyone is going to scale their servers to support the load of a viral post that might happen once every 6 months and will be 100x their base load

Mastodon is by design about small niche communities rather than centralised twitter alternative.

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

#206

Post by None4U »

chrishas35 wrote: post #69
tethys wrote: post #60

Earlier quoted context omitted.

From the instance admins: > We just started serving a http 429 error on the exact url of the post. So everything should go back to normal now.

If you go to the user's profile and then to the post, it seems to be okay. So perhaps also looking at Referrer.

Doing such a thing never requests to the page that is linked, so it makes sense that nothing is blocking it

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

#207

Post by LawTalkingGuy »

mikea1 wrote: post #140
throwawaaarrgh wrote: post #116

Earlier quoted context omitted.

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

It's not as much that it's trivial (but it seems like it always is because social engineering never stops working) but that once the attacker has authed they can generally delete whatever extra file or record they made and stay authed, potentially hiding the attack.

Whereas, if that required a signature from a private key, with a counter or other log of use in the TPM, it'd be caught by an audit without having to notice the symptoms.

I know that in security design that I've been involved with there's a lot more scrutiny given to each use of a privileged key than there is to making sure that all website logging lists each file in the directory at each request, or logging the full public state of your DNS every minute. Requiring a signed request makes the attacker come in through the front door.

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

#208

Post by bscphil »

madeofpalk wrote: post #190
bscphil wrote: post #169

Earlier quoted context omitted.

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

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

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.

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

#209

Post by benatkin »

ceejayoz wrote: post #161
benatkin wrote: post #122

Earlier quoted context omitted.

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

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.

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

#210

Post by afavour »

jesprenj wrote: post #203
JdeBP wrote: post #189

Things to learn about the FediVerse from the 429 error: * The FediVerse is lots of WWW sites. Some are WWW-hosting companies showing off, with all of the acoutrements of high-end WWW sites, including CloudFlare protection and lots of tweaking of the back end stuff. Others are one-person sites where someone has just set up the vanilla Mastodon/Pleroma/Pixelfed/Friendica/whatever software on a cheap hosted VM somewhere…

So server software is not written with high performance in mind? I've read somewhere that federation is done via regular HTTP requests which ends up really hogging down servers if someone has a lot of followers.

Mastodon is written in Ruby on Rails and there are some inherent performance issues with that, it generates a huge number of Sidekiq jobs that can bog down a server quite easily. There are other, non-Ruby implementations aiming for compatibility with the Mastodon API though, so I’m curious to see how it will all shake out.
Post reply on HN