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

111–120 of 522 posts

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

#111

Post by steveklabnik »

mikeryan wrote: post #104
Nick87633 wrote: post #9

Seems like the crypto crowd is moving on to creating flaky decentralized twitter clones now

Bluesky was started within Twitter as a federated social protocol in 2019. Spun out in 2021 as a standalone company and it was also being used in the Crypto group at Twitter until Elon came in. I'm sure just because of its age and principals involved it's been heavily influenced by the crypto crowd. But suddenly, without anything else really stepping in to fill the void, it's the Twitter alternative of the day. Anywa…

> I'm sure just because of its age and principals involved it's been heavily influenced by the crypto crowd.

It builds off of several specifications that came from the crypto crowd. It does not use a proof of stake or proof of work blockchain, though, so depending on how you use the words "crypto" and "blockchain," it either is or is not those things.

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

#113

Post by elijahbenizzy »

OK, this is a very cool method of verification for a social network but they goofed. Everyone goofs. In this thread folks being like "this is a bunch of jokers", yeah, I think they learned their lesson about rolling their own domain verification and everyone had some fun.

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

#114

Post by 88913527 »

mwint wrote: post #42
pyentropy wrote: post #26

Earlier quoted context omitted.

Further context: Bluesky lets you use a domain name you own as a user handle. The official method is to set a TXT record, but apparently their "AT protocol" also lets you confirm a domain by serving `GET your.domainname.com/xrpc/com.atproto.identity.resolveHandle` and `xrpc` was available as an S3 bucket name :)

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

N=1, but it appears users often create long and overly verbose bucket names.

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

#115

Post by bisby »

steveklabnik wrote: post #49
9dev wrote: post #44

Earlier quoted context omitted.

Dunno. That’s such a fundamental piece of thinking you just have to come across in the design phase, I don’t know how you would build a beta that didn’t avoid the issue in the first place unless you had a flawed take on security in the first place.

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"

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

#116

Post by throwawaaarrgh »

bob1029 wrote: post #47
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/ .

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, weeks to run a MITM on any domain you want. The attack only has to work once, on any of 130+ CAs.

The solution is registrar-level proof. Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true, it's sent to the CA who can see the registrar signed it. Now you know for a fact the domain owner asked for the cert. The only possible attack is to steal all three of the owner's private key, the registrar's private key, and a CA's private key.

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

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

#117

Post by unethical_ban »

reaperducer wrote: post #96
zippergz wrote: post #92

Earlier quoted context omitted.

I worked on a product that required DNS changes to set up. Especially for business accounts, the level of friction was STUNNING. We had it take months to get set up because the contact had to submit a ticket to IT, write up the business justification, get director level approval, get security approval, and so on before it could get done. We had customers who couldn't even figure out which group in their company manag…

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

[flagged]

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

#118

Post by xwdv »

ldoughty wrote: post #56
xwdv wrote: post #39

[flagged]

It's not that hard to modify code.. and I'd argue it's new enough that people should expect growing pains if they want to be early adopters... "Death" of a product for one bug? ....

This was a simple thing, the fact they got it so wrong only makes me wonder what other bad choices have been made.

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

#119

Post by steveklabnik »

justinsaccount wrote: post #95
steveklabnik wrote: post #16

Earlier quoted context omitted.

That is correct. 1. Bluesky allows you to use a domain as a handle by creating a TXT record on an _atproto subdomain of the domain you wish to use (see https://mxtoolbox.com/SuperTool.aspx?action=txt%3a_atproto.s... for mine) 2. You can also serve up your DID by having the URL " /xprc/com.atproto.identity.resolveHandle" rel="nofollow">https:// /xprc/com.atproto.identity.resolveHandle " return the DID. 3. AWS buckets…

Sounds like Bluesky screwed up by not implementing the https://publicsuffix.org/ list

The root cause here IMHO is more subtle than that, but I do agree that implementing that at some point is probably a good idea.

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

#120

Post by seba_dos1 »

steveklabnik wrote: post #62
seba_dos1 wrote: post #53

Earlier quoted context omitted.

In general - no, but this kind of fundamental mistake might.

I hope I never work on software you folks use. The grand claims about something that is not even hard to fix is just wild to me.

Being easy to fix is completely irrelevant. The thing is that it's easy to avoid. The only way to end up there is to not put any thought into the domain verification scheme before deploying it. Any kind of review would catch it. That's what makes it look really bad.
Post reply on HN