4 ms·
> 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, t
by luhn 7y ago
> 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. Anybody care to speculate?
- regecks 7y agoThey'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 agoIsn't it technically valid to issue a cert with (star).domain.com, (star).(star).domain.com, (star).(star).(star).domain.com, etc...?
- judge2020 7y agoYou can technically create them, but IIRC browsers don't trust them.
- oasisbob 7y agoAnd creating/signing them is a violation of the CAB Forum Baseline requirements.
- koolba 7y agoNo you can only have a single wildcard per domain listed in a cert.
- deathanatos 7y agoAnd only as the leftmost component, that is, (star).example.com is valid, foo.(star).example.com is not.
- philip1209 7y agoThey could probably even generate them in a lazy-loading style
- blattimwind 7y agoGiven 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 agoYeah, 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 agoWith 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 agoA 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 agoThere 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 agoIt 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.
- kijin 7y agoI'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.
- ars 7y agoUse some kind of encoding? Maybe a type of Punycode?