3

OK, this question might seem a no-brainer for a professional but keep in mind I am not a professional web developer so my knowledge in this field is very limited.

I have been pondering over time trying to decide if I should make my website accessible with both HTTPS and HTTP (the less important pages not needing encryption) or if I should only use HTTPS for all the pages in my website.

The reason I did this is because I'm afraid a Man in the middle attack could theoretically inject JavaScript code inside the web page when one of the users is trying to browse the website and cause unwanted behavior (such as stealing the authentication cookie or other stuff).

So, what I would say is that my questions basically boil down to:

1) Is this a mistake? Do I really need HTTPS everywhere. It's more computation. And no, I don't live by the - why worry about computation in today's day and age? With the current hardware you should be able to count the number of atoms in a sandwich in less than a day - type of mentality. I think it's a bad mentality for a programmer since it invites sloppy inefficient algorithms to be written. If there's a better way of doing things that allows for lesser computations then I would like to hear it.

2) Is it still somehow possible for a person to inject unwanted code in my webpages when they're in transit to an end user even if I use TLS certificates? I know it sounds impossible but, like I said, I'm not an expert so I would want to hear your opinions.

3) Finally, is HTTPS a good way of preventing cross-site request forgery attacks? I heard somewhere that it is although I couldn't understand the logic behind it. The best it can help with, as far as I see it, is allow the end user to realize that the fake webpage is not secured and help him figure it out that something is fishy. Does it help in any other way other than that? Or do I need to implement some extra fail-safe mechanisms to prevent that?

Thank you for your time!

Also, in response to the duplicate reaction, I still believe that this question is also somewhat original in regards to the fact that I did additionally ask about the computational requirements for a solution as well as asking if XSS can be used even with TLS used

Mr Sir
  • 175
  • 1
  • 5
  • 1
    Consider that if your have a not protected page then https may be stripped from any links leading from this page to *protected* pages. – Cthulhu Aug 29 '15 at 17:01
  • 1
    It's debatable whether HTTPS is always good, but most people agree it's never bad (or extremely rarely, anyway). – user253751 Aug 30 '15 at 11:00
  • HTTPS isn't an silver bullet for security like most people think. HTTPS only creates an safe transport between browser and server. All server side and client attacks will still work. – Raymond Nijland Sep 14 '15 at 15:52

2 Answers2

5

  1. As with all things in security, using HTTPS is a trade-off. You're trading some performance and potentially customer inconvenienace for improved security and other possible benefits (for example google boosting the ratings of SSL enabled sites). Only you can answer whether that's worth it, as only you know what your site does and whether the trade-off is worth it. As a rule of thumb, I'd say that if you're processing any personal or sensitive data for your users it's likely worth it. If you run a purely static brochureware site it's likely not. One thing is, if you do do HTTPS (e.g. because you have a logged in section) do it all over the site, not just in places.

  2. In the general case it wouldn't be possible for attackers to inject code into your site, but the full picture could be more complex than that, depending on what your site does and who is likely to attack it. Safe to say that in most cases it makes it a lot more difficult for this to occur.

  3. HTTPS generally does not protect against CSRF attacks. If an attacker can cause a logged-in user to take an action on your site, the fact that the action is taken over an encrypted connection does not, in and of itself, make that any different.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • Just to make things entirely clear: why do I necessarily have to use HTTPS everywhere if I have a login form? Why not just use it on the login page? – Mr Sir Aug 29 '15 at 17:25
  • 1
    the reason is that once the user has logged in, if you revert to an unencrypted connection, the session token will be sent over the Internet in a clear text format, which could allow it to be intercepted. As the session token is essentially as good as the password for the duration of the session, this is a bad idea. – Rory McCune Aug 29 '15 at 18:01
  • 2
    This answer is pretty much spot on. I'd just like to add that I personally would much prefer my connection to a site to be encrypted, even if I'm not doing anything sensitive, or business critical. I believe that we all have a right to privacy even if we're not talking about anything particularly interesting. – Nic Barker Aug 30 '15 at 00:36
  • Re: SSL not needed for a "purely static brochureware site" — because of stuff like this http://arstechnica.com/business/2015/08/atts-free-wi-fi-hotspot-injects-extra-ads-on-non-att-websites/, even a static site will benefit from SSL. It make sure your customers see what you want to show them, not ads or malware injected by a compromised router, a bad network, etc etc etc. – Joel L Aug 30 '15 at 09:34
  • The tradeoff also involves some development effort. @JoelL: He said "worth it", not "needed". – user253751 Aug 30 '15 at 11:02
  • The trade-off if anything is the extra maintenance required to keep an up to date certificate, and the one-time work of configuring the server. Performance has not been an issue for many years. Even on a very old AMD Athelon 2600 processor (30% saturated 100 Mbps uplink), I could only get it to choke on TLS handshakes when using a particularly poorly optimized implementation of secp521r1, or when using large (4096) DH parameters. Using something light like x25519 or secp256r1 causes absolutely no noticeable handshake overhead. – forest Feb 26 '18 at 07:13
1

With modern Intel CPU's (and we're talking 5-7 years now...) there is no significant performance hit on the computation involved in an SSL connection. So - from a performance perspective there is no reason not to use SSL everywhere.

Another caveat is the vulnerability of mixed content on your page. You should not be referencing HTTP resources on an HTTPS-served page.

If you are using JS or CSS libraries access them without the protocol as //css/mycsslib.css

Danny Lieberman
  • 388
  • 2
  • 6