是否有可能通过 HTTPS 运行所有网络流量？
我正在考虑（从技术上）需要什么才能将所有网络流量转移到 HTTPS。 我认为计算机变得越来越快，因此从现在起一段时间将可以通过 HTTPS 运行所有流量，而无需任何明显的成本。
但我又想，加密强度必须不断发展以应对安全性的损失。 如果计算机速度提高 10 倍，加密强度就必须提高 10 倍，否则破解难度就会提高 10 倍。
那么，我们是否能够“免费”加密所有网络流量？
编辑：我只是询问计算与加密性能提高的逻辑。 如果我们可以在 20 年内使用相同的加密算法和密钥，它们消耗的服务器（或客户端）整体计算能力的百分比将低得多，并且实际上，这将使其“免费”加密和签名所有内容我们通过网络传输的信息。
I was considering what would it take (technologically) to move all the web traffic to HTTPS. I thought that computers are getting faster, and faster, so some time from now it will be possible to run all traffic via HTTPS without any noticeable cost.
But then again, I thought, encryption strength will have to evolve to counter the loss of security. If computers get 10x faster, encryption will have to be 10x stronger, or it will be 10x easier to break.
So, will we ever be able to encrypt all web traffic "for free"?
Edit: I'm asking only about the logic of performance increases in computing vs encryption. If we can use the same crypto algorhytms and keys in 20 years, they will consume a far lower percentage of the overall computing capacity of a server (or client), and in effect, that will make it "free" to encrypt and sign everything that we transmit over networks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
使用 HTTPS 的一大问题是它被认为是安全的，因此大多数 Web 浏览器不进行任何缓存，或者至少进行非常有限的缓存。
如果没有缓存，您会注意到 HTTPS 页面的加载速度明显慢于非加密页面。
应使用 HTTPS 来保护敏感信息。
我不知道通过 SSL 运行所有内容对 CPU 的影响。 我想说，在客户端，CPU 不是问题，因为大多数工作站大部分时间都处于空闲状态。 由于正在处理的并发请求数量巨大，因此大型程序将位于 Web 服务器端。
为了达到 SSL 基本上“免费”的目的，您必须拥有专用的加密硬件（目前已经存在）。
编辑：根据评论，问题的作者认为这就是他正在寻找的答案：
更新：我刚刚读到Google 的 SPDY 协议（旨在取代 HTTP）看起来它将在每个连接上使用 SSL。 所以，看起来谷歌认为这是可能的！
One of the big issues with using HTTPS is that its considered secure and so most web browsers don't do any caching, or at least do very limited caching.
Without the cache, you'll notice that HTTPS pages load significantly slower and a non-encrypted page would.
HTTPS should be used to protect sensitive information.
I have no idea about the CPU impact of running everything through SSL. I would say that on the client side, the CPU isn't an issue since most workstations are running idle most of the time anyway. The big program would be on the web server side due to the sheer number of concurrent requests that are being handled.
In order to get to the point that SSL is basically 'free', you'd have to have dedicated hardware for encryption (which already exists today).
EDIT: Based on the comments, the question's author suggests this is the answer he was looking for :
UPDATE: I just read that Google's SPDY protocol (designed to replace HTTP) looks like it will use SSL on every connection. So, it looks like Google thinks that it's possible!
Chris Thompson 提到了浏览器缓存，但这在浏览器中很容易修复。 将所有内容切换到 HTTPS 后无法修复的是代理缓存。 由于 HTTPS 是端到端加密的，因此透明 HTTP 代理不起作用。 在很多地方，透明代理可以加快速度（例如在 NAT 边界）。
处理因失去透明代理而产生的额外带宽可能是可行的 - 据称，与 p2p 相比，HTTP 流量无论如何都是微不足道的，因此透明代理并不是保持互联网在线的唯一方法。 它将不可避免地影响延迟，并使斜线打点比目前更糟糕。 但对于云托管来说，这两个问题都可以通过技术来处理。 当然，“安全服务器”对于云托管，甚至对于像 akamai 这样的网络内容分散形式来说，有着不同的含义。
我不认为 CPU 开销有那么大。 当然，如果您的服务器当前至少在某些时候受到 CPU 限制，那么将所有流量从 HTTP 切换到 HTTPS 将会导致服务器彻底崩溃。 一些服务器可能认为 HTTPS 不值得花费 CPU 来处理负载，并且它们会阻止每个人都采用它。 但我怀疑这将成为长期的主要障碍。 例如，谷歌已经跨越了它，并愉快地以 https 方式提供应用程序（尽管不是搜索），无需大惊小怪。 服务器为每个连接执行的工作越多，通过 SSL 保护该连接所需的额外工作就越少。 SSL 可以并且在必要时进行硬件加速。
还有管理/经济问题，HTTPS 依赖于受信任的 CA，而受信任的 CA 需要花钱。 除了 SSL 实际使用的方法之外，还有其他设计 PKI 的方法，但 SSL 的工作原理是有原因的。 例如，SSH 让用户有责任通过安全侧通道从服务器获取密钥指纹，并且 这就是结果：一些用户认为其安全目的并不能证明这种程度的不便是合理的。 如果用户不想要安全性，那么他们就不会得到安全性，除非他们无法避免。
如果用户只是自动单击“接受”不受信任的 SSL 证书，那么您可能还不如没有它，因为如今中间人攻击并不比普通窃听困难得多。 因此，再次强调，有大量服务器对支付（工作）HTTPS 不感兴趣。
Chris Thompson mentions browser caching, but that's easily fixable in the browser. What isn't fixable on switching everything to HTTPS is proxy caching. Because HTTPS is encrypted end-to-end, transparent HTTP proxies don't work. There are a lot of places where transparent proxying can speed things up (for instance at NAT boundaries).
Dealing with the additional bandwidth from losing transparent proxying is probably doable - allegedly HTTP traffic is trivial compared with p2p anyway, so it's not as if transparent proxies are the only thing keeping the internet online. It will hit latency irrevocably, and make a slashdotting even worse than it is currently. But then with cloud hosting, both those might be dealt with by tech. Of course "secure server" takes on a different meaning with cloud hosting, or even with other forms of de-centralisation of content across the network like akamai.
I don't think the CPU overhead is that significant. Sure, if your server is currently CPU bound at least some of the time, then switching all traffic from HTTP to HTTPS will kill it stone dead. Some servers may decide that HTTPS is not worth the monetary cost of a CPU that can handle the load, and they will prevent literally everyone adopting it. But I doubt it will be a major barrier for long. For instance, Google has crossed it already and happily serves apps (although not searches) as https without fuss. And the more work servers are doing per connection, the less proportional extra work is required to SSL-secure that connection. SSL can be and is hardware accelerated where necessary.
There's also the management/economic problem that HTTPS relies on trusted CAs, and trusted CAs cost money. There are other ways to design a PKI than the one SSL actually uses, but there are reasons SSL works how it does. For example SSH places the responsibility on the user to obtain a key fingerprint from the server by a secure side-channel, and this is the result: some users don't think that level of inconvenience is justified by its security purpose. If users don't want security, then they won't get it unless it's impossible for them to avoid it.
If users just auto-click "accept" for untrusted SSL certificates, then you pretty much might as well not have it, since these days a man-in-the-middle attack is not significantly more difficult than plain eavesdropping. So, again, there's a significant block of servers which just aren't interesting in paying for (working) HTTPS.
现在的成本已经没有那么高了。
另外……拥有一台速度快 10 倍的计算机决不会需要更改加密。 AES（SSL 的一种常见加密技术）足够强大，需要很长时间才能破解。
The cost isn't that great nowadays.
Also...having a computer that is 10x faster will in no way make it necessary to change encryption. AES (a common encryption for SSL) is strong enough that it would take a very very long time to break.
有可能吗？ 是的
这是可取的吗？ 不，
有几个原因。
Will it be possible? YES
Will it be advisable? NO
For a few reasons.
IMO，答案是否定的。 这样做的主要原因是，如果您考虑有多少页面包含来自多个来源的项目，每个页面都必须使用 https 并拥有有效的证书，我认为这不适用于一些必须更改所有内容的大公司他们的链接。
这不是一个坏主意，也许某些 Web x.0 默认情况下会有更安全的通信，但我不认为 http 会成为该协议。
仅举几个例子，尽管我来自加拿大，但这可能会影响这些网站的呈现方式：
www.msn.com :
www.cnn.com :
这些是通过“NoScript”列出的，其中指出该页面除了 stackoverflow.com 之外还有来自“google-analytics.com”和“quantserve.com”的代码作为第三个示例。
IMO, the answer is no. The main reason for this is that if you consider how many pages have items from multiple sources that would each have to use https and have a valid certificate that I don't think would work for some of the big companies that would have to change all their links.
It isn't a bad idea and maybe some Web x.0 would have more secure communications by default, but I don't think http will be that protocol.
Just to give a couple of examples, though I am from Canada which may affect how these sites render:
www.msn.com :
www.cnn.com :
Those were listed through "NoScript" which notes this page has code from "google-analytics.com" and "quantserve.com" besides the stackoverflow.com for a third example of this.
与 https 的主要区别在于，会话将保持打开状态，直到您将其关闭。 使用会话 cookie 可以节省很多麻烦，但会增加服务器的负载。
在您发送查询后，Google 应将 https 会话与您保持活动状态多久？
您想要与每个弹出广告保持持久连接吗？
A major difference with https is that a session is kept open until you close it. Saves a lot of hassle with session cookies but puts a load on the server.
How long should google keep the https session with you alive after you send a query?
Do you want a persistent connection to every popup ad?