security - HTTPS 握手很慢。有什么好的选择来改善用户体验？

Question

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

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

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

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

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

这是一个可能的解决方法(1):

允许用户与我们的网站建立 HTTP 连接，这样我们就可以快速呈现页面而无需 SSL 握手。

允许在页面加载后进行登录。也许是 Ajax 请求超过 HTTPS 可以对用户进行身份验证，并为页面提供相关更新。 (这从根本上是不安全的吗？编辑:是的，它并不完全安全，请参见下面的答案。)

另一种选择可能是(2):

不是通过 HTTPS 的长期 cookie，而是通过 HTTP 组合使用长期的一次性 key cookie 进行持久登录，并使用短期 cookie 进行非线性浏览。经常更换它们。 (这可能不如 HTTPS 安全，但比 HTTP 上的正常长期 cookie 使用更安全。)

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

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

Answer 1

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

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

但是即使成功了，我们仍然不应该完全信任来自第一页的任何用户点击或

POST。 (当然，查看其他页面的请求很好，但拒绝对设置、密码和财务相关操作的更新可能是明智的。)

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