Live data from Hacker News

Amazon S3 Path Deprecation Plan – The Rest of the Story

aws.amazon.com

91–100 of 146 posts

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

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

> 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

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

#92
post #33

Earlier quoted context omitted.

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.

Why S3 must carry the burden of getting around censorship? If you are talking about China, yeah, Google used to carry that burden. Now GAE, GCloud, Youtube, Gmail are all gone. The whole IP range was blacklisted. Now what? Just because something accidentally works does not mean it will last forever.

China isn't the only repressive country in the world, there's plenty of people using domain fronting right now in other parts of the world.

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

#93

Earlier quoted context omitted.

Encrypted SNI seems to be tailor made for this situation. The public portion of the request SNI would just be s3.amazonaws.com but the ESNI extension has the full subdomain name. That (+encrypted dns) solves the privacy issue, while still enabling all the new features and improvements they have planned.

Does encrypted SNI solve the issues that AWS are trying to solve by removing path-style S3 requests? Namely, removing the complexity and single-point-of-failure of having one domain, and making it possible for subdomains to have varying allowed cipher settings? I don't know how encrypted SNI will work, but it surely it must choose the cipher before it sends the domain, so it ought to rule out one of the reasons for t…

According to https://tools.ietf.org/html/draft-ietf-tls-esni-03 ESNI parameters (e.g. public key) are queried via DNS. In the above case, the browser queries a TXT record for _esni.tiananmen-square-facts.s3.amazonaws.com, in addition to A and/or AAAA records for tiananmen-square-facts.s3.amazonaws.com. It then uses the public and other parameters to encrypt the SNI.

So it simply shifts the problem to DNS. To keep requests confidential from sniffers on your LAN or somewhere along the path, you're expected to use something like DoH.

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

#94

Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!

Stupid question but can’t amazon simply do a redirection?

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

#95
post #47

Earlier quoted context omitted.

There's a book out there that points to my website. I wish they had just mirrored it. My website has been dead for a few months, and some O'Reilly book has a dead link.

I just now realised that if the web required two-way links there would be no way to put them into books! Some context: Back when the www was first released the most common criticism was the lack of back links. This is such a stupid and obvious deficiency that it really wasn't worth even looking into a system that was an obvious stillbirth. It wasn't just the "experts" saying this, but so many of them did because it w…

Pfff, TCP/IP will never succeed. It doesn't have enough layers! /s

https://archive.org/details/elementsofnetwor00padl

"The Book": The Elements of Networking Style: And Other Essays & Animadversions of the Art of Intercomputer Networking, by M. A. Padlipsky (1985)

The World's Only Know Constructively Snotty Computer Science Book: historically, its polemics for TCP/IP and against the international standardsmongers' "OSI" helped the Internet happen; currently, its principles of technoaesthetic criticism are still eminently applicable to the States of most (probably all) technical Arts-all this and Cover Cartoons, too but it's not for those who can't deal with real sentences.

Standards: Threat or Menace, p. 193

A final preliminary: Because ISORM is more widely touted than TCP/IP, and hence the clearer present danger, it seems only fair that it should be the target of the nastier of the questions. This is in the spirit of our title, for in my humble but dogmatic opinion even a good proposed Standard is a prima facie threat to further advance in the state of the art, but a sufficiently flawed standard is a menace even to maintaining the art in its present state, so if the ISORM school is wrong and isn't exposed the consequences could be extremely unfortunate. At least, the threat / menace paradigm applies, I submit in all seriousness, to protocol standards; that is, I wouldn't think of being gratuitously snotty to the developers of physical standards -- I like to be able to use the same cap to reclose sodapop bottles and beer bottles (though I suspect somebody as it were screwed up when it came to those damn "twist off" caps) -- but I find it difficult to be civil to advocates of "final," "ultimate" standards when they're dealing with logical constructs rather than physical ones. After all, as I understand it, a fundamental property of the stored program computer is its ability to be reprogrammed. Yes, I understand that to do so costs money and yes, I've heard of ROM, and no I'm not saying that I insist on some idealistic notion of optimality, but definitely I don't think it makes much sense to keep trudging to an outhouse if I can get indoor plumbing . . . even if the moon in the door is exactly like the one in my neighbor's.

Appendix 3, The Self-Framed Slogans Suitable for Mounting

https://donhopkins.com/home/Layers.png

    IF YOU KNOW WHAT YOU'RE DOING,
    THREE LAYERS IS ENOUGH; 
    IF YOU DON'T,
    EVEN SEVENTEEN LEVELS WON'T HELP
https://en.wikipedia.org/wiki/Michael_A._Padlipsky

On the occasion of The Book's reissuance, Peter Salus wrote a review in Cisco's Internet Protocol Journal which included the following observations:

Padlipsky brought together several strands that managed to result in the perfect chord for me over 15 years ago. I reread this slim volume (made up of a Foreword, 11 chapters (each a separate arrow from Padlipsky's quiver) and three appendixes (made up of half a dozen darts of various lengths and a sheaf of cartoons and slogans) several months ago, and have concluded that it is as acerbic and as important now as it was 15 years ago. [Emphasis added] The instruments Padlipsky employs are a sharp wit (and a deep admiration for François Marie Arouet), a sincere detestation for the ISO Reference Model, a deep knowledge of the Advanced Research Projects Agency Network (ARPANET)/Internet, and wide reading in classic science fiction.

In a lighter vein, The Book has been called "... beyond doubt the funniest technical book ever written."

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

#96
post #94

Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!

Stupid question but can’t amazon simply do a redirection?

It'd break working paths, because bucket names can contain dots which work fine in "old style" paths but breaks using vhost style (a cert can only have a single wildcard, and the wildcard does not match dots, so ".s3.amazonraws.com" will not match "foo.bar.s3.amazonraws.com", and it's not possible to create a ".*.s3.amazonraws.com" cert).

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

#97
post #94

Earlier quoted context omitted.

Stupid question but can’t amazon simply do a redirection?

It'd break working paths, because bucket names can contain dots which work fine in "old style" paths but breaks using vhost style (a cert can only have a single wildcard, and the wildcard does not match dots, so " .s3.amazonraws.com" will not match "foo.bar.s3.amazonraws.com", and it's not possible to create a " .*.s3.amazonraws.com" cert).

But if it is an auto-redirect, can’t aws redirect to an alias of the bucket that replaces dots by another character?

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

#98
post #97

Earlier quoted context omitted.

It'd break working paths, because bucket names can contain dots which work fine in "old style" paths but breaks using vhost style (a cert can only have a single wildcard, and the wildcard does not match dots, so " .s3.amazonraws.com" will not match "foo.bar.s3.amazonraws.com", and it's not possible to create a " .*.s3.amazonraws.com" cert).

But if it is an auto-redirect, can’t aws redirect to an alias of the bucket that replaces dots by another character?

How do you handle conflicts when an other bucket name legitimately uses whichever replacement character you picked? Historically bucket names are supersets of DNS names. In fact, early 2018 Amazon modified the bucket naming rules in one of the older regions as the names that region allowed were completely inaccessible in vhost style (not just cert mismatch, the names were literally not expressible):

> The legacy rules for bucket names in the US East (N. Virginia) Region allowed bucket names to be as long as 255 characters, and bucket names could contain any combination of uppercase letters, lowercase letters, numbers, periods (.), hyphens (-), and underscores (_).

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

#100
post #97

Earlier quoted context omitted.

But if it is an auto-redirect, can’t aws redirect to an alias of the bucket that replaces dots by another character?

How do you handle conflicts when an other bucket name legitimately uses whichever replacement character you picked? Historically bucket names are supersets of DNS names. In fact, early 2018 Amazon modified the bucket naming rules in one of the older regions as the names that region allowed were completely inaccessible in vhost style (not just cert mismatch, the names were literally not expressible): > The legacy rule…

Or use an md5 of the bucket name with a prefix and make bucket names with that prefix followed by a bunch of hex chars illegal bucket names. It doesn’t need to be pretty, it’s only an alias that will never be typed or viewed by a human.

[edit]: I assume that new bucket names that break subdomains have been made illegal now so they work with a finite and static list of names. I am sure they can come up with a substitution that doesn't create collisions and with a reserved prefix you can avoid future collisions.

Post reply on HN