Is using a CDN possible when you're running a HTTPS website? - ssl

I have a website with only home page available through simple HTTP protocol.
All other pages are accessible only through HTTP over SSL(https://).
I'm using CDN for home page and very happy with it.
But for me it looks like using CDN for https pages is impossible because of security warnings, especially in IE. My files hosted at CDN are accessible though simple HTTP protocol.
What should I do? How this problem can be solved?

You need to get a CDN that supports serving files over HTTPS, then use that CDN for the SSL requests.

You can do this if their boxes have HTTPS support. What you can't do is use a subdomain of your own domain to cname against the cdn network. Because SSL doesn't work this way.
so https://cdn.tld/mydomain/path/to/file as a mechanism does work (because browsers will verify the cdn.tld ssl certificate correctly)
but https://cdn.mydomain.tld/path/to/file will not.

Two options, but in general I'd redirect all pages that don't need to be SSL'ed to their non-SSL equivalent and only use SSL when necessary.
Get a SSL certificate for your CDN host. It's just 30 bucks/year, but you need to take into account that this requires more configuration and depending on the traffic, this is also more expensive because the server requires more resources for SSL'd connections.
For the relevant pages, store the CSS/images/js files "local" on your own SSL host and use them when you need SSL. Of course you loose the speed etc. from the CDN, but that's a trade off. We opted for this because just our signup is SSL, 99.9999% of the time users spend on our website is on non-SSL links.

Related

Where would be the best place to host my simple Flask API?

I have a Flask API which has no database but just a json file that stores the data. At the moment I have put it on an EC2 and opened a port so someone can put in the IP address and port and have access to the API that way. The problem with this is that I get a mixed content error since the site it uses is HTTPS and the API is HTTP. I want to put the API behind HTTPS on a proper platform but I'm not sure where to start.
Is there a platform that I can host the API python file and the json file behind an HTTPS?
All of them? EC2 allows HTTPS (per #tawfikboujeh's comment). I don't actually know a hosting platform that would allow HTTP but not HTTPS.
There are some options in how you accomplish this:
Use a self-signed certificate. This will give you HTTPS but all the modern browsers will give a nasty warning to all your visitors.
Purchase a signed certification for you IP address from a CA. Just hope you don't have to change your IP address.
Purchase a domain and use Let's Encrypt to generate a signed certificate for you.
Option 3 would be the most robust solution, but it does carry the cost of a domain (maybe $10/year).
Google App Engine is perfect for this. SSL cert is free, and you would be in their free tier.
https://cloud.google.com/free

Subdomain working fine with http and not working with https

Recently I have installed ssl certificate on my website. After the ssl certificates have been installed ,I found that my subdomain is not working properly. I will address my subdomain as 'xxxx'and main domain as 'primary'. The main domain works well with http as well as https. Now the subdomain works well with http, but with https://xxxx.primary.com delivers me the main site content and not the content of subdomain. I'm using apache server, linux operating system.
Can anyone please help to solve this issue?
Thanks in advance.
This is how SSL protocol works with the browsers. Whenever browsers receive HTTPS request for domain name, it first checks with the server then delivers the site's content. If a website on server has enabled SSL accessed with HTTPS, browser will try to make secure connection and send request to the server.
In your case, your main website is working properly with HTTP as well as HTTPS and delivers proper content, but your sub-domain is not showing proper content for HTTPS. In order to deliver proper content you should consult with your development team. You can better host your sub-domain on another server or you can protect your sub-domain with valid separate SSL certificate.
Suggestion: If you own multiple sub-domains then it is advisable to use Wildcard SSL, that can protect unlimited number of sub-domains with single certificates. Please note, this unlimited does secure first level (blog.domain.com), doesn't second-third-fourth-etc. level (news.blog.domain.com, 1.news.blog.domain.com or abc.1.news.blog.domain.com).

Can https content ever be cached at CDN datacentres?

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.

Cloudfront in front of an IIS7.5 web server with SSL

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.

Is it wrong to configure a webserver to map both HTTP and HTTPS traffic to the same document root?

Is there anything wrong with configuring a webserver to map SSL traffic (port 443) to the same document root as normal traffic (port 80)?
Using the same document root for both http and https means you need to implement the following:
On each page that needs to be secure, there needs to be some application code that redirects the user to the https version if they somehow got to the http version (or to rediect the user to the login page if they have no session).
The login page always needs to redirect to the https version.
For pages that are accessible via both http and https, you need to set a canonical URL to ensure it doesn't appear like you have duplicate content.
Is there a better way to configure encryption of user account pages? Is there a best practice to separate website into HTTP and HTTPS sections?
It's not necessarily wrong to do this, but as your points 1..3 show, it introduces complications. It seems to me that setting up a separate document root might be a lot simpler than working around the complications.
In Internet Information Server 7.X you can define a "secure path" which is require to access with HTTPS and you can redirect the user to a user-friendly error page.
Maybe this can be a good solution to mix the document root and keep parts of the application secured.
Redirecting http automatically to https allows for man-in-the-middle attacks and is therefore not recommended. A man-in-the-middle could manipulate your HTTP traffic to send you to a malicious HTTPS site that resembles your HTTPS content.