14

Should we force website from HTTP to HTTPS , one of the method is using .htaccess:

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

But what I notice is that some service like Google Translate can't translate any HTTPS website.

So what is the best practice to do it while keeping the user secure?

  • Force to HTTPS using .htaccess even they browsing static page

  • Don't force user to HTTPS automatically but the link in the hyperlinks will link to HTTPS?

  • Use HTTPS only while form POST or page that contain sensitive information.

  • Allow user to select HTTP or HTTPS

  • ...

xDragonZ
  • 243
  • 1
  • 3
  • 9

7 Answers7

16

Set up a rule which redirects any attempt to access the site via HTTP, over to the front page via HTTPS (redirect any attempt to access anything matching http://www.example.com/* to https:/www.example.com/).

Enable HSTS. This tells browsers to connect to your site via HTTPS in the future.

Set the secure flag on all cookies.

Make sure pages delivered over HTTPS don't load any content via HTTP.

Read the following questions on this site:

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

If your site uses authentication then it must also use HTTPS for the life of the session.

That rewrite condition is insecure. An attacker can still hijack the redirect with a tool like SSLStrip, and if the user is posting sensitive information then it will be leaked. You should enable HSTS to enforce HTTPS and Read Owasp A9 - Insufficient Transport Layer Security.

rook
  • 46,916
  • 10
  • 92
  • 181
  • STS is only supported by a minority of browsers. The redirect mechanism isn't itself exploitable, but it would be insecure to submit information through an encrypted connection even if later redirected, but that's not something that the server can prevent without blocking port 80, since no server action can be taken at all until *after* the request has been submitted. – tylerl Nov 06 '12 at 00:58
  • 2
    @tylerl Throwing a 302 redirect over http to an https connection is trivial to exploit. If you don't see how this is serious problem, fire up wireshark and look at the traffic. HSTS is supported by chrome and firefox, which is the STRONG MAJORITY of browsers. IE has never been known for security, so i wouldn't be surprised if they just ignored this feature. – rook Nov 06 '12 at 03:13
  • chrome = 30%, ff v4+ = 20%; so neither majority nor minority. Again, the redirect is not exploitable, but the request BEFORE the redirect can be sniffed/spoofed. The catch is that if you didn't solicit the request, **there's nothing you can do about it**. Whether you send a redirect, a 404, a 500, or no response at all, the attacker can STILL sniff/spoof the connection. There's no vulnerability in the redirect itself. It's like saying a bank is insecure because you can get robbed on drive over to it. – tylerl Nov 06 '12 at 04:24
  • @tylerl Depends who you ask: http://www.w3schools.com/browsers/browsers_stats.asp . Personally I don't know anyone that uses IE. And you could not be more wrong about the redirect, the attacker can send whatever response they would like in a MITM attack, and SSLStrip will remove the https redirect for you. I am actually surprised i am even debating this, i thought this was obvious. – rook Nov 06 '12 at 04:59
  • 1
    No argument that non-ssl traffic is exploitable. My question is this: If you don't return a redirect when traffic arrives on port 80, what *do* you return? Is there anything you can do that would **not** be exploitable? Assuming a browser that doesn't support STS gets sent by a third-party to your site over HTTP. If you don't return a 302, what do you return which would be safe? – tylerl Nov 06 '12 at 05:22
  • 1
    @tylerl THat is a good question that probably deserves its own post. Really a redirect is just addressing a symptom of a problem. Having a redirect is a good thing, but you need to address mixed content vulnerabilities that would cause this to happen in the first place. Also set the "secure" flag on session id's. Also warn IE users that they are potentially vulnerable to attack. – rook Nov 06 '12 at 07:52
4

This entirely depends on your security goals, which you haven't stated. If you are a banking site then yes, force all https access. If you are a search engine which has user accounts then maybe use a model where some pages have enforced https. If the security benefits of forcing all https outweigh the drawbacks to your business model then do it, otherwise accept the security risks.

GdD
  • 17,291
  • 2
  • 41
  • 63
  • 1
    If your website has user accounts, you should serve the whole thing over HTTPS. Otherwise, an attacker could replace your "login" links with an insecure version. Some people may notice, but most won't. – Brendan Long Nov 05 '12 at 21:38
  • Using words like **should**, and **must** may lead you to use security strategies that are unnecessary, and incompatible with your business. Security is a business enabler, not an end in itself, and it's important to keep that in mind. – GdD Nov 06 '12 at 09:59
  • 2
    Maybe I'm out of place by thinking that when a customer trusts you with personal information (including passwords which are almost guaranteed to be used on other websites), then you **should** protect it. If you want to do that, then there's no such thing as enforcing HTTPS on *some pages*. [It's all-or-nothing](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). If you want to protect your users *at all*, you need to be all HTTPS. – Brendan Long Nov 06 '12 at 15:57
1

If your leave any of your pages insecure, all of your pages are insecure, because anyone in-between your users and you (like other people in a coffee shop) can easily intercept all of the traffic and replace https:// links with http:// links. They can then do whatever they want with any page on your site (like replace the login page with their own, then get access to whatever the user has stored on your site).

There are two ways to handle this (and they go together):

  • Use HTTPS on every page. This way, no matter how the user gets to your site (no matter which bookmark they use), they'll always go directly to the secure version.

  • Use HTTP Strict Transport Security. This makes it so once a user's browser has been to your site once, it will refuse to connect to the insecure version for some period of time. This isn't as nice as it could be, but it's much better than nothing.

The only downsides to this are:

  • Some services, like Google Translate, are broken.
  • HTTPS takes a completely insignificant amount of processing power. This excuse almost made sense 10 years ago, but our computers are so fast now, unless you're Google, you won't even notice. If you are Google, you can afford it to keep your customers happy.
Brendan Long
  • 2,878
  • 1
  • 19
  • 27
  • So you think you should HTTPS static Html pages? As to the speed effect, this depends. For prolonged visits (multi-page sessions) even a short delay can accumulate. Try browsing a on-line store with https at all pages... Now think about it from a hoster's stand point, he has so serve hundreds if not millions of sessions per minute even a 0.001% delay is noticeable and will cause "parasitic drag" for all sites. – Igal Zeifman Nov 07 '12 at 06:57
  • 2
    What I'm saying is that if your site is supposed to have any secure content, then HSTS is *the only way to make it secure*. Feel free to suggest another solution that prevents the trivial attack in my first paragraph. All of Google is served over HTTPS (this might be because of one of my addons?) and I haven't noticed any performance problems at all. Like I said: `This excuse almost made sense 10 years ago, but our computers are so fast now, unless you're Google, you won't even notice. If you are Google, you can afford it to keep your customers happy.` – Brendan Long Nov 07 '12 at 15:20
  • If you feel that SSL will fool-proof you against session hijacking I can refer you to these sources (http://stackoverflow.com/questions/12233406/preventing-session-hijacking) or ( http://stackoverflow.com/questions/10801916/ssl-and-session-hijacking-fixation) And yes, it will help but then again this is just another barrier your can raise, not a solution. As to the speed issues, you don't have to be google to care about it. A hosting company with 10,000 clients can serve millions of sessions per day, if all are https that the slowdown will be noticeable for all. – Igal Zeifman Nov 08 '12 at 08:43
  • Also you are correct, Google uses https, ebay, amazon, whitehouse, fbi and cnn don't. Having said that, you made a good point (+1). Still for static pages or for sites that don't allow logins, I personally would use https. In some cases I guess you can "divide" your site and manage all loged request on diffrent httpsed [is this a word?] sub-domain. Still, good point. :) – Igal Zeifman Nov 08 '12 at 08:52
1

It should be clear from the responses, there is no one right or wrong answer. Many factors need to be kept in mind.

It is true that https can add some overhead. However, with current server technology, I'm not convinced this is as big an issue as it once was.

SSL/TLS is not a magick bullet that will automatically make your site secure. It is just one part of a strategy. Many security breaches are due to the backend server data being compromised through other channels and failures in storing/managing data securely.

While it may be true that there is less need to use SSL on pages which don't have any obvious security implicaitons, I would be very careful. The problem is that a mixed site adds complexity and greater possibility for mistakes. This is particularly relevant if your site is large, complex or has multiple developers. Given the overheads associated with encryption are not as high as they use to be, in general, if you have a reason to use https for some content, I would favor using it for all content on the site.

Tim X
  • 3,242
  • 13
  • 13
0

I am going to agree with Rook

If your website has public parts to it leave them as normal http no reason to add extra load to your servers and your users. Now if you have users logging in and doing anything you have a service to protect them. From the moment they hit the login page to the moment they log out everything should be done in https. Make sure that when you set the users cookies that its for https only, you will also want to employ something on the java-script side to check if they have https cookies and if they do it should force the redirect to https this way you never transmit the users cookies over http.

The trust is you cant end your security with just that make sure you force strong passwords you have good hashing policies and poilcies about storing data in rest. It depends on the application you have but unless you cover your self at all points your just asking someone to test there skills out on you until they win and post your sites users information on a public torrent.

WojonsTech
  • 117
  • 2
  • 1
    What about before they hit the login page? Do your users actually go up to the URL bar and type "https://www.yoursite.com/login" to login? Or do they click the "login" link on the page you left unsecured? – Brendan Long Nov 06 '12 at 15:58
-2

Agreed with @Rook and @WojonsTech.

No need to https the whole site.

For one, this will slow down your website...

So you`ll loose speed but gain very little (if something at all) in terms of extra security.

Igal Zeifman
  • 563
  • 3
  • 8
  • 2
    There is almost no speed effect, and there *is* [a good reason](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) to HTTPS the whole site. – Brendan Long Nov 06 '12 at 15:59