4

HTTPS 启动速度很慢，尤其是在低带宽和高延迟的连接上，或者在低规格的机器上。不幸的是，这似乎是所有主要网站使用的保护登录的标准方法。

但是我们通常访问的很多网站只是为了阅读信息。如果我们只是偶尔想要进行写入/更新，那么等待登录是不必要的时间开销。

对我来说最令人沮丧的例子是：

  • GitHub。我经常想访问一个 github 页面，只是为了阅读项目的概述或查看文件。但我必须等待 SSL 握手，即使我不想做任何与我的个人帐户相关的事情。Github 总是将我的浏览器从 HTTP 重定向到 HTTPS。为什么？！

我了解安全连接对于验证用户帐户非常重要。但是，当这影响了简单查看公共页面的用户体验时，我们应该尝试找出替代方案（并鼓励主要网站采用它）。

这是一个可能的解决方法（1）：

  • 允许用户与我们的网站建立 HTTP 连接，这样我们就可以快速呈现页面而无需 SSL 握手。
  • 允许在页面加载后进行登录。也许通过HTTPS的Ajax请求可以验证用户身份，并为页面提供相关更新。（这从根本上是不安全的吗？编辑：是的，它并不完全安全，请参见下面的答案。）

另一种选择可能是（2）：

  • 代替通过 HTTPS 的长期 cookie，使用长期一次性密钥 cookie 的组合用于持久登录，以及通过 HTTP 用于非线性浏览的短期 cookie。经常更换它们。（这可能不如 HTTPS 安全，但比 HTTP 上的正常长期 cookie 使用更安全。）

这些解决方案看起来是否足够安全，或者您能提出更好的建议吗？

（我在印度尼西亚附近的某个地方写这篇文章可能不是巧合，那里离美国网络很远！）

4

2 回答 2

0

这是我能想到的另一种选择，尽管有一些限制：

  • 允许通过 HTTP 浏览公共页面，但不执行任何用户登录。这避免了所有安全问题。
  • 然后，“登录”链接会将我们发送到 HTTPS 页面，并且可能能够从长期存在的 HTTPS cookie 中自动恢复用户的帐户。
  • 为不受握手开销困扰并希望始终登录的用户提供“始终通过 HTTPS 登录”选项。请注意，需要在 HTTP 域上设置此设置的 cookie，因为它需要在没有用户登录的情况下工作！

实际上，我们可能会提供相反的情况：默认自动重定向到 HTTPS 的现有流行行为，但为希望避免 SSL 握手的用户提供“不要总是切换到 HTTPS 登录”的选择退出。

但是这种方法仍然存在问题：

不幸的是，cookie 没有命名为协议 (http/https)。我们可以将 cookie 标记为“安全”以防止它们通过 HTTP 发送，但如果确实发生 HTTP 请求，某些浏览器会完全清除它们。将 cookie 分开的一种方法是使用不同的域来对站点进行未经身份验证和经过身份验证的访问。但后来我们发现自己违反了 REST，两个不同的地址指向本质上相同的资源......

这可以解决吗？

于 2013-10-23T06:34:23.707 回答
0

问题中的解决方法#1 无法为第一页提供完全的安全性，因为中间人攻击可能在登录发生之前在页面上注入或修改了脚本。

因此，我们不应该在 HTTP 页面上要求用户名/密码。但是，HTTPS Ajax 操作可能能够通知用户持久登录会话已经/可以恢复。（然后脚本可以用 HTTPS 链接替换页面上的所有 HTTP 链接。）

但是即使成功了，我们仍然不应该完全信任来自第一页的任何用户点击或 <form> POST。（当然，查看其他页面的请求很好，但拒绝对设置、密码和财务相关操作的更新可能是明智的。）

这种技术至少可以作为一种在后台执行 HTTPS 设置的方法，而无需让用户等待初始内容。（StackOverflow 使用类似这个过程的东西。）希望浏览器缓存 HTTPS 连接，或者至少缓存 keys，避免后续请求的任何延迟。

于 2013-10-28T08:43:13.410 回答