I can't figure out how to use Amazon AWS. I am trying to set up the simplest possible thing (https-protected access to a s3 bucket) and failing. Can anyone give me advice :( https://cohost.org/mcc/post/1453305-please-help-i-am-baby
Please help I am baby and do not understand Amazon S3

https://mastodon.social/@mcc/110278058804094562 [https://mastodon.social/@mcc/110278058804094562] Everything is so broken I can't even get the post embed explaining how broken things are to work. I have this site, dryad.technology. It's my "static content" site. It has always been HTTP-only, no TLS. For reasons, I have to fix that now. It has to go HTTPS. When I set this site up 7 years ago I decided I would finally use ~cloud technology~ (I self-host my other sites and was tired of it). The architecture is: * Content hosted in a secret S3 bucket * Cloudflare caches/proxies the S3 bucket and serves at the domain. I pay almost nothing because Cloudflare is free, and Amazon charges me only for the traffic between Amazon and Cloudflare, which comes out to sub-penny levels. But I can't figure out how to move this setup to HTTPS. I tripped over this 7 years ago and I'm tripping over it now. Can anyone help. Me. With this. Here is a list of things I tried that don't work. Imagine my secret S3 bucket is named BEEFCAFE. 1. Serve site from http://BEEFCAFE.s3-website-datacentername-1.amazonaws.com/ Cloudflare proxies, https-encodes, adds a Cloudflare-signed https certificate Why this doesn't work: This is fake https. It's HTTPS signed from Cloudflare to the user, but it passes unencrypted over the open Internet between Amazon and Cloudflare. This is lying. It is giving a false sense of security to my users. I won't do it. The domain above does not respond to requests on port 443. 2. Serve site from https://s3.amazonaws.com/BEEFCAFE/index.html Cloudflare designates site DNS as s3.amazonaws.com, and adds a rewrite rule that tacks on BEEFCAFE/ to all inner-website requests. Why this doesn't work: Although I can go to https://s3.amazonaws.com/BEEFCAFE/index.html in a web browser and see my site URL, they appear to be specifically denylisting Cloudflare. When accessing dryad.technology/BEEFCAFE/index.html after making the change I get: <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>R7QMB7JF9RKMTJ12</RequestId> <HostId> CCQMYXOnUVx1OTNPYl0W/GYL/xHLBm2kZyXq2aBls4YFiHSvNgUTRJfKD9J/znX05MkmYbngAc0= </HostId> </Error> … or similar nonsense, on every pageload. I cannot find any Amazon documentation explaining why requests from CloudFlare specifically would result in this AccessDenied request. However there is a stack overflow answer [https://stackoverflow.com/a/39769368/6582253] that purports to address this exact problem, for this exact scenario, by setting a JSON "bucket policy". Following this page's had literally no effect. It did not change the error when accessed through CloudFlare nor did it block me from accessing through non-cloudflare. That is weird enough I wonder if I did something wrong 3. Follow the instructions There is a CloudFlare support page [https://developers.cloudflare.com/support/third-party-software/others/configuring-an-amazon-web-services-static-site-to-use-cloudflare/] which purports to explain how to do exactly the thing I want to do [use CloudFlare to serve pages stored in an S3 bucket]. The page is a bit oblique. It explains you need to go into the bucket policy editor and then "use this sample to fill out the needed JSON code". The referent of "this sample" is not in any way indicated, it is as if a sentence is missing. However I think they mean the IP based bucket policy [https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-IP]. The CloudFlare support page then directs you to fill in the list of known CloudFlare IP ranges. This produces a JSON very similar to the one from the stackoverflow page listed above. I'm not sure whether this support page gives me what I want. For one thing, it has a step directing me to "redirect requests from this bucket’s URL to the subdomain bucket URL you created". This suggests I'm going through my BEEFCAFE.s3-website-datacentername-1.amazonaws.com domain from approach 1 above, which implies I'll founder on the same http/https problem as before. However they also make oblique reference to an "endpoint", and there is an "access points" menu in Amazon's interface I have not fully explored. So maybe this will solve one of my problems (it is theoretically possible someone could guess my bucket name and access it directly instead of going through dryad.technology, mostly harmless but still worth avoiding) and I can solve the https problem in a following step. Why this doesn't work: The Amazon examples page contains an interesting statement: "Warning: Before using this policy, replace the 192.0.2.0/24 IP address range in this example with an appropriate value for your use case. Otherwise, you will lose the ability to access your bucket." Editing the JSON, I think: Wait, does that mean I won't be able to read the bucket, or does it mean I won't be able to administrate it? Hopefully it's just reading the bucket! No, it was total. After applying the change, my S3 bucket was suddenly only accessible from CloudFlare IPs. Meaning the site still loaded (because it was loaded from a CloudFlare site) but all of the AWS administration pages for the bucket now showed big red error messages, and I assume I tried to edit it that wouldn't work either. Hilariously this meant I was also blocked from undoing the configuration change I had just made. (Fortunately Amazon foresaw someone might make this mistake, and if I logged in from my superuser account it unlocked the bucket policy JSON form only, allowing me to reverse the change. 4. CloudFront? Amazon's help pages do contain a page on how to serve S3 as HTTPS. What they recommend is using a different Amazon service called CloudFront [https://repost.aws/knowledge-center/cloudfront-https-requests-s3]. Not CloudFlare. CloudFront. So in this model S3 funnels to CloudFront which funnels to CloudFlare which funnels to the user. The problem here is that CloudFront is not a straightforward web endpoint but a full-featured CDN, which isn't exactly what I want. This would mean two layers of caching which would be odd and could even be glitchy; it also implies I'll be getting charged twice per page update, which could potentially increase my AWS costs from one-quarter of a cent per year to as high as one-half of a cent per year. Given that this very almost works— I can access AWS via http, and I can access it (at the s3 site) via https as long as I don't do so via CloudFlare— without CloudFront, I'd prefer not to jump into that particular pool of frigid water unless I'm assured by someone who has done this before that it really is the only way. A second problem is that it's not clear to me from these docs how CloudFront accesses S3. Is it http? Is it https? Is it… whatever Amazon-internal communication method "aws://" is, which I assume but have not specifically seen documented is confirmed secure? My "win condition" is that I have an S3 bucket, access to which is unrestricted with appropriate AWS credentials, and access to which is possible via public HTTPS but only when accessed by CloudFlare. Data should be encrypted (to ensure integrity) via some key or other at each link between the S3 bucket and the user's browser. I don't pay for CloudFlare and the S3 charges for updating pages and transmitting them to the CloudFlare cache comes out to a few pennies per decade, so I'm basically hosting high-availability static content for free. Can I make this work? Is there something I need to be reading? I am flailing.

andi on cohost
@mcc S3 isn't really intended for hosting websites?
@whitequark Does "Amazon Web Services" offer a product which is specifically appropriate for hosting static web pages, then?
@mcc @whitequark no that's s3 + cloudfront. you are supposed to be able to host websites from s3
@parataxis @whitequark Oddly, S3, despite not being marketed as a web host, does have a built in system for serving web pages, and this system acts like a web server. But this system does not support HTTPS. CloudFront on the other hand, which is marketed as a web frontend, does not act like a web host *at all* unless it is specifically fronting S3's web host (which I am somewhat trying to avoid as it would mean an unencrypted hop across Amazon's network).
@mcc @whitequark amazon can already read the data at rest though
@parataxis @whitequark I'm sorry, I don't know what you mean by this.
@mcc @whitequark the web pages, which are stored in S3 unencrypted, can be read by amazon without having to intercept them going over the network
@mcc @whitequark if you don't want to deal with amazon there's also https://www.nearlyfreespeech.net/
NearlyFreeSpeech.NET Web Hosting

NearlyFreeSpeech.NET web hosting provides powerful, low-cost hosting services for experienced webmasters with a do-it-yourself focus.

@parataxis @mcc @whitequark I highly recommend nearly free speech as a host for static serve stuff. I think they only charge me a couple of bucks a year or something like that. It's cheap and reliable.
@aeva @parataxis @whitequark AWS charged me literally two cents over seven years
@mcc @parataxis @whitequark strictly speaking AWS has never charged me anything
@parataxis @whitequark @eqe So first off I believe they are technically stored encrypted in S3, or at least there is a checkbox for that. However I am not worried about data being *read* (the files are on the public internet anyway) but rather changed in transit. I understand it's unlikely Amazon would have an intranet router compromise, but it seems at least *more* likely than compromising a cloud server, so if I *can* avoid that risk I'd like to? But I don't know if I can.
@mcc @parataxis @whitequark @eqe if AWS gets owned in that fashion you are fucked in many worse ways before someone gets to your site

@mcc @parataxis @whitequark

> (which I am somewhat trying to avoid as it would mean an unencrypted hop across Amazon's network).

I don't understand this claim. It may be true in some technical sense that there is more cleartext on some internal backplane in cloudfront-serving-s3 than in some other network service topology, but

- aws does not promise that the cloudfront origin-server-fetch is unencrypted, it most likely uses a s3 access layer which most likely runs over pooled tls connections
- any Mallory who has access to the backplane most likely also has access to the RAM on the cloudfront tls frontend, as well
- the internal network links may well also have link encryption; at least Google did add link encryption to all inter data center links circa Snowden, and that appears to be best practice today; again aws doesn't promise this afaik but it seems likely.

So if you're baked into the aws ecosystem, cloudfront fronting s3 doesn't seem to me to have much risk under a network adversary threat model.

@eqe @mcc @whitequark the attack scenario would be like a router misconfig that leaked internal traffic