Is posting from HTTP to HTTPS a bad practice?

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.