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

11–20 of 146 posts

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

#11

Post by judge2020 »

regecks wrote: post #7
luhn wrote: 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.~

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

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

#12

Post by judge2020 »

mmastrac wrote: post #8
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.~

Isn't it technically valid to issue a cert with (star).domain.com, (star).(star).domain.com, (star).(star).(star).domain.com, etc...?

You can technically create them, but IIRC browsers don't trust them.

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

#13

Post by koolba »

mmastrac wrote: post #8
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.~

Isn't it technically valid to issue a cert with (star).domain.com, (star).(star).domain.com, (star).(star).(star).domain.com, etc...?

No you can only have a single wildcard per domain listed in a cert.

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

#14

Post by regecks »

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.

Yeah, good point. It makes me doubt that they will issue bucket-specific certificates at all. Perpetually exposing every single bucket name seems like a bad trade-off just to satisfy certificate verification.

Maybe there will be a name translation scheme for bucket names with periods (kinda like punycode for IDNs).

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

#15

Post by chipperyman573 »

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.

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

#16

Post by oasisbob »

judge2020 wrote: post #12
mmastrac wrote: post #8

Earlier quoted context omitted.

Isn't it technically valid to issue a cert with (star).domain.com, (star).(star).domain.com, (star).(star).(star).domain.com, etc...?

You can technically create them, but IIRC browsers don't trust them.

And creating/signing them is a violation of the CAB Forum Baseline requirements.

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

#17

Post by erikpukinskis »

chipperyman573 wrote: post #15

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.

What could Amazon do that would "help"?

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

#18

Post by chipperyman573 »

erikpukinskis wrote: post #17
chipperyman573 wrote: post #15

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.

What could Amazon do that would "help"?

Still let people use the old path system, even on new servers. This is an often-used trick to get around government censorship that will be destroyed with this change.

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

#19

Post by clinta »

chipperyman573 wrote: post #15

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.

And even if you use encrypted DNS, the domain is still in the clear via SNI. There's an RFC for encrypting SNI, but that's not here yet.

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

#20

Post by haney »

erikpukinskis wrote: post #17
chipperyman573 wrote: post #15

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.

What could Amazon do that would "help"?

I believe their point was that a central authority would have finer grained censorship control with the v2 bucket scheme instead of the old path based scheme.
Post reply on HN