The SSL/TLS protocol has more to offer than just providing you with transmission encryption. Its main benefit is that it provides a way for third parties to authenticate connections to your website over the Internet. A user who can connect to your site and retrieve information via SSL/TLS will have greater assurance and trust that information came from you. The point of Always-On SSL is that once a user is able to create an authenticated connection to your point of presence via https, then he or she should not be bounced back outside of that zone of protection. When content is communicated via HTTPS, it is because you expect to provide a level of security — and your users come to expect them as well. Once you welcome a visitor, it makes no sense to have them go back outside in order to knock. This is just one of several illustrations I’d like to present where heightened protection of a visitor should be maintained, and hopefully these examples will illustrate why Always-On SSL is the preferred method for providing web visit security.
Take the first-time visitor, who comes to your site and begins to browse. They might want to review your privacy policy or terms of use in order to know whether you will communicate with them securely and protect their privacy. First and foremost, users today want to know whether they can trust you with their information, and secondarily, will you protect them from others with malicious intent? As they navigate your site, they do not want to be redirected to insecure content, which will happen once you start pointing them to HTTP resources — basically you are breaking down the secure channel that you established in the first place with HTTPS.
So, my first point is that even if you do not implement Always-On SSL, you should at least begin by offering HTTPS everywhere on your site where a user may visit. Once the user has established https session from your homepage, don’t bounce them back and forth between http and https — certainly not during the sign-up process, and never for log-in pages. During what should be a secure enrollment process, you do not want the new user to click on a hyperlink for your “Terms of Service Agreement” only to read it from an insecure connection. Returning visitors may want to browse through some of your web pages before logging in, but that does not mean that SSL/TLS is only for https://login.yoursite.com — https is not just for when users want to click onto an internal account page. As general rules, use secure cookies and force https. If a user attempts to retrieve a page with “http:”, re-direct them back via https.
Know and control your server infrastructure. It is quite common for businesses to link into a variety of service providers with content for customer satisfaction surveys, shopping cart providers, human resources, corporate communications, and for vendors and suppliers. Large enterprises may have links to other internal departments or corporate affiliates. Always-On SSL requires that these cross-references be https as well. As was noted in the previous blog post on this topic, but which is well-worth repeating here — avoid mixed content by checking your site content for instances of http and scan your code to ensure that it doesn’t call any insecure content over HTTP or port 80. Graphics and images should be delivered over port 443 as well. Otherwise, browsers such as Firefox and Internet Explorer will block your site from rendering, or links will appear broken, “not found” 404 error messages will be found throughout your site, and other warnings, such as, “This connection is not fully secure because it contains unencrypted elements, such as images” will decrease visitor confidence.
Similarly, make sure that the certificate that you have installed covers all of the content from your servers. If content is spread across multiple servers, or even multiple domains, get a unified communication / multi-SAN certificate containing all of the fully qualified domain names (FQDNs) of those servers. For example, if you have a bundle of virtual servers (secure.login.net, content.mysite.com, and images.mysite.com) that a site visitor needs to communicate with, then your server certificate will need to contain all three of those FQDNs. Otherwise site visitors will receive an error message that a secure connection has failed.
Finally, if you are using a hosted solution work closely with your provider to ensure that they can deliver all of your web pages over SSL; configure your online spaces as “https” areas (e.g. in WordPress, under “General Settings” include “https” at the beginning of your Site Address URL); and make sure your hosting provider has the technical expertise to support Always-On SSL and is able to ensure that all of your websites have matching SSL certificates.
