Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've left my credit card information at I don't know how many web shops, and I noticed that some are very "sensitive": they go to HTTPS as soon as you go to the checkout area, which is good.

Some, however, let you enter your credit card information on a page that's on regular HTTP. As soon as you submit the form, they switch to HTTPS (or so you hope). I've even seen one that redirected to plain HTTP immediately after doing something in HTTPS -- Firefox's nice coloured HTTPS indicator in the address bar flashed before my eyes and was gone instantly. The point is: you don't know in advance whether they will encrypt your data when you submit, or not.

So why don't web shops just do everything in HTTPS? I think it would make me, as a customer, feel a lot safer. Are there any big advantages to use plain HTTP? (Apart from the fact that it's much simpler to set up for the admins, which I don't think is a very good excuse.)

Also, is there any way to find out in advance if one of those "unsensitive" web shops will switch to HTTPS, before I submit my credit card information?

share|improve this question
This should be a Community Wiki question. – Izzy Nov 15 '09 at 18:59
up vote 2 down vote accepted

It's a fair bit faster to service requests using HTTP, especially when the browser isn't pipelining requests. Faster to service == less resources required to serve the site, less resources == less cost, less cost == more profit. And as we all know:

  1. Underpants
  2. ...
  3. Profit!

All of this goes double, triple, or more when the shop is using a hosted cart or site or whatever -- in that instance, the vendor has no control over what the site does, and the person who runs the overall site has no motivation to make you feel better unless the vendor takes their business elsewhere (and let's face it, working out that you're not making sales because your shop isn't sufficiently SSL'd isn't the sort of thing that someone who's relying on a third-party cart host is likely to come up with).

As far as knowing whether you're going to be sending your card data down the tubes without a bodyguard, if the submission page is HTTPS your browser should issue a warning saying "this page will be sent unencrypted" if the form submission URL isn't HTTPS also. However, if the form page isn't secured, then normally you won't get a warning (in theory, you could have your browser setup to warn you for every form submission that isn't HTTPS, but that would drive you insane and nobody does it).

share|improve this answer
in addition ones that don't have things POST-ing through SSL are doing it wrong and I would discontinue using those site's since the plain text communication can be easily compromised. – xenoterracide Nov 15 '09 at 21:01
Yeah, I think we've established that. – womble Nov 15 '09 at 21:05

Technically, in order to call a transaction secure, the only part that needs to be encrypted is the form submission. That means that the form's action URI needs to use the HTTPS protocol. Your browser may have accessed the form using an unencrypted connection, but the submission is the real critical part.

Even knowing and understanding this, I still prefer to access an order form over an SSL connection.

share|improve this answer

There are many possible reasons:

  • SSL encryption can be CPU-time costly. It will require more machines to serve or more resources on a single machine.
  • SSL cannot be cached as easily. Many ISPs have a passive web cache that can cache this close to the consumer for faster loading.
  • Serving SSL and non-SSL content on the same page is pretty much impossible without getting browser warnings. This makes SSL an all-or-nothing per page issue.
  • SSL traffic cannot compress. Usually compression is done before the SSL encryption is performed, but if not, SSL will prevent compression from being useful.
  • SSL requires more resources on the consumer side as well. This may not be a big deal for a desktop or where A/C power is available, but laptops and cell phones have limited power available at times.
  • SSL also is search engine unfriendly. I believe most search engines will look at https, but not all will score such pages identically, or even traverse them.

Using SSL where it's not needed would be a lot like putting locks on all your doors. Sure, you can do that, but sometimes you really can't wait to fish a key out of your pocket to get into the bathroom. :)

share|improve this answer

For me, I am not aware of any webshop that does not uns SSL (including our own shops).

Though we use SSL as short a possible since the pages usually load faster without SSL.

share|improve this answer

Steve Gibson has a great discussion about this a few weeks ago, and explained why HTTPS needs to become the standard for all web communications (like Google is suggesting with SDY). is a link to the actual podcast (#217), and is a link to the whole collection of Security Now! podcast.


share|improve this answer
Nothing like Steve Gibson to point out the obvious. Did he try and fix the rotting bits on your hard drive after the podcast? – Doug Luxem Nov 15 '09 at 20:29
Annnnnnd how are we going to share IP addresses for multiple websites without sharing the keys/certificats around which defeats the purpose of SSL in the first place? – Mark Henderson Nov 15 '09 at 21:04
@Farseeker: There are several ways. – womble Nov 15 '09 at 21:07
There's already a way in place as far as I know which puts the host header information outside the encrypted part...? (not fully internet ready yet though I figure) – Oskar Duveborn Nov 15 '09 at 21:12
Right now you can share a single certificate with multiple sites, however, that won't work for a general purpose "host your domain here" hosting company. But then again, either would switching to/from SSL per-domain in that case. – Michael Graff Nov 15 '09 at 22:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.