SSL is the Secure Socket Layer, a protocol of Internet communication that encrypts data leaving point A and decrypts it when it arrives at point B. The entire purpose of SSL certificates and HTTPS usage is to make data difficult or impossible to use if it’s intercepted. If, for example, there was a malicious server between point A and point B, that logged and saved all data passing through it, data encrypted by SSL would be impossible to use.
For this reason, SSL is by default required for virtually all financial transactions online. Consider a more physical scenario, one that isn’t really feasible but which illustrates the point. Say that you want to buy something from a store. You select your item and stand next to it in the aisles. You then write down the item name and product number on a piece of paper, put your credit card on top of that paper, and hand it to someone walking down the aisle. They bring it to the end of the aisle, where it is handed off to someone else, who brings it to the front of the store. At the front of the store, someone else takes it and brings it to the cashier. The cashier then rings up your transaction.
Would you shop at a store that used that process? Ignoring, of course, the inefficiency of the transaction compared to traditional shopping. I wouldn’t. Anyone, at any point, could simply look at your credit card and take your number, name, confirmation code, expiration date; everything necessary to use it for their own ends.
The Internet works like this analogy. You don’t send your data directly to the shop in question. Instead, your communication passes through several servers and hubs along the way. There’s one in your house, if you have a router; it passes data from several computers to one Internet connection. There’s another, similar router at the street level, servicing the data from your neighborhood. There will be another serving your area of town, and so on until you reach an Internet backbone. Then your data has to go through the chain on down, until it reaches the server hosting the website. You just don’t see any of this data passing because it happens incredibly quickly.
Now imagine the same scenario, except your credit card is sealed inside an opaque box that cannot be opened except by the cashier, who has a special key only they have, and that fits only that box and no other box. You can be assured, then, that passing your order and credit box along the chain is perfectly safe; no one except the cashier can read your credit card information.
That’s how SSL works, and if you can’t see the immediate benefits to security, I’m not sure what to tell you.
That being said, lets learn about the intricacies of having SSL certificate on an eCommerce site:
If you’ve been paying attention and analyzing the ridiculous scenario above, you’ll note two problems with the SSL black box scenario.
The first is the moment when you take your credit card out of your wallet or purse and put it into the black box. This is analogous to when you type in your credit card information on your computer. There’s nothing preventing someone from watching over your shoulder, or knocking you down and taking it, as keyloggers and viruses do on your computer. Typing data onto your computer is only as safe as your computer itself. If you don’t have a virus scanner, a firewall, or any kind of protection against malware, your information can be logged and stolen before it ever leaves your computer.
The second is the moment the cashier opens the box and adds your credit card information to the pile. Most websites – cashiers in this analogy – store credit card information to make it easier for returning customers. The idea would be that the next time you want to make a purchase at the same store, you don’t need to go through the black box scenario, you just send in your order and the cashier fishes your card out of the pile.
If there’s someone else with access to that pile, or if that pile isn’t secured in a different black box of its own, your information – along with the information of hundreds, thousands or millions of others – can just be stolen. SSL doesn’t protect you from having your information stolen from the company that has it, and no company is secure. Just look at that link, see what large companies you can spot with huge data breaches. AOL, TJ Maxx, Sony, Ebay, JP Morgan; they’re far from alone. A study run last year indicates that as many as 43% of all companies in the U.S. experienced a data breach in the previous year alone.
With all of that in mind, why use SSL? If it’s apparently so easy for hackers to break into your system and steal user information, it’s probably better to not store it at all. If it’s easy for users to be infected and lose their information that way, why bother protecting it in transit?
This is a very nihilistic view, with one good point. On one hand, it’s probably a good idea to just not store user information if you’re at all worried about it being compromised. The problem with this is when it comes to user support; if you have no record of transactions, you can’t help your users when an issue comes up. If you don’t store credit information, you can’t issue refunds.
If you experience a data breach, that’s a bad thing. However, if you have your servers and databases encrypted sufficiently, that data is valueless to the hackers. The current standard of strong encryption is virtually impossible to break; it’s easier to kidnap and interrogate someone for the password to decrypt it than it is to use computers to guess that key and have it decrypted independently. Of course, that’s not SSL; that’s server security, a whole different business.
So, why protect the data in transit? One reason is that it’s just good practice. You don’t want to be That Business that lets users just throw their credit card information to the wind. You might as well just walk to a random person on the street and hand over the credit card. You have about as much chance of it being used inappropriately.
Another reason is that if a hacker ever notices that your company doesn’t use SSL, it’s a big red flag. They figure if you’re not using that security, maybe you’re not using other security. It makes you a target for further, worse data breaches. Using SSL then protects you from casual attacks of opportunity.
This is the first question you need to ask yourself. Do you need SSL for the pages where a user clicks to send sensitive information? This includes login pages and purchase pages, by the way.
The answer is an unequivocal yes. Yes, you need SSL for these pages. There is no reason, at all, ever, for you to not use SSL when a user submits any information more private than their name. Even that should be encrypted, realistically.
There’s one and only one exception to this, and that’s if you do not use any sort of login or purchase system yourself. If the only way people can log in to your site is through Facebook, and the only way they can purchase from your site is through PayPal, you don’t need SSL. The reason for that is that the Facebook login system and the PayPal payment system are themselves already encrypted. There’s no point in that transaction where you process or handle the information, and thus there’s no point where it’s not encrypted.
There are a wide range of SSL providers, ranging from GoDaddy to VeriSign to GeoTrust. Prices can range from $150 per year to $700 per year or more. It’s not a minor cost, but it’s not a cost you can ignore. “It’s too expensive!” is not, and never will be, an excuse to compromise user security. Don’t believe me? Just check out how much it costs to recover from a data breach. In retail, the best case scenario breaks down to $105 per individual customer record lost. Lost 100,000 customer profiles, and you’re suddenly out ten and a half million bucks. That’s the cheapest calculation for retail; for the healthcare industry, it can be as much as $359 per record.
The next question, and the more serious question, is do you need SSL on the rest of your site? Does your blog need SSL? Do your product pages need SSL? Does your homepage need SSL?
The answer to this is a resounding “it depends.” It’s really up to you, though there are some good arguments for doing so. There are also some good arguments against. Let’s take a look at the factors that go into the decision.
A similar concern is the type of data you’re sending. No one, anywhere, wants to steal and maliciously use the list of websites a user is visiting. No hacker wants to steal your Google Analytics data. It’s not profitable or useful to them in any way, so they don’t bother with it. If your site isn’t handling sensitive data, there’s no reason to secure that data handling.
In the vast majority of cases, the slowdown is measured in milliseconds. Virtually no user in any situation will ever notice.
The solution to this is to use a 301 redirect from the old URL to the new URL, which will pass most of the search ranking over. You will lose a little bit, but that’s unavoidable.
In the end, the choice is yours. I recommend SSL on every page of your eCommerce site, for the sake of security, and because a more secure web is desirable for everyone involved.