Using SSL Across Entire Site

Question

Instead of just having a few select pages for HTTPS access, I was thinking about just using SSL for my entire site.

What would be the drawbacks to this?

I would like to allow social service logins (like FaceBook), but we will also be storing credit card information, which is why SSL is essential. Would there be any other problems with this?

Don't store credit-card numbers. Just don't do it. Every credit-card gateway will store them for you, and give you an ID that you can use to make additional purchases *for your account only*. — Michael Lorton, Dec 23 '10 at 03:22
Yes, we are not storing them, PCI regs are crazy too. We are using Braintree's vault, but still, there is CC info involved. I want to make sure the Facebook login with SSL won't make any warnings start popping up. — Dex, Dec 23 '10 at 03:23

score 38 · Accepted Answer · edited May 23 '17 at 11:53

It is highly recommended these days to run the entire site on TLS (https that is) if possible.

The overhead concern is a thing of the past, it is no longer an issue with the newer TLS protocols, because it is now maintaining sessions, and even caching them for reuse if the client drops the connection. In the old days this was not the case. Which means that today, the only time you have to do public-key crypto(the type that is cpu heavy) is when establishing the connection. So there isn't really any drawbacks when you have a cert anyway. This means that you won't have to send people back and forth between http and https, and the customers will always see the lock sign in their browser.

Extra attention has been drawn to this subject after the release of Firesheep. As you might've heard Firesheep is a Firefox addon that let's you easily (if you are both using the same open wifi network) highjack other people's sessions on sites like Facebook, Twitter etc. This works because those sites only use TLS selectively, and this would not be a problem for them if TLS was enabled site-wide.

So, in conclusion, the cons (such as added CPU use) are negligible with the state of current technology, and the pros are clear, so serve all content via SSL/TLS! It's the way to go these days.

Edit: As mentioned in other answers, another problem with serving some of a site's content (like images) without SSL/TLS, is that customers/users will get a very annoying "unsecure content on secure page" message.

Also, as stated by thirtydot, you should redirect people to the https site. And you can even enable the flag that makes your server deny non-ssl connections.

Another edit: As pointed out in a comment below, remember that SSL/TLS isn't the only solution to all your site's security needs, there is still a lot of other considerations, but it does solve a few security issues for the users, and solves them well (Even though there are ways to do a man-in-the-middle, even with SSL/TLS)

thirtydot · Answer 2 · 2010-12-23T02:30:59.767

3

It is a good idea to do this if possible, however you should:

~~Serve static resources (images, CSS, etc) from plain HTTP to avoid the HTTPS overhead.~~
(Don't do this or you will get warnings about "insecure resources").
You should also redirect the HTTP homepage to the HTTPS version so that users do not have to type HTTPS to access your site.

Drawbacks include:

Less responsive browsing experience - because there is more back and forth between the server and client with HTTPS vs HTTP - the amount this is noticeable will be dependent on the latency between the server and client.
More CPU usage on your server - because every page has to be encrypted instead of just the select few.

edited Dec 23 '10 at 02:30

answered Dec 23 '10 at 02:18

thirtydot

224,678
48
389
349

2

If you serve anything w/o https you need to make sure that it comes from a different hostname to not send session cookies over clear channel. – MK. Dec 23 '10 at 02:22
You can easily configure a subdomain not to send cookies. However, I just realised that following the "serve static resources" point of my answer brings up annoying warnings about "insecure resources". – thirtydot Dec 23 '10 at 02:29
The problem is not that the warning is annoying, although it is. The problem is that, having gotten the warning, the user's only choices are (a) to ignore the warning or (b) to not ignore the warning, and those are both very bad choices. – Michael Lorton Dec 23 '10 at 03:24

score 1 · Answer 3 · answered Dec 23 '10 at 02:03

1

Server side algorithms for establishing SSL connection are expensive, so serving all content via SSL requires more CPU power on the back end. As far as I know that is the only drawback.

answered Dec 23 '10 at 02:03

MK.

33,605
18
74
111

1

Google claims that in this day and age, the additional CPU required for HTTPS is not that big a deal. – Thilo Dec 23 '10 at 02:07
1

Yes, I've read it is about ~1% extra CPU. I'll be on the cloud anyways and they don't charge me per clock cycle. – Dex Dec 23 '10 at 02:50
Dex: 1% is BS, because it will depend on A LOT of factors. How many connections, how many requests per a visitor etc. CPU is not free even in a cloud -- you will need more instances. I don't have a good grasp on how big the penalty is, but it exists. Anyways, I'm just giving you cons. I would recommend to run it completely over HTTPS, that's what I do for any site that requires authentication. – MK. Dec 23 '10 at 04:38

Thilo · Answer 4 · 2010-12-23T03:19:00.450

1

SSL was not designed for virtual hosting, especially of the elastic cloud type. You may face some difficulties if you cannot control the host names of the web servers, and how they resolve to IP addresses.

But in general, that it is excellent idea, and if you allow users to login to your site, almost a necessity (as shown by Firesheep).

I should also add what I am trying to do. I would like to allow social service logins (like FaceBook), but we will also be storing credit card information

For the pages where the user can review his credit card information, or make financial transactions, better shift into a more secure authentication mode. Facebook is a big target, and attracts hackers. If someone's Facebook account gets hacked, and they can then spend money or gather credit card info from your site, that would not be good. Accepting social service logins for non-critical stuff is fine, but for the more serious parts of your site, better require additional passwords.

edited Dec 23 '10 at 03:19

answered Dec 23 '10 at 02:10

Thilo

257,207
101
511
656

Will Facebook not require SSL if my site is using SSL? – Dex Dec 23 '10 at 03:29
Regardless of what Facebook requires, people's Facebook accounts are being hacked, could just be because of poor passwords. – Thilo Dec 23 '10 at 03:53
1

Even if you force SSL on Facebook (which it accepts), your timeline updates are fetched via non-encrypted AJAX which defies the reason to actually use SSL on Facebook. – Mike Jan 27 '11 at 08:03

score -1 · Answer 5 · answered Dec 23 '10 at 02:36

It is highly recommended these days to run the entire side on TLS

It's highly recommended by some people.

The total number of users your system can support is gated by either the CPU demands or IO load; if you are up against the CPU, TLS makes it that much worse.
Encrypting the traffic makes it impossible to use certain kinds of diagnostic techniques.
Most browsers will give your user a warning if you load any non-encrypted files. Which can be a huge problem if you are trying access third-party resources.

In some circumstances (e.g. a lot of money at stake), it makes sense to just bite the bullet and encrypt everything; in others, the odds of an attacker intercepting a packet in flight and deciding to hijack the session are so low and the amount of damage that could be done is so small, you can just go bare-back, as it work. (For example, this session, the one I'm using to post this answer, is unencrypted and I really, really don't care.)

For still other cases, you may want to offer your user a choice. Someone using a hard-wired connection in his own basement can make a different situation than someone using WiFi at the Starbucks across from a Black Hat convention.

I'm working on a protocol and a library to let you sign XHR requests. The idea is that the entire site would be set up as static files of HTML, CSS, and JavaScript, which would be loaded from a CDN. The actual application would be conducted entirely by JavaScript making AJAX and COMET requests. Any request that has to be authenticated is, but as a practical matter, most requests do not. I've done several sites this way -- they're very, very scalable.

"Someone using a hard-wired connection in his own basement" still gets his traffic routed through his ISP, the service's ISP and backbone providers along the way. Plus, without TLS someone could give you fake DNS data and you would talk to the wrong site. — Thilo, Dec 23 '10 at 03:14
Luckily, here on Planet Earth, the difficulty of breaking into a backbone and sifting through to find the packets you are trying to hack is much higher than the difficulty of breaking into the site itself, and both are usually higher than the difficulty of going over to the sys-admin's house and poking his Chihuahua with a soldering iron until he gives you the password. Security is about realistic responses to realistic threats. Besides, if the DNS is wrong, why would the wrong site bother to use TLS? — Michael Lorton, Dec 23 '10 at 03:19

score -1 · Answer 6 · edited Nov 11 '12 at 15:23

We run a fully forced, secured website and shop. I've done this on the advice of a friend that knows a thing or two about website security.

The positive is that our website doesn't seem noticeably slower. Also Google Analytics runs although I can't get ecommerce to work. If it protected us against attacks I can't say offcourse but until today no trouble.

The bad thing however is that you will have a very hard time running Youtube and Social ("Like") boxes on a secured website.

Tips for good security:

Good webhost (they will cost you but it's worth it!)
No login for visitors. It kills usability but with a fast and easy checkout it goes and the obvious pro is that you simply don't store sensitive info.
Use a good Payment Service Provider and let them handle payment.

*2 I know this won't go for a lot of websites but "what you don't have, can't be stolen". We have been selling on our webshop without login for 2 years now and it works fine as long as the Checkout is Mega simple and lightning fast.

Using SSL Across Entire Site

6 Answers6

Linked