I have a question regarding CloudFlare's new Flexible SSL. I am on a free account there, so I figured I'd ask the community here before submitting a support ticket (since they don't appear to have a forum).
How do I properly handle a forced SSL redirect? I want all traffic to my site to use SSL, but right now it's bypassed. CloudFlare is enabled, and manually going to https:// works perfectly, but what is the "proper" way for forcing SSL? Do I need to use my domain registrar to redirect all requests to https? Not a problem if that's the case, I know how to do that, but I don't know if that's the "proper" way.
You could actually use PageRules to force http:// to https://
You should also make sure you don't have any mixed content issues.
Note: We don't provide a forum because we don't want people sharing sensitive information (server IPs, etc.) in a public arena. Everything is handled via support for that reason.
Related
I have a website running on IIS that requires two SSL certificates, one for the main website domain, and one for the traffic coming through a CDN (the assets are served from a different domain name). Both use SSL.
I therefore used the Server Name Indication option when creating the HTTPS bindings in IIS.
The site works fine, I know that users on IE6/Windows XP may experience an issue, but we don't have any/many users visiting our site using that combination so that's not a problem. However, it is an ecommerce site that receives postbacks/callbacks from both PayPal and WorldPay. Here is where we are experiencing an issue. It would seem that neither PayPal or WorldPay's mechanism for posting back payment information understands SNI, therefore we don't get notified that a payment has been made.
I'm not sure what the options are. IIS is telling me to create a default SSL site, but I can't find any instructions online regarding what I should be creating, or what benefit it serves.
Am I going down the right path with this? Can anyone offer any advice on a) whether a default SSL site will fix this issue and b) how to create the default SSL site?
Thanks for your time in advance.
Kind regards,
Dotdev
You don't have to have all your sites configured to require SNI.
From what you're saying, your callbacks from PayPal and WorldPay are on your main site are they?
If this is the case, you can simply edit the binding on your main site so that it does not require SNI, and make sure it is set to "All unassigned" rather than a specific IP address (otherwise it will get in the way of the SNI site).
So I've moved a website to another server (from wordpress) and have transferred the domain. Previously, it had a ssl certificate in wordpress, but not now (not needed). So now, when I try to access it in a browser, it automatically redirects to https. I know how to remove it from the browser cache, but the problem is, all the users that had accessed the website before will have the same problem and they won't know how to solve it or won't be even interested in doing so. My client could be losing a lot of visitors because of that.
Is there any way to solve that without buying a ssl certificate? I only need to solve the browser cache problem, the website is all new and everything else works fine.
Thanks
No, you cannot.
The mechanism you refer to is known as Strict Transport Security, and is specifically designed to prevent what you are trying to do.
However, you do not have to buy a certificate, you can get them for free using Let's Encrypt.
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.
I'm interested in hearing what others do when, in a given application, some pages need to be secure and others don't. Take any solution off the table that requires a separate domain/subdomain. In this case, all calls, secure or insecure, will link to the same domain. I see a few options:
The ham-fisted, just secure it all approach.
A URI rewrite solution that ensure the pages that need to be secure are accessed via the https protocol and either ignores other pages or, alternatively, forces those to standard http
An application-centric approach where each link is responsible for knowing whether it's pointing and applying the correct protocol. In this solution, all links would have to be fully qualified.
A laissez-fair version of the application-centric approach where links to secure pages are fully qualified and links to other pages are not. In this case, the protocol would be inherited for pages not handled explicitly and inconsequential pages may be accessed via https.
I've used several of these from time to time, but they all have drawbacks. What's everyone else doing in these situations? Is there another path I haven't considered?
UPDATE:
vartec's answer below made me realize that I'd left out one critical piece of information. In my network config, all SSL-handling is taken care of at the load balancer level. The LB, then, communicates with the web server cluster via port 80. As a result, the applications themselves have no idea whether traffic arrived securely. All they see is a port 80 connection.
Thanks.
I use a mixture of #4 and #2: try to specify absolute URLs where possible when I need to switch protocols, and implement server-side redirection to catch any links I haven't used absolute URLs on (or if someone accesses the URL directly, not by following a link).
In my view, the one essential thing is that the pages which need to be accessed securely (form submissions etc.) are accessed securely, and for that I use Apache's SSLRequireSSL directive. It makes it easy to verify to myself that certain pages will never be accessed except over SSL.
I'm for the ham-fisted secure it all approach, but then you took my real solution off the table by (strangely to my mind) excluding domain/subdomain solutions. Errors in securing the site are far more dangerous than a bit of processing overhead.
We have our main site, which is insecure (but mainly marketing) and then we have the application site which is a different subdomain. Simple, easy and effective. Why take that option off the table?
Application centric approach, where controller for each page knows if it has to be secure. If it needs to be secure, but it's accessed via insecure http, redirect to https, passing along all of parameters.
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.