6

Possible Duplicate:
What are the pros and cons of site wide SSL (https)?

I am working on a site where all authentication is via facebook oauth2. I'd consider the nature of our content to be non-critical (basically news stuff). Had some discussions with client about securing site and felt that there wasn't a great reason to do right now but that Facebook and Microsoft do for all traffic (logged-in and not logged-in) whereas SO doesn't.

Not taking performance into account, would there be any security reason for us to run the site over HTTPS? I am using Rails with OmniAuth. Even though I consider the content to be non-critical, it might be easier to add at this point - perhaps user-to-user messaging (a currently unimplemented feature would require this - perhaps a reason why SO doesn't have user-to-user messaging?). Since all my authentication with Facebook is over HTTPS, would there be ANY reason that my non-HTTPS traffic with the end user would introduce a security risk to the end user?

I am asking because, when it comes to security, I'm often surprised what I don't know.

I'm using HttpOnly cookies in Rails 3.1. One thing I noticed was that I could copy out the cookie and get access even with HttpOnly in a different browser. Hmm.... not what I expected.

Community
  • 1
timpone
  • 349
  • 3
  • 8

4 Answers4

8

My general guidance to websites is to just build new sites on SSL, plain and simple. Make your life simpler.

Keep in mind that if you don't, all traffic between your users and your servers can be intercepted and manipulated. So, for example, if you were running a forum, I could intercept cookies and post to the forum as your users. Forum data is probably not the end of the world and has nothing "private" associated with it. But having users impersonating other users is just icky.

Using news as another example, as you pointed out, probably nothing sensitive. But if you have a profile feature, then others could see the news I have signed up for. And potentially manipulate it. It's a data leak sort of thing. Again, not the end of the universe, but icky.

None of these problems matter until one day you wake up and they suddenly matter (like if you get big and someone writes a FF extension to make it as simple as "follow these 3 easy steps").

Your life will be simpler if you start SSL and never look back.

Eric Fleischman
  • 522
  • 3
  • 3
  • I agree with the general point. Honestly, hesitant to make this jump due to time / testing contraints. Have to think through this a little bit more. Do https and Varnish work well together? – timpone Sep 19 '12 at 17:55
3

SSL is cheap financially and computationally.

If you're doing new deployment, there's no reason not to if you're using any login at all. When in doubt, use SSL. You may require it later, and rolling out later may be very problematic.

If you think you can't use SSL, you should reexamine your requirements and ask a security pro if you're not mistaken.

Hubert Kario
  • 3,708
  • 3
  • 27
  • 34
1

For a self-contained site with no advertising, if security is critical, I would recommend that you use SSL sitewide (only HTTPS, no HTTP). If there is no need for security, HTTP is fine.

If the site is not self-contained -- if you want to use advertising, third-party CDNs, third-party Javascript widgets, or the like -- life gets more complicated. See below.

The best discussion I can find of reasons why you might not use SSL is found in What are the pros and cons of site wide SSL (https)?. The short version is: if security matters, use SSL, unless you can't -- and that question explains some situations where you can't.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
1

One generally chooses to have their web application use HTTPS in two cases :-

  • The communication between the server and the client contains some kind of sensitive information and stands the risk of being intercepted. In such cases the data needs to be encrypted and sent securely to the server and back.
  • The client needs to know that it is in fact talking to the real server! In such cases, the browser can verify the server by checking if the servers certificate traces back to a root certificate.

In your case, your webapplication uses HTTPS to communicate with FB and login -- in the process transferring authorization tokens, access tokens among other sensitive information. If your web application does not use HTTPS in talking to the client, and if there is a client log-in functionality provided by your web application it is imperative that you provide HTTPS at your side too.

Else, its not so important.

However, generally sites which have a certificate signed by a root CA are more trusted -- I would never sign into a website which does not have a valid certificate of its own using OAuth ; whether it be for the purposes of accessing a stream or otherwise.