5 ms·

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 could

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

mmastrac 7y ago
Isn't it technically valid to issue a cert with (star).domain.com, (star).(star).domain.com, (star).(star).(star).domain.com, etc...?
- judge2020 7y ago
  You can technically create them, but IIRC browsers don't trust them.
  - oasisbob 7y ago
    And creating/signing them is a violation of the CAB Forum Baseline requirements.
- koolba 7y ago
  No you can only have a single wildcard per domain listed in a cert.
  - deathanatos 7y ago
    And only as the leftmost component, that is, (star).example.com is valid, foo.(star).example.com is not.
philip1209 7y ago
They could probably even generate them in a lazy-loading style
- blattimwind 7y ago
  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).
RKearney 7y ago
> 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.
- regecks 7y ago
  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).
- mjevans 7y ago
  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.
- falsedan 7y ago
  > 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
- blattimwind 7y ago
  > 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.
judge2020 7y ago
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/docs/certificate-transparency.md https://chromium.googlesource.com/chromium/src/+/master/net/... ).
- clinta 7y ago
  There is progress being made on allowing redaction of subdomains in CT logs. https://tools.ietf.org/id/draft-strad-trans-redaction-01.html https://tools.ietf.org/id/draft-strad-trans-redaction-01.htm...
morpheuskafka 7y ago
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.

mmastrac 7y ago

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

judge2020 7y ago
You can technically create them, but IIRC browsers don't trust them.
- oasisbob 7y ago
  And creating/signing them is a violation of the CAB Forum Baseline requirements.
koolba 7y ago
No you can only have a single wildcard per domain listed in a cert.
- deathanatos 7y ago
  And only as the leftmost component, that is, (star).example.com is valid, foo.(star).example.com is not.

philip1209 7y ago

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

blattimwind 7y ago
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).

RKearney 7y ago

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

regecks 7y ago
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).
mjevans 7y ago
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.
falsedan 7y ago
> 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
blattimwind 7y ago
> 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.

judge2020 7y ago

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/docs/certificate-transparency.md https://chromium.googlesource.com/chromium/src/+/master/net/... ).

clinta 7y ago
There is progress being made on allowing redaction of subdomains in CT logs. https://tools.ietf.org/id/draft-strad-trans-redaction-01.html https://tools.ietf.org/id/draft-strad-trans-redaction-01.htm...

morpheuskafka 7y ago

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.