I have a simple static site which I provide through Amazon's Cloudfront. There is nothing of importance on there so it does not need HTTPS, furthermore I don't want to go through the hassle and cost of setting up an SSL certificate for my site, and I'm happy if requests are sent through HTTPS are met with a service unavailable or whatever other error message would be considered appropriate. Instead, Cloudfront attempts to serve the HTTPS pages using its own certificate and so flags the site up in the browser as 'untrusted' due to the certificate/domain name mismatch.
Is there some way to disable HTTPS entirely in Cloudfront, or some other way of gracefully falling back to HTTP whilst still using Cloudfront?
I've had the same problem.
Amazon now offers SSL certificates free of charge with following restrictions:
You can only use them in CloudFront or ELB.
Browsers which don't have Server Name Indication support won't render your site correctly.
In my case, I just used it even though I never need it. It is much better than having "Untrusted Connection" on the browser.
I couldn't find any mechanism to graceful fail or to block HTTPS completely.
See : http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html#CNAMEsAndHTTPS
For those who are using AWS web console to setup their cloudfront, follow this path to change the "Viewer protocol policy":
AWS Web Console > Cloudfront > Cloudfront Distributions > [Select your distribution] > Behaviors tab > [Select your cache behavior] > Edit > Viewer Protocol Policy > Set "HTTP and HTTPS"
You can specify independently, for each CloudFront origin, if it should use HTTP and HTTPS or only HTTP using the Origin Protocol Policy setting.
Protocols
CloudFront forwards HTTP or HTTPS requests to the origin server based
on the following:
The protocol of the request that the end user sends to CloudFront,
either HTTP or HTTPS.
The value of the Origin Protocol Policy field in the CloudFront
console or, if you're using the CloudFront API, the
OriginProtocolPolicy element in the DistributionConfig complex type.
In the CloudFront console, the options are HTTP Only and Match Viewer.
If you specify HTTP Only, CloudFront forwards requests to the origin
server using only the HTTP protocol, regardless of the protocol in the
end-user request.
Source: AWS CloudFront documentation
Please notice that in case you wish to add an alternate domain name to a distribution:
It seems that since this release (Apr 8, 2019) when you add an alternate domain name to a distribution, you must also attach a SSL/TLS certificate to that distribution that covers the alternate domain name.
So in that case you can't disable HTTPS.
(*) Note: I personally don't see the mentioned option of HTTP Only for Origin Protocol Policy - although it is also mentioned here.
Related
I am hosting a static website on AWS S3 bucket.
I have setup a CloudFront distribution with this bucket as origin.
I have created 2 alternate domains in my distributions
my-domain.com
*.my-domain.com
my-domain is registered in route53
I have created a hosted zone in which I have created records for my-domain.com and *.my-domain.com to point to my CloudFront distribution.
In AWS Certificate manager I have created a certificate for my-domain.com and *.my-domain.com that I have added to the CloudFront distribution.
At this point, everything is working fine and I get the expected result when I browse 'https://my-doamin.com
Now what I want to achieve is that my website is only accessible through https. I want users trying to access with http to be blocked.
I have setup my distribution behaviour to 'https only' and it works fine to block direct http access to my distribution (http://my-distribution.com)
However it is not enough to block http access through the altername domain (http://my-domain.com)
Through AWS documentation https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html I have figured out I needed to activate SNI.
The steps in the documentation are :
To switch from a custom SSL/TLS certificate with dedicated IP addresses to SNI.
Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/v3/home.
Choose the ID of the distribution that you want to view or update.
Choose Distribution Settings.
On the General tab, choose Edit.
Change the setting of Custom SSL Client Support to Only Clients that Support Server Name Indication (SNI).
Choose Yes, Edit.
I believe I am following all these steps but in step 5 there is nowhere I can find where I can change the setting of Custom SSL Client Support and I am blocked.
Here is what I see instead:
I know that modern web browsers cache https content by default. But when you use, say, CloudFlare on your https webpage can it ever cache the css/jpg files for the client? I'm expecting the answer is no as its encrypted, but maybe the datacentre is intelligent and can establish its own connection as a client, cache, then serve as a proxy or something using its own certificates. Thanks
Cloudflare is a content delivery network and not a simple load balancer. Because it is expected that they reduce the load on the original server they will cache also https traffic. This means that they will be a man in the middle and provide their own certificate for the site. For more information see their SSL-FAQ.
I've just set up CloudFlare on my web app. The free version, since my app isn't generating any revenue right now.
Now all my traffic is routing through CloudFlare's servers, correct? And that connection is "secure" because it's under HTTPS -- Chrome even displays the green padlock.
But CloudFlare is still communicating with my server over HTTP (unsecure connection), are they not?
Doesn't that mean all my client's data is sent in the clear between CloudFlare and my server? And that makes it not really secure at all, despite what Chrome thinks?
No.
The "Flexible" option of the "Crypto / SSL (with SPDY)" setting is not secure. If you read the "Help" text it says:
There is an encrypted connection between your website visitors and CloudFlare, but not from CloudFlare to your server.
You must install an SSL certificate on your own server and then select the "Full SSL (strict)" option to be secure.
You can configure the origin for the CDN (i.e. your servers that provide the original version of the content to be distributed across the CDN) to provide data using HTTPS. With the pro version (which you are not currently using) you can also use the SPDY protocol. HTTPS communication between the CDN and your servers protects that part of the communication path.
Additionally, and optionally, you can use Authenticated Origin Pulls (also available in the free version) to ensure that the CDN and origin (you) are both who you claim to be.
I'm setting up HTTPS Load Balancing (LB) on Google Compute Engine (GCE). Key components are outlined in the Overview Diagram.
After successfully creating a HTTP Backend Service where 1 of 1 (GCE) instance is healthy, I decided to do the same for HTTPS. I'm using the Developer Console UI to do this.
The Healtheck "wizard" provides a drop-down menu for protocol with the option HTTP and HTTPS:
The successful HTTP Heathcheck used the path :8080/admin/healthcheck.
Presumably the HTTPS Healtheck will use the path :443/admin/healthcheck. The problem is my HTTPS Healthchecks are failing. This was expected since when visiting https://[INSTANCE_IP]:443/admin/healthcheck in a browser, it could not connect. So I didn't expect the Healthcheck to mark the instance as healthy.
How can I connect to https://[INSTANCE_IP]:443/admin/healthcheck over TLS, do I merely need to upload a certificate and create a Certificate Resource in the Developer Console (I doubt it)?
I think it's a conceptual problem too.
The URL https://[INSTANCE_IP]:443/admin/healthcheck does exist, I think because the instance doesn't implement TLS, the Healthcheck fails.
What is the relationship between a uploading a certificate (i.e. creating Certificate Resource) and a specific GCE instance accepting HTTPS requests such that HTTPS HealthCheck pass?
After re-reading the documentation, it is stated:
The client SSL session terminates at the load balancer. Sessions
between the load balancer and the instance can either be HTTPS
(recommended) or HTTP. If HTTPS, each instance must have a
certificate.
It is the last sentence that I was trying to achieve because HTTPS Healthchecks use a HTTPS URL to check the 'health' of an individual instance:
https://[INSTANCE_IP]:443/admin/healthcheck
Since this was failing, I incorrectly assumed I needed to implement TLS on each instance for the Healthcheck to succeed. However, I do not require each instance to implement TLS (HTTPS), only the Load Balancer.
The final configuration I used involved creating a new HTTPS Target Proxy, which pointed to the same Backend Service used for the HTTP Target Proxy. In other words: 2 Target Proxies (HTTP and HTTPS), but only one Backend Service).
Since Healthchecks are employed by Backend Services, the only Healthcheck required was the (original) unsecure Healthcheck, i.e.
http://[INSTANCE_IP]:8080/admin/healthcheck
The next sentence is important to:
The Beta release of HTTPS load balancing only supports a single SSL
certificate with a single load balancing service.
If the beta release only supports a single SSL certificate, I assume this certificate belongs to the LB, and therefore, on the beta at least, it's not actually possible to secure individual instances.
I have a CloudFront destro in front of my asp.net application, serving dynamic content. All cache periods are set and everything looks ok.
I am using cloudfront mainly to accelerate the site for international visitors.
I have a registration page on the site that uses SSL. I understand that I can't use my own SSL with cloudfront, but is there a way that I can tell cloudfront to point the user to the origin when they navigate to one of the HTTPS pages?
The urls on your secure page must use the https prefix or the browser will complain about mixed-mode content. This means that the requests have to start their lives as https ones. This makes redirection in the manner you suggest impossible.
Your best bet is to have logic in your pages that determines the host portion of your url and protocol so that if it's a secure connection, all your content urls are prefixed with the secure host/protocol in the form https://[cloudfront-secure-hostname]/[your content]
If the connection is not secure, you return your standard CDN hostname using http.
The only down side is that a user will see requests going off to a domain other than yours. This shouldn't be too much of a problem though.