Pablowe

HTTP Over SSL Best Practices

Encrypting connections to your web server using HTTPS is a trade-off between performance and security. Therefore, there’s no “right answer” for exactly what traffic to encrypt; it’s a business decision. There are, however, best practices that can guide you in the decision making process. In fact, there is a “golden rule” for making this decision:

If it were your session, would it bother you if I got the data? If your answer is yes, then the data should be encrypted!

While the above is a great rule, organizations are often bound by legal guidelines (which MUST be adhered to). For example, if you’re storing/transmitting credit card information, you must adhere to the PCI DSS and possibly other standards. If you’re dealing with classified information, there are a plethora of DoD/Military specifications that must be obeyed (a partial list here).

Login

It is very often good practice to have site login done over HTTPS, but not always. You need to evaluate the ramifications of what would happen if this data were sniffed over the wire. For example, I would not care at all if my del.icio.us password were sniffed because it’s just a bunch of public bookmarks, anyways. On the other hand, I would be nothing short of livid if my online bank did not encrypt my login because there is real money at stake if my login were compromised.

Personal Information

Even the most mundane of sites may offer the ability to input/update personal information such as: name, address, phone, email, etc… Depending what the “etc…” is, you may want to have this information displayed over SSL. The post began by saying that HTTPS is a tradeoff between performance and security. For the vast majority of websites, updating account information is not the typical use-case. I would venture to say that the average is less than 0.01% of traffic would be to account information pages. As such, there would be very little overhead in making that subsection of the site go over HTTPS.

The Performance Trade-Off

Unfortunately there is no catch-all formula about how the overhead is for HTTPS, it is highly dependent on the web server software, hardware, software, page content, client software and configuration, and a whole host of other things. The best thing that you can do is to benchmark your own setup.

Usability

An additional consideration is how SSL affects site usability. Does it require re-direction to a different (sub)domain? Some (most? all?) browsers will also display a pop-up requiring the user to view and accept the certificate if it’s not signed by Certificate Authority. Yes, self-signed certs are cheaper and easier. But my trust level of the website immediately declines if I see that they have not taken the time to get a real CA signature. As a user, I can only assume that their security scheme is half-baked and my data is 100% at risk (even though this is not necessarily the case).

Perhaps the best approach for sites that don’t really store data that should necessarily be encrypted is to give the user an option. You can default to HTTP, but if the user goes to HTTPS explicitly, you can put their entire session over SSL. Google Mail, for example, always defaults to HTTPS on login but HTTP elsewhere. If I explicitly go to https://www.gmail.com/ though, my entire session will be over https. This is a great trade-off for people who don’t particularly care if their gmail is read and those (like me) who do care.