On: Amazon S3 Path Deprecation Plan – The Rest of the ...

[regecks]

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

[judge2020 → regecks]

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

[clinta → judge2020]

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

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

[RKearney → regecks]

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

[blattimwind → RKearney]

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

[regecks → RKearney]

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

[falsedan → RKearney]

> security through obscurity is a bad idea

only if that's your only defense, which it was for a lot of old crypto schemes & why the crypto community consensus was to publish algorithms/assume the attacker had the implementation. that mindset isn't universally applicable

[mjevans → RKearney]

With an Internet that doesn't push back packet rejection to bad hosts, rather than victims that are being flooded; being able to individually address buckets sounds like an increased risk.

[mmastrac → regecks]

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

[koolba → mmastrac]

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

[deathanatos → koolba]

And only as the leftmost component, that is, (star).example.com is valid, foo.(star).example.com is not.

[judge2020 → mmastrac]

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

[oasisbob → judge2020]

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

[morpheuskafka → regecks]

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.

[philip1209 → regecks]

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

[blattimwind → philip1209]

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