I created an S3 bucket and enabled "Redirect all requests to another host name" under "Static Website Hosting".
This works and when I visit http://www.XXXX.com.s3-website-us-east-1.amazonaws.com, I am redirected to my end destination.
If however, I try to access the same URL over HTTPS: https://www.XXXX.com.s3-website-us-east-1.amazonaws.com, the connection times out.
Is it possible to specify an SSL certificate to use so that the redirect can handle HTTPS traffic?
With S3 by itself, no, it isn't possible. The web site endpoints don't speak SSL at all, and the REST endpoints don't handle redirects or allow any cert other than the *.s3(-region).amazonaws.com cert.
However, you can do it with CloudFront and S3 combined, if your clients support SNI.
Create a CloudFront distribution, configured with your hostname and SSL certificate, but don't use an "S3 Origin." Use a "custom origin" and that origin is your S3 web site endpoint hostname, with all requests forwarded to the origin using http (even though it's https on the front end).
If you are not familiar with CloudFront, this probably sounds a little convoluted, but I use it for exactly this purpose (among others).
Requests hit CloudFront, which allows you to use your own SSL cert... and then CloudFront forwards the request to S3, which returns the redirect, which CloudFront will cache and return to the requester (as well as to future requesters hitting the same CloudFront edge location).
The cost for this extra layer is negligible and you should not see any meaningful change in performance (if anything, there's potential for a slight speed improvement).
Related
I have a ALB set up behind a cloudfront distro. I have a rule to redirect an HTTP request to URL A to URL B which is not on AWS infrastructure.
When I query the ALB directly for URL A, the load balancer properly redirects to URL B. When I query a cloudfront endpoint for URL A, I get a 403 error back. Per the troubleshoot 403s aws doc, it seems the issue is that I don't have an alternate CNAME configured for URL B. However, since it's not on my SAN certificate that's associated with my CloudFront distro, I can't add it to the list of alternate CNAMES. is there a workaround to allow requests to URL A to properly travel through my cloudfront distro and get redirected? It doesn't make sense to me that I can't do this for an HTTP request.
verified that the ALB can be queried directly and redirect works
tried to add an alternate cname for http domain
removed wacl on alb to make sure that wasn't blocking it
I have a REST API on a Hetzner server which uses Varnish. I am trying to set up Cloudfront to use as the CDN for it. After reading around, I currently have the following setup:
Hetzner / Varnish
A main API route api.mydomain.com.
Config in Varnish for cdn-api.mydomain.com to also act as a route to the same API.
In the DNS for the domain in Hetzner, for cdn-api.mydomain.com I have
added the name servers for Route 53.
Route 53
Hosted zone called cdn-api.mydomain.com.
An A record with name prod.cdn-api.mydomain.com which points to my Cloudfront distribution.
An A record with name cdn-api.mydomain.com which points to the IP address of the server.
Cloudfront Distribution
Has the alternate domain name prod.cdn-api.mydomain.com.
Has the origin domain of cdn-api.mydomain.com
Protocol for origin is HTTP only
What I think should happen
Make a request to prod.cdn-api.mydomain.com.
Route 53 forwards to the Cloudfront distribution.
CloudFront looks to origin cdn-api.mydomain.com.
Origin cdn-api.mydomain.com looks to IP address of Hetzner.
Hetzner receives request, Varnish allows the domain through, sends back data to Cloudfront.
What actually happens
If I make a request straight to cdn-api.mydomain.com from Postman, it works if I turn off SSL.
If I turn on SSL, I get the error SSL Error: Hostname/IP does not match certificate's altnames, saying that cdn-api.mydomain.com is not on the certificates of the server.
If I make a request to prod.cdn-api.mydomain.com, I get the error Error: Exceeded maxRedirects. Probably stuck in a redirect loop. Which may be due to the same certs error.
Cloudflare
As a comparison, we have Cloudflare set up as the CDN for a different domain on the same Hetzner server. It has:
A main API route api.myotherdomain.com
In Hetzner a CNAME for cdn-api.myotherdomain.com with value cdn-api.myotherdomain.com.cdn.cloudflare.net.
In Cloudflare, an A record for cdn-api.myotherdomain.com which points to the IP address of the server.
cdn-api.myotherdomain.com is set up in Varnish as an entry point, but is not on the list of certificates of the server.
This all works fine including with SSL enabled.
It would be good to understand what I'm doing wrong here.
I've added certificate with custom domain name map in AWS API gateway but it allows HTTP automatically, how can I block normal HTTP and only allows HTTPS?
All API Gateway APIs are fronted with a CloudFront distribution. Each of these CloudFront distributions (whether it's a Custom Domain like yours or the default *.execute-api distribution) is configured to redirect all HTTP requests to HTTPS. Although CloudFront has the option to strictly require HTTPS and return 403 on HTTP requests we currently don't expose this option for simplicity.
If you feel you have valid use case for requiring HTTPS without a redirect please open a support ticket and the team can evaluate your request.
I have a gadget[*] that connects to the user's WiFi network and responds to commands over a simple REST interface. The user uses a web app to control this gadget. The web app is currently served over http and the app's javascript does AJAX calls to the gadget's local IP address to control it. This scheme works well and I have no issues with it.
[*] By "gadget" I mean an actual, physical IoT device that the user buys and installs within their home, and configures to connect to their home WiFi network
Now, I want to serve this web app over https. I have no issue setting up https on the hosting side. The problem is, now the browser blocks access to the gadget (since the gadget's REST API is over http and not https).
The obvious solution is to have the gadget serve it's REST API over https. But how? It has a local IP address and no one will issue a certificate for it. (Even if they did, I'd have to buy a boatload of certificates for each possible local IP address.) I could round-trip via the cloud (by adding additional logic on my server side to accept commands from the web app and forward it to the gadget over another connection), but this will increase latencies.
Is there a way around this problem? One possibility that I have in mind is to:
Get a wildcard certificate (say, *.mydomain.com)
Run my own DNS that maps sub-domains to a local IP address following a pattern (For example, 192-168-1-123.mydomain.com would map to 192.168.1.123)
Use the wild-card certificate in all the gadgets
My web app could then make AJAX calls to https://192-168-1-123.mydomain.com instead of http://192.168.1.123 and latencies would remain unaffected aside from the initial DNS lookup
Would this work? It's an expensive experiment to try out (wildcard certificates cost ~$200) and running a DNS server seems like a lot of work. Plus I find myself under-qualified to think through the security implications.
Perhaps there's already a service out there that solves this problem?
While this is a pretty old question, it is still nothing that you find out-of-the-box solutions for today.
Just as #Jaffa-the-cake posted in a comment, you can lean on how Plex did it, which Filippo Valsorda explained in his blog:
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
This is very similar to what you proposed yourself. You don't even need a wildcard certificate, but you can generate certificates on-the-fly using Let's Encrypt. (You can still use wildcard certificates, if you want, which Let's Encrypt supports now, too.)
Just yesterday I did a manual proof-of-concept for that workflow, that can be automated with the following steps:
Write a Web Service that can create DNS entries for individual devices dynamically and generate matching certificates via Let's Encrypt - this is pretty easy using certbot and e.g. Google Cloud DNS. I guess Azure, AWS and others have similar offerings, too. When you use certbot's DNS plugins, you don't even need to have an actual web server running on port 80/443.
On you local device, contact that Web Service to generate a unique DNS entry (e.g. ..yourdns.com) and certificate for that domain
Use that certificate in your local HTTPS server
Browse to that domain instead of your local IP
Now you will have a HTTPS connection to your local server, using a local IP, but a publicly resolved DNS entry.
The downside is that this does not work offline from arbitrary clients. And you need to think of a good security concept to create trust between the client that requests a DNS and certificate, and your web service that will generate those.
BTW, do you mind sharing what kind of gadget it is that you are building?
If all you want is to access the device APIs through the web browser, A Simple solution would be to proxy all the requests to the device through your web server.this was even self signed certs for the devices wont be a problem. Only problem though is that the server would have to be on the same network as your devices.
If you are not on the same network, you can write a simple browser plugin (chrome) to send the api request to IoT device. but then the dependency on the app/plugin will be clumsy.
I have two components to my application, an API server (which is shared between several versions of the app), and static asset servers for the different distributions (mobile/desktop). I am using HAproxy to make the API server and the static asset servers behave as though they are on the same domain (to prevent CORS nastiness). My static asset servers are on CloudFront. Eventually, the HTML will reference the cloudfront URLs for the assets it depends on (to leverage global distribution). Temporarily for ease, I'm just having everything go through HAProxy. I'm having a hard time, however, getting HAProxy to send stuff properly to cloudfront.
My backend definition looks like this:
backend music_static
http-request set-header Host <hash>.cloudfront.net
option httpclose
server cloudfront <hash>.cloudfront.net
I figured that by setting the Host header value, I would be "spoofing" things correctly on their way to CloudFront. Obviously, visiting .cloudfront.net behaves exactly as I expect.
You probably moved over from this issue, but I see its not answered yet.
One solution to this issue is to enable SNI on CloudFront (this cost money, but worked for me - http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html). The above Host header doesnt help, as HTTP Host header is sent after TCP handshake, and to support SNI CloudFront requires host details in TCP handshake.