HTTPS 握手很慢。有啥好的选择来改善用户体验？

Posted 2023-02-19

【中文标题】HTTPS 握手很慢。有啥好的选择来改善用户体验？

【英文标题】：HTTPS handshakes are slow. What is a good alternative, to improve the user experience?HTTPS 握手很慢。有什么好的选择来改善用户体验？

【发布时间】：2013-10-31 16:27:34

【问题描述】：

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

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

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

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

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

这是一种可能的解决方法 (1)：

允许用户与我们的网站建立 HTTP 连接，因此我们可以快速呈现页面，而无需 SSL 握手。 允许在页面加载后登录。也许通过

HTTPS

的

Ajax

请求可以验证用户身份，并为页面提供相关更新。 （这从根本上是不安全的吗？编辑：是的，它并不完全安全，请参阅下面的答案。）

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

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

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

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

【问题讨论】：

ssl 不是“慢”。它与传输的非 SSL 连接一样快。它确实有很大的启动开销，但是一旦连接开始，差别就很小了。允许 http keep-alives 使连接/重新连接开销最小化。

你使用什么编程语言？如果它是 Java - 请查看 websockets：docs.oracle.com/javaee/7/tutorial/doc/websocket.htm btw，SSL 仅在交换密钥的第一部分很慢，之后加密/解密部分使用非常类似于 3DES

的算法运行得非常快

困扰我的是握手，所以我更新了问题。这似乎是一个小问题，直到您每天经历 20 次！ Keep-Alive 肯定会有所帮助，但在某些时候，用户需要再次握手，可能是到他一个小时前才访问过的网站。我认为这是一个网络问题，因此与语言无关。

一种可能的解决方案就在我们眼前！ *** 本身使用 HTTPS 进行登录，然后使用短暂的 HTTP cookie 进行会话。然而，当涉及金融交易时，这可能被认为不够安全，例如在电子商务网站上。 ***.com/questions/709085/…

***.com/questions/733564/…

【参考方案1】：

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

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

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

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

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

【参考方案2】：

这是我能想到的另一种选择，虽然有点限制：

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

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

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

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

这可以解决吗？

【讨论】：

使用登录按钮切换到 https 使 https 完全无用，因为带有登录按钮的页面可以很容易地更改，从而启用中间人。如果您想以 http 方式提供非登录服务，则需要将登录区域作为单独的页面，通过 https 提供服务。有关更多详细信息，请参阅Troy Hunt 的这篇文章。

是的，我同意必须在 https 页面上提供登录详细信息。我将在我的答案中将“按钮”重命名为“链接”。这个额外的页面加载对用户来说有点不方便，尽管登录页面可能能够恢复持久登录......如果安全 cookie 没有被擦除！