Where should you enable SSL?

Question

My last couple of projects have involved websites that sell a product/service and require a 'checkout' process in which users put in their credit card information and such. Obviously we got SSL certificates for the security of it plus giving peace of mind to the customers. I am, however, a little clueless as to the subtleties of it, and most importantly as to which parts of the website should 'use' the certificate.

For example, I've been to websites where the moment you hit the homepage you are put in https - mostly banking sites - and then there are websites where you are only put in https when you are finally checking out. Is it overkill to make the entire website run through https if it doesn't deal with something on the level of banking? Should I only make the checkout page https? What is the performance hit on going all out?

Answer 1

I think a good rule of thumb is forcing SSL anywhere where sensitive information is going to possibly be transmitted. For example: I'm a member of Wescom Credit Union. There's a section on the front page that allows me to log on to my online bank account. Therefore, the root page forces SSL.

Think of it this way: will sensitive, private information be transmitted? If yes, enable SSL. Otherwise you should be fine.

Answer 2

I only ever redirect my sites to SSL when it requires the user to enter sensitive information. With a shopping cart as soon as they have to fill out a page with their personal information or credit card details I redirect them to a SSL page. For the rest of the site its probably not needed - if they are just viewing information/products on your commerce site.

Answer 3

If the site is for public usage, you should probably put the public parts on HTTP. This makes things easier and more efficient for spiders and casual users. HTTP requests are much faster to initiate than HTTPS and this is very obvious especially on sites with lots of images.

Browsers also sometimes have a different cache policy for HTTPS than HTTP.

But it's alright to put them into HTTPS as soon as they log on, or just before. At the point at which the site becomes personalised and non-anonymous, it can be HTTPS from there onwards.

It's a better idea to use HTTPS for the log on page itself as well as any other forms, as it gives the use the padlock before they enter their info, which makes them feel better.

Answer 4

SSL is pretty computationally intensive and should not be used to transmit large amounts of data if possible. Therfore it would be better to enable it at the checkout stage where the user would be transmitting sensitive information.

Answer 5

Generally anytime you're transmitting sensitive or personal data you should be using SSL - e.g. adding an item to a basket probably doesn't need SSL, logging in with your username/password, or entering your CC details should be encrypted.

Answer 6

In our organization we have three classifications of applications -

• Low Business Impact - no PII, clear-text storage, clear-text transmission, no access restrictions.
• Medium Business Impact - non-transactional PII e.g. email address. clear-text storage, SSL from datacenter to client, clear-text in data center, limited storage access.
• High Business Impact - transactional data e.g. SSN, Credit Card etc. SSL within and outside of datacenter. Encrypted & Audited Storage. Audited applications.

We use these criteria to determine partitioning of data, and which aspects of the site require SSL. Computation of SSL is either done on server or through accelerators such as Netscaler. As level of PII increases so does the complexity of the audit and threat modelling.

As you can imagine we prefer to do LBI applications.

Answer 7

I personally go with "SSL from go to woe".

If your user never enters a credit card number, sure, no SSL.

But there's an inherent possible security leak from the cookie replay.

1. User visits site and gets assigned a cookie.
2. User browses site and adds data to cart ( using cookie )
3. User proceeds to payment page using cookie.

Right here there is a problem, especially if you have to handle payment negotiation yourself.

You have to transmit information from the non-secure domain to the secure domain, and back again, with no guarantees of protection.

If you do something dumb like share the same cookie with unsecure as you do with secure, you may find some browsers ( rightly ) will just drop the cookie completely ( Safari ) for the sake of security, because if somebody sniffs that cookie in the open, they can forge it and use it in the secure mode to, degrading your wonderful SSL security to 0, and if the Card details ever get even temporarily stored in the session, you have a dangerous leak waiting to happen.

If you can't be certain that your software is not prone to these weaknesses, I would suggest SSL from the start, so their initial cookie is transmitted in the secure.

Answer 8

I too would use HTTPS all the way. This doesn't have a big performance impact (since browser cache the negociated symmetric key after the first connection) and protects against sniffing.

Sniffing was once on its way out because of fully switched wired networks, where you would have to work extra hard to capture anyone else's traffic (as opposed to networks using hubs), but it's on its way back because of wireless networks, which create a broadcast medium once again an make session hijacking easy, unless the traffic is encrypted.

Answer 9

I have always done it on the entire website.

Answer 10

Kent nailed it. I just want to make a quick comment -- Amazon does this well I think. http for most of the site, but when it comes time to checkout, you gotta login again (oneclick is a little different), there's probably a different cookie at that point. I think other comments are saying the same thing, but I just wanted to give a concrete example.