SSL is the most common form of security for the web. You see it when a website complains about lacking the proper certificates. You see it with the lock icon in your browser status bar when you visit a secured site. You see it in the URL, with the HTTPS notifier. You even hear about it in the news, when a bug like Heartbleed rolls around.
Even with bugs like Heartbleed, SSL is still far more secure than a page over open HTTP. So why hasn’t the whole web switched to using or requiring SSL on every page? On a more personal scale, should you enable SSL on every page, or should you keep it limited to secure pages, such as account control panels and login pages?
SSL is essentially a secret handshake that lets your traffic into an exclusive club where it has near-complete privacy. It creates a shrouded meeting place between your computer and the web server hosting the pages you’re accessing. The exact process is something like this:
- • Your browser visits a website that uses SSL, such as a login page.
- • Your browser sends a request to the server, asking that it identifies itself. After all, before you give your information to someone, you want to know they’re someone you can trust.
- • The server sends your browser a copy of the SSL certificate it uses.
- • Your browser checks that certificate to see if it’s trustworthy, making sure it’s legitimate and that it hasn’t expired. If it checks out, it sends a reply to the server.
- • The server then sends an acknowledgement of trust and begins an encrypted session, as indicated by the lock icon, HTTPS URL, green taskbar or other signifier in use.
- • From this point forward, traffic between your browser and that webpage is encrypted.
Encrypting data uses a complex public and private key system that is nearly impossible to crack. No small-time hacker could crack basic SSL encryption to steal your information. Even the NSA, making use of the world’s strongest supercomputers, would take centuries at best to brute force the keys necessary to read your data.
SSL is used for two reasons. The first reason is to establish identity and security online. A website, such as your bank, uses SSL to tell you that it is who it says it is. This way it can easily point to the lock icon or HTTPS URL and tell you if it isn’t there, don’t put in your information. The second reason is the protection of that information itself. If a hacker intercepted your account information while it was encrypted, all they would receive is garbled gibberish.
So it’s a no-brainer to enable SSL for your account login page. Do you enable it for your whole site?
Con: Server overhead. Each request made of a server over SSL requires a bit more processing power and bandwidth than an unencrypted bit of traffic. On a small scale, this isn’t much. Google noticed very little overhead increase when Gmail switched entirely to SSL – on the order of a single percent. However, across the entire Internet, a 1-2 percent increase in server wear can be important. Note: This used to be much worse when computers were slower, but it is much less of a factor with modern computing. Chances are server infrastructure will easily outpace the increased load of an all-SSL Internet.
Con: Content distribution networks face challenges. With a CDN, your website may draw from a dozen different servers to load a single page. This creates a problem. When your browser visits www.website.com and asks for its SSL certificate, it expects a certificate for that URL. It may receive one back from the CDN, www.cdn.com. The disparity between expected and actual host name causes an error and the browser reads the connection as untrustworthy.
Con: Subdomains have a similar issue as CDNs. www.mail.website.com would need a different certificate than www.users.website.com. A single certificate, called a wildcard certificate, solves this problem, except it doesn’t work for the simple http://website.com. Multiple certificates are necessary.
Con: Similar again to the CDN issue is the issue of ad networks. A website would need to know that every asset served up by the ad network was certified with SSL. More importantly, the ad network itself wound need to make sure every third party ad it served was equally secure. The problem stretches as far back as there are links in the chain, and if any one of them fails to provide SSL, every one forward in the chain throws errors.
Con: If an entire site is using SSL, it must be secure, correct? Well, there are still a few ways – in an Internet not entirely using SSL – that your information can be hijacked before it’s encrypted. Using SSL throughout your entire site can create a false sense of security in your users.
Con: SSL can interfere with some tools used for measuring SEO performance. HTTPS also requires canonicalization and the proper 301 redirects. This can take some time to set up properly and doesn’t fix the fact that some tools simply won’t work.
Pro: For one thing, implementing SSL throughout your entire site is technically easier than limiting it to a single page or a selection of pages. This makes it less work for your technical staff to implement.
Pro: You don’t run into issues where your login page is unsecure but the submit button is secure. These issues can make users think their information isn’t encrypted, even though the actual submission and transmission of data is perfectly safe.
Pro: HTTPS really is more secure. Having SSL across your entire site limits the ability of phishers to pull off impersonation attacks on your site. Your users will be able to expect a certain level of safety when using your site.
As you can see, the cons somewhat outweigh the pros in this situation. However, many of the cons are issues that can be alleviated by more sites and content providers switching to total SSL use.
The common recommendation is to use SSL for the parts of your site that necessarily need security. Login pages, sensitive submission forms and other such traffic needs to be encrypted, so you need at least that basic level of SSL use.
Over time, as more of the Internet switches to SSL, you can expand your SSL usage to cover the rest of your site. You may run into issues with third party content providers, if those providers have not fully implemented SSL of their own. Once these issues have been solved, site-wide SSL will be the new standard.