Hacker News Reader

Comment by regecks | Hacker News Reader

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

View on HN

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

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

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.

> 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

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

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.

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

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

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.

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

Reply on news.ycombinator.com