假设 SSL 既可以加密数据，又可以保证网站的身份和合法性，是否应该避免在通过 HTTP 请求的页面上提供登录表单的做法，即使它发布到 HTTPS 也是如此？
这个问题与我昨天发表的一篇关于密码不良做法的名人的帖子有关，以及一些反馈表明，如果确实安全地发布了表单，那么在进行身份验证之前看不到浏览器中表示的证书就可以了。
在我看来，这会使 SSL 卖空，因为您不仅无法在交出您的凭据之前验证网站的合法性，而且您也无法确定它是通过 HTTPS 发布的。我知道 Twitter 和 Facebook 之类的公司采用这种方法，但他们应该这样做吗？我是否在这里忽略了某些东西，或者这是一种应该不鼓励的做法？
更新：我最终在博客文章SSL 与加密无关，详细说明了这个问题的结果和后续讨论
OWASP 指出：
（从http://www.owasp.org/index.php/SSL_Best_Practices逐字复制）
安全登录页面
安全地设计登录页面有几个主要考虑因素。以下文本将讨论有关 SSL 的注意事项。登录必须发布到 SSL 页面 这很明显。用户名和密码必须通过 SSL 连接发布。如果您查看表单的 action 元素，它应该是 https。
登录登陆页面必须使用 SSL 用户填写表单的实际页面必须是 HTTPS 页面。如果不是，攻击者可以在页面发送给用户时对其进行修改，并更改表单提交位置或插入 JavaScript，从而在键入时窃取用户名/密码。
必须没有 SSL 错误或警告消息 任何 SSL 警告消息的存在都是失败的。其中一些错误消息是合法的安全问题；其他人使用户对真正的安全问题不敏感，因为他们盲目地点击接受。任何 SSL 错误消息的存在都是不可接受的 - 甚至 www 的域名不匹配。
应丢弃 HTTP 连接 如果用户尝试连接到登录页面的 HTTP 版本，则应拒绝连接。一种策略是自动将 HTTP 连接重定向到 HTTPS 连接。虽然这确实让用户进入安全页面，但仍有一个挥之不去的风险。执行中间人攻击的攻击者可以拦截 HTTP 重定向响应并将用户发送到备用页面。
重复一遍： 登录登陆页面必须使用 SSL
值得补充的是，有一些自动化工具可以精确地执行 OWASP 最佳实践所述的操作：“攻击者可以在页面发送给用户时修改页面并更改表单提交位置......”该链接包括一个黑帽关于攻击的介绍。
添加到已经提供的答案。在实际案例中，非 HTTPS 登录页面允许攻击者修改站点并获取用户凭据。 这个例子，是我见过的最新的。在这种情况下，它是在 ISP 级别完成的，但同样可以由无线热点提供商或任何使用相关工具执行中间人攻击的任何人完成。
从技术上讲，它仍然是安全的——你的浏览器应该在 SSL 握手之后但在发送任何 HTTP 数据之前告诉你它是否不喜欢证书，但是作为用户，我会非常警惕一个网站要求我在它之前提供身份验证详细信息已切换到 HTTPS - 没有一些挖掘，也没有对该主题的一些知识，直到我发送信息后我才知道我发送它的地方是否安全（或我期望的地方）。
即使我信任该站点，这种方法也可能会受到 MITM 攻击而不是 HTTP 页面的破坏。