Working on the assumption that SSL serves both to encrypt data and to provide assurance as to the identity and legitimacy of the website, should the practice of providing a logon form on a page requested over HTTP be avoided, even when it posts to HTTPS?

The question relates to a post I made yesterday about the Who's who of bad password practices and some of the feedback suggesting that not visibly seeing the certificate represented in the browser before authenticating was fine if indeed the form posted securely.

To my mind, this sells SSL short as you not only lose the ability to validate the legitimacy of the site before handing over your credentials but you also have no certainty that it is posting over HTTPS. I'm conscious the likes of Twitter and Facebook take this approach, but should they? Am I overlooking something here or is this a practice which should be discouraged?

Update: I ended up detailing the outcome of this question and subsequent discussion in the blog post SSL is not about encryption

4 Answers 4


OWASP states:

(copied verbatim from http://www.owasp.org/index.php/SSL_Best_Practices)

Secure Login Pages
There are several major considerations for securely designing a login page. The following text will address the considerations with regards to SSL.

Logins Must Post to an SSL Page This is pretty obvious. The username and password must be posted over an SSL connection. If you look at the action element of the form it should be https.

Login Landing Page Must Use SSL The actual page where the user fills out the form must be an HTTPS page. If its not, an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed.

There must be no SSL Error or Warning Messages The presence of any SSL warning message is a failure. Some of these error messages are legitimate security concerns; others desensitize the users against real security concerns since they blindly click accept. The presence of any SSL error message is unacceptable - even domain name mismatch for the www.

HTTP connections should be dropped If a user attempts to connect to the HTTP version of the login page the connection should be denied. One strategy is to automatically redirect HTTP connections to HTTPS connections. While this does get the user to the secure page there is one lingering risk. An attacker performing a man in the middle attack could intercept the HTTP redirect response and send the user to an alternate page.

To repeat: Login Landing Page Must Use SSL

  • 1
    Use HSTS to force HTTPS
    – danday74
    Commented Jan 30, 2017 at 15:33
  • 1
    @danday74 It's worth noting that the HSTS header is ignored if sent over HTTP (because an attacker could inject/remove the header at will), so you need to send them to an HTTPS page at least once, even if you use HSTS. Not to mention when/if the header expires.
    – Sinjai
    Commented Mar 1, 2019 at 16:32

It may be worth adding that there are automated tools for doing precisely what the OWASP best practices state: "an attacker could modify the page as it is sent to the user and change the form submission location..." The link includes a Black Hat presentation on the attack.

  • 1
    Do take a few hours to check the other tools and articles on this site, Moxie is really an interesting guy with great insights on SSL and security in general.
    – Shadok
    Commented Sep 7, 2011 at 13:56

To add to the answers already provided. There have been practical cases where having non-HTTPS landing pages allows for attackers to modify the site and grab users credentials. This example, is the most recent that I've seen. In this case it was done at the ISP level, but equally it could be done by wireless hotspot providers or anyone using the relevant tools to carry out a Man-In-The-Middle attack.


Technically its still secure - your browser should tell you if it doesn't like the certificate after the SSL handshake but before sending any HTTP data, however as a user, I would be very wary of a site asking me to provide authentication details before it has switched to HTTPS - without some digging around, and some knowledge of the subject, I don't know until after I've sent the information whether the place I was sending it to is secure (or where I was expecting).

Even if I trust the site, this approach can be undermined by a MITM attack no the HTTP page.

  • your answer contradicts your first sentence: that "Technically its still secure". Problem is, "secure" can mean several different things here.
    – AviD
    Commented Jan 18, 2011 at 11:08
  • 1
    But of course technically, it's only secure if the site is legitimate and hasn't been tampered with before the credentials have been entered which you can't ascertain when no cert is visible, right?
    – Troy Hunt
    Commented Jan 18, 2011 at 19:46
  • 6
    No, technically it is still insecure, at least against man-in-the-middle attacks. The page could have been modified and might be sending your password off to Timbuktu. Browser warnings are not effective at stopping such attacks. Your last sentence is correct, but your first paragraph is incorrect.
    – D.W.
    Commented Jan 19, 2011 at 7:28
  • 1
    @Troy - "secure" isn't just protecting the confidentiality of the transport, its also authentication, etc.
    – AviD
    Commented Jan 19, 2011 at 8:39

You must log in to answer this question.

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