https 和https_关于HTTPS和难题

https 和https

Eric Meyer was recently in Uganda, where he experienced first-hand a very undesirable side effect of HTTPS. The area he was in was served by satellite internet access, and experienced significant latency (a floor of 506 milliseconds) and packet loss (between 50-80% was typical). In addition, there is a cap on the data that an account can use in any given month. Go over the cap, and you either pay overages or lose data access entirely until the next billing cycle.

埃里克·迈耶(Eric Meyer)最近在乌干达 ，在那里他亲身经历了HTTPS带来的非常不利的副作用。 他所在的区域可通过卫星互联网访问，并经历了显着的延迟(最低为506毫秒)和数据包丢失(通常为50-80％)。 此外，帐户在任何给定月份可以使用的数据上限。 超过上限，您将支付超额费用或完全失去数据访问权限，直到下一个计费周期。

To counter this, the school he was visiting sets up their own local caching server. But, as he explains, this approach falls apart when HTTPS gets involved.

为了解决这个问题，他所访问的学校建立了自己的本地缓存服务器。 但是，正如他所解释的那样，当HTTPS介入时，这种方法就会瓦解。

A local caching server, meant to speed up commonly-requested sites and reduce bandwidth usage, is a “man in the middle”. HTTPS, which by design prevents man-in-the-middle attacks, utterly breaks local caching servers. So I kept waiting and waiting for remote resources, eating into that month’s data cap with every request.

本地缓存服务器是“中间人”，旨在加快常见请求的站点并减少带宽使用。 HTTPS通过设计来防止中间人攻击，从而完全破坏了本地缓存服务器。 因此，我一直在等待远程资源，每次请求都占用了该月的数据上限。

Eric acknowledged that HTTPS is a good idea (I agree) but also pointed out that these implications can’t be ignored.

Eric承认HTTPS是个好主意(我同意)，但同时指出，这些影响不容忽视。

Beyond deploying service workers and hoping those struggling to bridge the digital divide make it across, I don’t really have a solution here. I think HTTPS is probably a net positive overall, and I don’t know what we could have done better. All I know is that I saw, first-hand, the negative externality that was pushed onto people far, far away from our data centers and our thoughts.

除了部署服务人员并希望那些为弥合数字鸿沟而努力的人能够跨越，我在这里还没有真正的解决方案。 我认为HTTPS总体上可能是净积极的，我不知道我们可以做得更好。 我所知道的是，我亲眼看到了负面的外部性，这种负面性被推到了远离我们数据中心和思想的人们。

Every technology creates winners and losers. HTTPS is no exception.

每种技术都会创造赢家和输家。 HTTPS也不例外。

Many of the responses to the post were…predictable. Some folks read this as an “anti-HTTPS” post. As Brad recently pointed out, we need to get better at talking about technology “…without people assuming you’re calling that technology and the people who create/use it garbage.”

该职位的许多回复都是……可预测的。 有些人将其视为“反HTTPS”帖子。 正如布拉德(Brad) 最近指出的那样 ，我们需要在谈论技术上做得更好“……没有人会假设您在称呼该技术以及创造/使用它的人都是垃圾。”

Eric’s post is exactly the kind of reasoned, critical thinking that our industry could benefit from seeing a bit more of. HTTPS is great. It’s essential. I’m very happy that we’ve reached a point where more requests are now made over HTTPS than HTTP. It took a lot of work to get there. A lot of advocacy, and a focus on making HTTPS easier and cheaper to implement.

埃里克(Eric)的帖子正是那种理性的，批判性的思维，我们的行业可以从更多的内容中受益。 HTTPS很棒。 必不可少 我很高兴看到我们现在通过HTTPS发出的请求比HTTP发出的请求更多。 到达那里花了很多工作。 很多倡导者，并且着重于使HTTPS的实现更容易，更便宜。

But the side-effects experienced by folks like those in that school in Uganda are still unsolved. Noting this isn’t blaming the problem on HTTPS or saying HTTPS is bad, it’s admitting we have a problem that we still needs solving.

但是像乌干达那所学校的人们所经历的副作用仍未解决。 注意这并不是将问题归咎于HTTPS或说HTTPS不好，这表明我们有一个仍需要解决的问题。

I was thinking about this issue myself recently. I live in a small town and our mobile data connectivity is a bit spotty, to say the least. I use T-Mobile, which is normally excellent. In my little town, however, that’s not the case. Recently, it seems T-Mobile has partnered with someone local to provide better and faster data connections. But it’s all roaming. T-Mobile doesn’t charge for that, but it does cap your mobile data usage. After you exceed 2GB in a given month, you’re cut off. In the few months since the data has become available, it’s a number I’ve exceeded more than a few times.

我最近在想这个问题。 至少可以说，我住在一个小镇上，我们的移动数据连接有点杂乱无章。 我使用T-Mobile，通常情况下非常出色。 但是，在我的小镇上并非如此。 最近，T-Mobile似乎已经与本地人员合作，以提供更好，更快的数据连接。 但这都是漫游。 T-Mobile无需为此付费，但可以限制您的移动数据使用量。 在给定月份中超过2GB后，您将被切断。 自数据可用以来的几个月中，这个数字我已经超过了几次。

So I’ve been taking a few steps to help. One of those was to turn Chrome’s Data Saver (they’re proxy service) back on. It does a good job of cutting down data usage where it can, but it’s useless for any HTTPS site for the same reasons that school’s local caching server is useless—to do what it needs to do it needs to act as a man-in-the-middle. So while Data Saver is extremely effective when it works, it works less and less now.

因此，我一直在采取一些措施来提供帮助。 其中之一是重新打开Chrome的Data Saver(它们是代理服务)。 它可以在尽可能减少数据使用量方面做得很好，但是对于任何HTTPS站点来说，它都是无用的，其原因与学校的本地缓存服务器无用的原因相同-做它需要做的事中间。 因此，尽管Data Saver在工作时非常有效，但现在越来越少了。

It’s far from the end of the world for me, but that’s not the case for everyone. There are many folks who rely on proxy browsers and services to access the web in an affordable manner and for them, the fact that the shift to HTTPS has made those tools less effective can have real consequences.

对我来说，这还不是世界末日，但并非每个人都如此。 有很多人依靠代理浏览器和服务以可负担的方式访问Web，对于他们来说，向HTTPS转移已使这些工具的有效性降低的事实可能会带来实际的后果。

This isn’t an entirely new conversation (as my nemesis¹, Jason Grigsby, recounted on Twitter). I can personally remember bringing this up to folks involved with Chrome at conferences, online AMA’s and basically whenever else I had the opportunity. The answers always acknowledged the difficulty and importance of the solution while also admitting that what to do about it was also a bit unclear.

这不是一个全新的对话(正如我的复仇者¹ ，Jason Grigsby 在Twitter上讲述的那样 )。 我个人还记得在会议，在线AMA以及其他任何有机会的时候，将这些问题带给与Chrome相关的人员。 答案总是承认解决方案的困难性和重要性，同时也承认解决方案还不清楚。

Whether or not the topic was overlooked is up for debate (there has been work done by the IETF towards solving this), and I suppose depends entirely on which discussions you were or were not involved in over the past few years. The filter bubble effect is real and works both ways. But the reality is that in the past few years we’ve made tremendous progress getting HTTPS to be widely adopted, but we haven’t done nearly as good a job ensuring that folks have an affordable and simple alternative to the tools they’ve used in the past to access the web.

是否忽略该主题尚待辩论( IETF已为解决此问题而开展了工作)，我想这完全取决于过去几年中您参与或未参与的讨论。 滤镜气泡效果是真实的，并且可以双向起作用。 但是现实是，在过去的几年中，我们在使HTTPS广泛采用方面取得了巨大的进步，但是我们在确保人们能够负担得起的简单替代工具方面做得还差得很过去访问网络。

Should we have moved ahead with HTTPS everywhere before having a production-ready solution to ensure folks could still have affordable access? I honestly don’t know. Is a secure site you can’t access better than an insecure one you can? That’s an impossibly difficult question to answer, and if you asked it to any group of people, I’m sure a heated discussion would ensue.

在拥有可用于生产环境的解决方案以确保人们仍然可以负担得起的访问权限之前，我们是否应该在所有地方都采用HTTPS？ 老实说我不知道​​。 安全的网站比不安全的网站能更好吗？ 这是一个难以回答的问题，如果您向任何一群人问，我相信将会引起激烈的讨论。

Many of us, too, are likely the wrong people to answer that. I know I’m not the right person to pose the question to. I can afford to access the web, and I don’t have the same significant privacy concerns that many around the world and down the street do. Having the discussion is essential, but ensuring it happens with the right people is even more so.

我们许多人也可能是错误的人来回答这个问题。 我知道我不是提出这个问题的合适人选。 我负担得起访问网络的费用，而且我没有像世界各地和街上的许多人那样关注隐私。 进行讨论是必不可少的，但是确保与合适的人进行讨论更加重要。

Then there’s the question this raises about how we approach building our sites and applications today.

然后就出现了一个问题，那就是我们今天如何构建站点和应用程序。

Troy Hunt had one of the most reasoned responses to Eric’s post that I’ve seen. He pointed out that it’s critical that we move forward with HTTPS, but that this is also an essential problem to solve. He also, rightfully, pointed out the root issue: performance.

特洛伊·亨特(Troy Hunt)对我看到的埃里克(Eric)的帖子做出的最合理的回应之一。 他指出，推进HTTPS至关重要，但这也是需要解决的基本问题。 他也正确地指出了根本问题 ：性能。

If you’re concerned about audiences in low-bandwidth locations, focus on website optimisation first. The average page load is going on 3MB, follow @meyerweb’s lead and get rid of 90% of that if you want to make a real difference to everyone right now ????

如果您担心低带宽位置的受众，请首先关注网站优化。 平均页面加载量为3MB，如果您现在想对所有人产生真正的影响，请遵循@meyerweb的指导，并摆脱90％的负载????

I refer back to Paul Lewis’s unattractive pillars so often I should be paying him some sort of monthly stipend, but this is such a clear example of the reciprocal link and importance of security, accessibility, and performance.

我经常回想起保罗·刘易斯的吸引力 ，因为我经常应该每月给他一些津贴，但这是安全性，可访问性和性能相互联系和重要性的明确例子。

The folks using these local caching servers and proxy services are doing so because we’ve built a web that is too heavy and expensive for them to use otherwise. These tools, therefore, are essential. But using them poses serious privacy and security risks. They’re intentionally conducting a man-in-the-middle attack and which sounds so terribly scary because it is.

使用这些本地缓存服务器和代理服务的人们之所以这样做，是因为我们建立的网站过于繁重，对于他们而言，使用起来过于昂贵。 因此，这些工具至关重要。 但是使用它们会带来严重的隐私和安全风险。 他们故意进行中间人攻击，听起来很可怕，因为它确实如此。

To protect folks from these kinds of risks, we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many. The three pillars—security, accessibility and performance—can’t be considered in isolation. All three play a role and must be built-up in concert with each other.

为了保护人们免受此类风险的侵害，我们已采取一切措施使一切都通过HTTPS运行，从而提高了网络的安全性。 不可否认，这是至关重要的一步。 但是，这种组合(性能低下但安全性好)最终导致许多人无法访问Web。 安全，可访问性和性能这三个Struts不能孤立地考虑。 这三个角色都必须发挥作用，并且必须相互配合。

Like pretty much everyone in this discussion has acknowledged, this isn’t an easy issue to solve. Counting on improved infrastructure to resolve these performance issues is a bit optimistic in my opinion, at least if we expect it to happen anytime soon. Even improving the overall performance of the web, which sounds like the easiest solution, is harder than it first appears. Cultural changes are slow, and there are structural problems that further complicate the issue.

就像讨论中的每个人都承认的那样，这不是一个容易解决的问题。 在我看来，至少在我们希望很快发生这种情况时，依靠改进的基础架构来解决这些性能问题还是有点乐观。 听起来似乎是最简单的解决方案，但即使是提高Web的整体性能，也比最初看起来要难。 文化变革缓慢 ，存在结构性问题，使问题进一步复杂化 。

Those aren’t excuses, mind you. Each of us can and should be doing our part to make our sites as performant and bloat-free as possible. But they are an acknowledgment that there are deeply rooted issues here that need to be addressed.

注意，这些不是借口。 我们每个人都可以并且应该尽自己的一份力量，使我们的网站尽可能高效且无膨胀。 但是，他们承认这里有许多根深蒂固的问题需要解决。

There are a lot of questions this conversation has raised, and far fewer answers. This always makes me uncomfortable. I write a lot of posts that never get published because ending with unsolved questions is never particularly satisfying.

这次对话引发了很多问题，而答案却很少。 这总是让我不舒服。 我写了很多从未发表过的帖子，因为以未解决的问题结尾永远不会特别令人满意。

But I suspect that may be what we need—more open discussion and questioning. More thinking out loud. More acknowledgment that not everything we do is straightforward, that there’s much more nuance than may first appear. More critical thinking about the way we build the web. Because the problems may be hard and the answers uncertain, but the consequences are real.

但是我怀疑这可能是我们所需要的-更加公开的讨论和质疑。 大声思考。 人们更加认识到，并不是我们所做的一切都是直截了当的，而且细微之处要比最初出现的要多得多。 关于构建网络的方式的批判性思考。 因为问题可能很难解决，答案不确定，但是后果却是真实的。

翻译自: https://timkadlec.com/remembers/2018-08-14-https-and-hard-questions/

https 和https