Live data from Hacker News

Amazon S3 Path Deprecation Plan – The Rest of the Story

aws.amazon.com

21–30 of 146 posts

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

#22
post #7
post #6

> Bucket Names with Dots – It is important to note that bucket names with “.” characters are perfectly valid for website hosting and other use cases. However, there are some known issues with TLS and with SSL certificates. We are hard at work on a plan to support virtual-host requests to these buckets, and will share the details well ahead of September 30, 2020. I’m mystified how they’re planning on doing this. Anybo…

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

It would probably be easier to work with customers who can't migrate to make a wildcard for their use-case, e.g. for xyz.evilcorp bucket names, you could just make one *.evilcorp.s3.amazonaws.com cert.

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

#23

This is a great step forward. Particularly changing the rules a little so that old buckets won’t break after a certain date. Thank you for taking the time to write this up Jeff.

You are welcome. And now, back to my stay-cation.

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

#24
post #6

> Bucket Names with Dots – It is important to note that bucket names with “.” characters are perfectly valid for website hosting and other use cases. However, there are some known issues with TLS and with SSL certificates. We are hard at work on a plan to support virtual-host requests to these buckets, and will share the details well ahead of September 30, 2020. I’m mystified how they’re planning on doing this. Anybo…

I'm guessing that the vast majority of buckets with dots in their names are actual domain names that are CNAME'd to S3, not just random strings of characters that happen to contain dots.

In that case, you can create a CloudFront endpoint with your bucket as the origin, and point your domain name at the CloudFront endpoint instead. CloudFront can already handle TLS with arbitrary domain names, so I wouldn't be surprised if this becomes the official recommendation for buckets with dots in their names. You already need to do this anyway if you want to use TLS with your S3-hosted static website, because you're probably not accessing it at a ((sub)sub)subdomain of s3.amazonaws.com.

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

#25

Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!

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.

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

#26
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.~

A change like this would already end up exposing every bucket name - at least if you wanted them to actually work in browsers. CT logs are required for all browsers now (subject to https://chromium.googlesource.com/chromium/src/+/master/net/... ).

There is progress being made on allowing redaction of subdomains in CT logs.

https://tools.ietf.org/id/draft-strad-trans-redaction-01.htm...

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

#28

Still doesn't help with domain censorship. This was discussed in-depth in the other thread from yesterday, but TLDR, it's a lot harder to block https://s3.amazonaws.com/tiananmen-square-facts than https://tiananmen-square-facts.s3.amazonaws.com because DNS lookups are made before HTTPS kicks in.

It actually helps tremendously, since at the very least now there can be a "black market" for legacy (pre-Sept-2020) buckets, especially those on dedicated accounts that can be provided to organizations spreading facts like this.

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

#30
post #28

Still doesn't help with domain censorship. This was discussed in-depth in the other thread from yesterday, but TLDR, it's a lot harder to block https://s3.amazonaws.com/tiananmen-square-facts than https://tiananmen-square-facts.s3.amazonaws.com because DNS lookups are made before HTTPS kicks in.

It actually helps tremendously, since at the very least now there can be a "black market" for legacy (pre-Sept-2020) buckets, especially those on dedicated accounts that can be provided to organizations spreading facts like this.

I don't understand, why would restricting access to an anti-censorship service help fight censorship?
Post reply on HN