由于这里的大多数其他答案都涉及站点范围 SSL 的缺点（主要是性能问题 - 顺便说一句，这些可以通过将 SSL 终止卸载到 SSL 代理盒或 SSL 卡来轻松缓解），我会指出只有通过 SSL 的登录页面，然后切换到非 SSL 的一些问题：

• 站点的其余部分不安全（虽然这很明显，但有时过于关注用户的密码）。
• 用户的会话 id 必须以明文形式传输，允许其被拦截和使用，从而使坏人能够冒充您的用户。（这主要是Firesheep喧嚣的内容）。
• 由于上一点，您的会话 cookie 无法使用该secure属性进行标记，这意味着可以通过其他方式检索它们。
• 我见过只有登录 SSL 的网站，当然忽略了忘记密码页面、更改密码页面，甚至注册页面......
• 从 SSL 切换到非 SSL 通常很复杂，可能需要在您的网络服务器上进行复杂的配置，并且在许多情况下会为您的用户弹出一条可怕的消息。
• 如果它只是登录页面，并且有一个从您的网站主页指向登录页面的链接 - 什么是保证有人不会欺骗/修改/拦截您的主页，并让它指向不同的登录页面？
• 然后是登录页面本身不是 SSL，而只有SUBMIT是的情况——因为这是唯一一次发送密码，所以应该是安全的，对吧？但实际上，这使用户无法提前确保将密码发送到正确的站点，直到为时已晚。（例如美国银行等）。

“服务器开销”作为一个重要的“骗局”而增加是一个常见的神话。谷歌工程师指出，当将 gmail 切换到 100% SSL 时，他们没有部署额外的硬件，而且 SSL 只增加了不到 1% 的 CPU 负载和 2% 的网络流量。Stack Overflow 也有几个问题可以解决这个问题：SSL 会带来多少开销？以及HTTP 与 HTTPS 的性能。

来自 zscaler 博客条目为什么网络还没有切换到仅 SSL？

“随着 Firesheep 再次强调 session-sidejacking 问题，很多人问我为什么更多的网站，或者至少是主要参与者（谷歌、Facebook、亚马逊等）没有默认为所有通信启用 SSL。确实, 加密是确保用户会话在开放的无线网络上不能被轻易嗅探的唯一方法。

这听起来很简单 - 只需在 URL 中的 http 后添加一个 s！其实没那么容易。以下是一些挑战。”

挑战总结（缺点）：

• “服务器开销”
• “增加延迟”
• “CDN 挑战”
• “通配符证书是不够的”
• “混合 HTTP/HTTPS：先有鸡还是先有蛋的问题”
• “警告很可怕！”

Ars Technica 有一篇优秀的文章解释了在站点范围内部署 SSL 的一些挑战。

一大特点：大多数广告网络不提供通过 SSL 投放广告的任何方式。此外，如果您在通过 HTTPS 交付的主页中嵌入广告（通过 HTTP 交付），浏览器将发出可怕的混合内容警告，您不想让用户受到这些警告。因此，受广告支持的网站可能会发现很难在整个网站范围内过渡到 SSL。

文章还概述了其他一些挑战，例如第三方小部件、分析、嵌入式视频等。