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 ?


3 Answers 3


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.)

  • 1
    If a website has any HTTP page (except a redirect) then the user might bookmark the HTTP page. "Answering yes to these 3 questions is required for HTTPS to be used correctly." the problem is that the user may check this a few times, but not every single time. Another problem is that the domain is sometimes not in same the domain as the one the user went to, and not a domain he knows (bankofamerica-secure-login.com vs bankofamerica.com). Yet another issue is common looking names (bankofamerica.com vs bankofamerica.us vs bank-of-america.us). For this reason, go directly to the HTTPS site.
    – curiousguy
    Commented Jun 20, 2012 at 0:04
  • @curiousguy Users just have to check where they go to every time. Of course, bookmarking the HTTPS URL is the right thing to do indeed, but they need to bookmark the right one the first time. Users also have to know what domain name to expect in the first place, even when using HTTPS initially. EV certs are meant to help with this, but some banks manage to get this wrong... (see Natwest example in this answer, although I don't know if they advertise their other domain name in their brochures).
    – Bruno
    Commented Jun 20, 2012 at 0:15
  • 2
    How many users can explain the difference between bankofamerica-secure-login.com, bankofamerica.secure-login.com and secure-login.bankofamerica.com? My bet: most Internet users don't know and don't care. They probably wouldn't pay attention if I was trying to explain that. They want a simple advice that simply works. Mine is: go directly to the correct HTTPS website, bookmark it, then use your bookmark or equivalent feature (like the interactive history in modern browsers). Do not use a link on any other media, including other websites, include the bank's HTTP website, including any email.
    – curiousguy
    Commented Jun 20, 2012 at 2:29

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.

  • "Lack of HTTPS on the home page won't prevent SSLStrip" ?
    – curiousguy
    Commented Jun 19, 2012 at 20:47
  • @curiousguy I meant that in response to the question title: "...secure against sslstrip if it doesn't use ssl on homepage but ssl everywhere else?" Commented Jun 19, 2012 at 21:07
  • 1
    Do you actually mean "Lack of HTTPS on the home page makes it vulnerable to SSLStrip"?
    – curiousguy
    Commented Jun 19, 2012 at 23:49
  • @curiousguy - You are saying exactly the same thing.
    – Ramhound
    Commented Jun 20, 2012 at 10:52
  • 1
    @Ramhound Not really. Eating oranges does not prevent one getting hit by a bus. Does that mean it makes one more vulnerable to it? Commented Jun 20, 2012 at 13:24

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 (example-login.com instead of example.com)

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


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).

  • -1 because of "does not understand security". It's too broad and can be said about any vulnerability. I wanted to make it an edit but you rejected it. Also OP said ecommerce, not bank. Also see Bruno's answer. Commented Jun 19, 2012 at 21:26
  • @AndreyBotalov I stand by what I wrote. I rejected your edit because I really mean it. Your downvote is not logical.
    – curiousguy
    Commented Jun 19, 2012 at 23:47
  • By eCommerce I also mean Bank. @CuriousGuy could you detail what the bank does not understand ? Thanks.
    – user310291
    Commented Jun 20, 2012 at 5:57
  • @user310291 I have edited my answer.
    – curiousguy
    Commented Jun 20, 2012 at 17:24
  • 1
    Thanks @Curiousguy I gave you positive vote I'm sorry others have given negative. I wish they would remove because I'm pleased by the answer.
    – user310291
    Commented Jun 20, 2012 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .