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 ?
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:
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.
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
(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.)
Whenever users first go to a
Any bank with an
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:
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).
|show 1 more comment|
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.