HTTPS握手很慢。什么是改善用户体验的好方法？

Question

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

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

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

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

我了解安全连接对于验证用户帐户很重要。但是，如果这会影响用户查看公共页面的体验，我们应该尝试制定替代方案（并鼓励主要网站采用它）。

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

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

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

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

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

（我从印尼附近的某个地方写这篇文章可能不是巧合，离美国网很远！）

Answer 1

这是我能想到的一种替代方案，虽然略有限制：

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

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

但这种方法仍有问题：

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

这可以解决吗？

Answer 2

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

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

但即使成功，我们仍然不应完全信任任何用户点击或＆lt; form＆gt; POST从第一页发起。 （当然，查看其他页面的请求很好，但拒绝更新设置，密码和与财务相关的操作可能是明智之举。）

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