Is a company website secure against sslstrip if it doesn't use ssl on homepage but ssl everywhere else?

Question

Most ecommerce websites use SSL/TLS when you want to log. But most have homepage using http only. Is it enough to have SSL/TLS on login page and logged page to prevent sslstrip ?

Answer 1

Checking correct usage of HTTPS is ultimately the sole responsibility of the user. The users need to look at at least 3 points when visiting a web-page:

• Are they expecting HTTPS to be used (at least for this part of the site)?
• If so, is the certificate valid (lock/green/blue bar, without warning)?
• If so, is the host name in the address bar that of the site they intend to visit?

Answering yes to these 3 questions is required for HTTPS to be used correctly.

Not enabling HTTPS on the initial page isn't necessarily the end of the world. This page may be vulnerable to SSLStrip attacks, but what's on that page may not need to be transferred securely.

• If there is a link to a "secure section", the user should check that it sends them to the site they expect (see 3 points above). That's the user's responsibility.
• The secure section of the website shouldn't assume that what was done before entering the secure section (e.g. adding items to a basket) was done securely (the user should always confirm). The login landing page itself (if any) should also be served over HTTPS (so that the user can expect the login form to be sent to HTTPS too, see this OWASP rule). In addition, different session management should be used, and the non-secure session should be discarded, so as not to allow session theft. That's the web developer's responsibility.

Most websites may have a plain HTTP welcome page, if only to perform a redirection to HTTPS or send the first HSTS header. This may indeed be vulnerable to SSLStrip at this stage, but there needs to be a starting point if the user doesn't know what to expect (and most will use plain http:// URLs first). Automatic redirections can (only) mitigate the risk. The only way around this is either for the user to know that only https:// URI will work or for the site to be part of the pre-loaded HSTS list.

(No website is secure against SSLStrip if the user or the browser doesn't expect HTTPS to be used. This expectation can be activated automatically in the browser via HSTS, either via a first visit from a network where the attack hasn't taken place, or via the pre-loaded list.)

Answer 2

No. Lack of HTTPS on the home page won't prevent SSLStrip. If any of the connection is transmitted in plain text (ie HTTP), it can be sniffed, and the session could potentially be hijacked. HTTPS should be used for all pages that need to be secured, and HSTS Headers should be employed.

Answer 3

Whenever users first go to a http: page on the Web (as opposed to a local file, or a page on a local server), there is the risk that an evil HTTP proxy alter https: links to either:

• plain http: links
• https: links to another website, with a similar name (xxx-login.com instead of xxx.com)

Any bank with an http: main page that links to an https: login page does not understand security, full stop.

Explanation:

The bank should understand that providing a "secure" server (HTTPS server) is not enough, a responsible reasonable user should be end-up connecting to this server in all cases. (A user who follows links in emails is by definition unreasonable.)

A user can be expected to remember (or write down) the main domain name of his bank (one domain name), not to know every other domain his bank might use for any purpose. Add the fact that many users do not understand the hierarchical nature of the DNS, so they cannot recognise that secure-login.mybank.com is a subdomain of mybank.com but mybank.secure-login.com, mybank-secure-login.com and secure-login-mybank.com are not. They are not stupid, just ignorant of the basic principles of the DNS and not willing to learnt these technicalities. Users cannot be expected to recognise that a domain name is legitimate unless they know this exact fully qualified domain name.

The user must be guaranteed to arrive at the right place given only simple easy rules. "Negative" rules, such as "check that, stop if you detect a problem" are difficulty to apply consistently:

• the user will detect no problem as long as no attack is ongoing
• users get bored with checks that always gives the same (correct) result (they seem redundant)
• it is extremely easy to forget a negative rule, and proceed

Another problem is that in the physical world, fake objects can be recognised because they tend to be poor imitation of the real ones, and many features are security sensitive physical objects (bank notes, credit cards) are designed to be very difficult to imitate, and our intuition is trained to look at properties of object to detect imitations. When dealing with website this intuition is all wrong: the imitation of a web page looks just as good as the original - in fact, it is the original, bit of bit (and even the law carries the confusion that making illegal copies is the same thing as making an imitation).

When dealing with a fake bank (e-commerce, ISP, social...) website, only the URL (the address) will be different. The login page will look exactly the same (unless the crook is incompetent, which also happens).

Also, we have been trained to the idea that fake bank notes might exist, not fake banks.

OTOH, a "positive" rule such as "enter this URL" are impossible to forget, because if you forget it your browser (usually) doesn't go anywhere. So if one day your browser goes to a website that looks like your bank (e-commerce, ISP, social...) website, and you haven't entered the correct URL, you know something is wrong (at least extremely suspect).

So in practice, because the user is not a robot, safe recommended procedure should ideally consist only of positive rules. The browser is a robot, so he should implement all the negative rules (SSL/TLS has a bunch of negative rules).