5

I have a site which is mostly not an anything which needs to be protected. However there is a small part of the site which is only for logged in users.

So my regular site is Http & the site of logged in users is through Https.

On my regular Http site - I have a link to the https login page for those users who need to access that content.

I was wondering if this is a security issue - i.e. having a link from a HTTP page to a HTTPS page?

The only attack I can think of is if there is some kind of Man in the middle attack where someone modifies my link to point to a fake site with a URL which looks similar to mine.

Is this a concern? How can I mitigate it? Is the only way to turn my regular site also into https?

EDIT: My question is not a duplicate of the other question - the other question asks about switching to http post login. My question is totally different - it's about 2 different parts of the same site - one which needs login and one which is publicly accessible. I am asking if it's ok to keep the first part https (both for login and post login) and keep the other part http.

user93353
  • 1,982
  • 3
  • 19
  • 33
  • 1
    that's perfectly valid. That's the way many sites have been working for years, for example have a look at ebay.com – The Illusive Man Aug 18 '16 at 12:05
  • 1
    Possible duplicate of [What are the pros and cons of site wide SSL (https)?](http://security.stackexchange.com/questions/258/what-are-the-pros-and-cons-of-site-wide-ssl-https) – TTT Aug 18 '16 at 15:13
  • @TTT My question is not a duplicate of the other question - the other question asks about switching to http post login. My question is totally different - it's about 2 different parts of the same site - one which needs login and one which is publicly accessible. I am asking if it's ok to keep the first part https (both for login and post login) and keep the other part http. – user93353 Aug 18 '16 at 17:54
  • Is it the most secure setup? No, that would be HTTPS everywhere with HSTS enabled. Does it seem to be secure enough for several large companies who use this practice on their prominent websites (like amazon.com, nytimes.com, stackexchange.com, etc)? Possibly. It's just in this scenario users need to be careful to only input passwords/private info on the https version, and be aware attackers may eavesdrop or tamper with the http content. Test and see if there's a real downside to https everywhere, and if not deploy it that way (and after testing then turn on HSTS). – dr jimbob Aug 18 '16 at 18:10
  • it's good enough for stack to use mostly http, which makes sense since HTTPS is less efficient. If you don't have a lot of traffic/content (<100GB/month), you should probably use HTTPS everywhere. – dandavis Aug 18 '16 at 20:05
  • @dandavis https may be more efficient, with http2. And when it's not the overhead is mostly negligible – Tom Aug 18 '16 at 22:09
  • @user93353 - Thanks for the clarification. That is different enough that I have retracted my vote as dup. – TTT Aug 18 '16 at 22:51
  • @Tom: At the end of the day, https does more work and causes more work; everyone knows that security and convenience are at odds, so this is old news. admins must balance many factors. – dandavis Aug 18 '16 at 22:58

3 Answers3

6

Yes it is insecure.

The easiest way to attack that is sslstrip, a tools that do a MitM and automatically replace https links by http ones.

The only secure way to do it correctly is to have https on the whole website, and activate HSTS.

Note that even for your unlogged users https is usefull, for example to prevent third-parties (like ISP) to insert ads in your websites without your consent.

Tom
  • 2,063
  • 12
  • 19
  • 2
    He could host the https part of the site on a separate subdomain, and activate hsts for that subdomain. I think that should be sufficient. – Menno van den Heuvel Aug 18 '16 at 12:00
  • 3
    @MennovandenHeuvel no, because the link from http domain.com to https secureWithHSTS.domain.com could still be replace by anything else like http unexisting.domain.com if domain.com doesn't use https+HSTS – Tom Aug 18 '16 at 13:23
  • 1
    if someone can replace your site's links, you have bigger issues than forwarding to a phishing domain, and if they are coming from a customer's ISP, that's not your problem either... – dandavis Aug 18 '16 at 20:01
  • @Tom "no, because the link from http domain.com to https secureWithHSTS.domain.com could still be replace by anything else" This makes it harder to cache pages with a proxy server unless the proxy server is able to read the decrypted traffic. This is a cost that may not be necessary given the circumstances of the website. For example, the cost of a reddit account being stolen via a phishing attack is relatively low compared to a banking account. You have to balance these costs. – Jordan Melo Aug 18 '16 at 20:54
  • 2
    You're right, you have to balance the costs. Maintaining http+https is much harder (so more expensive), and in most countries there is an obligation of protection for personal dat (login+passwords are). And with http, anybody on the network can trivially replace link or insert ads or malicious content. – Tom Aug 18 '16 at 22:01
  • @dandavis not only your ISP can modify http content. And if you choose not to offer https, then it's your fault if your visitors gets hacked so it will became your problem even if you don't have ethics. – Tom Aug 18 '16 at 22:07
  • like anything, it's a balance of risk and reward; let's not pretend it's lopsided... – dandavis Aug 18 '16 at 22:57
1

The main threat is a Man-In-The-Middle attack here.

Any user navigating from http://example.com to https://example.com/secure/login could either be sslstrip'd or could be redirected to a phishing domain - https://example.org.

This also means that HSTS cannot be used to mitigate sslstrip. HSTS will ensure that once a browser has connected over HTTPS, it can never make a plain HTTP connection to that domain until the policy expires. Note that by "that domain" I either mean your actual domain, or a MITM controlled domain that pretends to be the plain HTTP version of your site.

If your secure content is on the same domain as your insecure content then this means that even if you are setting the Secure flag on all sensitive cookies, cookies could still be poisoned by a MITM. For example, in a session fixation attack, an attack on CSRF double submit cookies control or in the case where you're using a cookie to display raw content to the page an XSS attack could be possible. This is because a cookie set either on http://example.com and https://example.com will look the same to the server, as the Secure flag is not sent in each HTTP request for the server to differentiate them.

I would recommend using HTTPS site-wide, and implementing an HSTS policy with preload.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
0

As your site can be consulted in http mode, I assume that it contains no highly sensitive content. The choice HTTP vs. HTTPS is a matter of exchanging security for performance:

  • all what can be done in HTTP can be done in HTTPS and you get a higher security
  • HTTPS is more resource consuming

As a rule of thumb, use HTTPS if you can offer enough resources and HTTP if the value of the data is low.

It can be admissible to mix HTTP for normal pages and HTTPS for sensitive pages like credential exchange provided:

  • the server will reject any HTTP request to a secure page => if a page containing HTTPS links is rewritten with HTTP links you will get a redirect to the HTTPS page or an error
  • the overall security of the site is at HTTP level
  • you are confident in your users to control that sensitive pages come from your site

What you must be aware is that as soon as the session uses an insecure cookie (HTTP mode) you should not be confident in that session to access sensitive information.

So this is correct: HTTP consultation => link to HTTPS for login => new session after login => HTTP consultation - the overall security is low-medium because the session cookie is insecure and you only protect credentials

But this is bad: HTTPS login => HTTP consultation of non sensitive pages => HTTPS consultation/modification of sensitive data

because here the security level of the session has dropped to HTTP and it is still used for sensitive operations.

The minimal should be:

... => HTTP operations => HTTPS control of credential or of a secure cookie => new session => HTTPS operations ...

The greatest risk here is that you should instruct your users that the login page is special and that they should control that the little padlock is present and the url is in correct domain. The risk is here:

  • an attacker managed to get a copy of your login page
  • it manage to send one of your users to a page he controls
  • the user writes his credentials

=> the attacker has gained all accesses allowed to the user

TL/DR: having only a part of the site (including login page) in HTTPS is acceptable only if:

  • the login page is only accessible in HTTPS and creates a new session
  • any transition from HTTP to HTTPS requires a control of credentials (or of a special secure cookie)
  • all your users control that the URL of the login page is correct before entering their credentials
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • `the server will reject any HTTP request to a secure page` - this unfortunately does not mitigate sslstrip style attacks. The flow would be `Browser --http-> MITM --https-> server` - as you can see the server itself can serve HTTPS content to the MITM, it is just the user's browser that is over plain HTTP. – SilverlightFox Aug 19 '16 at 12:49
  • @SilverlightFox: that's the reason why I say to users should be educated to control URL of the secured page: if it is http of wrong domain *danger*... – Serge Ballesta Aug 19 '16 at 13:03
  • My site does not go to http post https login. It remains https post login also because I have sensitive content in that part – user93353 Aug 19 '16 at 15:12
  • @user93353: a user could look in the local history of its browser to come back and forth from the secured part to the public part even if there are no explicit links in the pages – Serge Ballesta Aug 19 '16 at 15:16
  • I don't understand - unless the user logs in the secured part will not be accessible to him even if he has a link. – user93353 Aug 19 '16 at 15:36