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

Amazon S3 Path Deprecation Plan – The Rest of the Story

aws.amazon.com

Post reply on HN
Print view View original

101–110 of 146 posts

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#101

Post by scoot »

gumby wrote: post #47
staticassertion wrote: post #25

Earlier quoted context omitted.

There's a book out there that points to my website. I wish they had just mirrored it. My website has been dead for a few months, and some O'Reilly book has a dead link.

I just now realised that if the web required two-way links there would be no way to put them into books! Some context: Back when the www was first released the most common criticism was the lack of back links. This is such a stupid and obvious deficiency that it really wasn't worth even looking into a system that was an obvious stillbirth. It wasn't just the "experts" saying this, but so many of them did because it w…

Your timeline’s all wrong. TCP/IP the Internet built on it were already well established by the time the web was born.

There was nothing particularly special about HTTP or HTML, or even the concept of the web. What made it a success was the availability of a server reference architecture, and, more importantly, a browser. It was easy to try it out, see the value, and get up and running with your own server if you had something to publish.

Discoverability was a problem in the early days. There were printed catalogs of wesites! Backlinks might have helped, but clearly were not a fundamental requirement for the web’s success.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#102

Post by nebulous1 »

masklinn wrote: post #98
cm2187 wrote: post #97

Earlier quoted context omitted.

But if it is an auto-redirect, can’t aws redirect to an alias of the bucket that replaces dots by another character?

How do you handle conflicts when an other bucket name legitimately uses whichever replacement character you picked? Historically bucket names are supersets of DNS names. In fact, early 2018 Amazon modified the bucket naming rules in one of the older regions as the names that region allowed were completely inaccessible in vhost style (not just cert mismatch, the names were literally not expressible): > The legacy rule…

You don't allow them register whatever replacement character you pick?

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#103

Post by faithteams »

Faith Teams is easy-to-use and affordable church management & database software with online giving, child check in, volunteer management, events, mailings, email campaigns, mobile blast & more. 14 days free trial. No credit card required. Sign up now!! https://faithteams.com/

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#104

Post by faithteams »

Faith Teams is easy-to-use and affordable church management & database software with online giving, child check in, volunteer management, events, mailings, email campaigns, mobile blast & more. 14 days free trial. No credit card required. Sign up now at: https://faithteams.com/

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#106

Post by lugg »

cthalupa wrote: post #85
lugg wrote: post #72

Earlier quoted context omitted.

ssl prevents that.

It explicitly does not. It means there are additional barriers to doing it - people would need to accept a bad cert (we already know the overwhelming majority will), or they would need to slip in their own CA that allows them to generate their own valid certs for MITM, but that is eminently doable for the Chinese government inside of China. They can then block all traffic for people that do not use the cert that allo…

That's not what explicitly means. Ssl explicitly does prevent mitm attacks from intercepting URLs of requests.

The fact you can get around it by ignoring the cert is a bit irrelevant. It's like saying locks don't work because people can break your window.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#108

Post by nik736 »

"In this example, jbarr-public and jeffbarr-public are bucket names; /images/ritchie_and_thompson_pdp11.jpeg and /jeffbarr-public/classic_amazon_door_desk.png are object keys."

I think this should be:

"In this example, jbarr-public and jeffbarr-public are bucket names; /images/ritchie_and_thompson_pdp11.jpeg and /classic_amazon_door_desk.png are object keys."

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#109

Post by blattimwind »

RKearney wrote: post #10
regecks wrote: post #7

Earlier quoted context omitted.

They're already a CA, could they reasonably just issue a certificate for every bucket? I have no idea how many buckets there are in total. ~They probably couldn't take the Cloudflare approach of jamming 100 customer domains onto each certificate, since that would leak bucket names too easily.~

> They probably couldn't take the Cloudflare approach of jamming 100 customer domains onto each certificate, since that would leak bucket names too easily. Issuing one certificate at a time wouldn't make a difference since they're all submitted to public CT logs. Bucket names shouldn't contain sensitive information and security through obscurity is a bad idea.

> security through obscurity is a bad idea

Obscurity is a good and sensible layer for defense in depth. Systems A and A' were the only difference for A' is added obscurity will result in A' being more difficult to attack.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#110

Post by blattimwind »

philip1209 wrote: post #9
regecks wrote: post #7

Earlier quoted context omitted.

They're already a CA, could they reasonably just issue a certificate for every bucket? I have no idea how many buckets there are in total. ~They probably couldn't take the Cloudflare approach of jamming 100 customer domains onto each certificate, since that would leak bucket names too easily.~

They could probably even generate them in a lazy-loading style

Given that the certificates don't really need unique keys this would actually be feasible, yes (since then generating the cert only requires a RSA signature).
Post reply on HN