执法 (Enforcement)

A similar thing applies to the enforcement of rules. For instance in order to ride a subway you need a ticket. There are two ways in which this can be policed: you have gates that prevent people without a ticket from passing onto the platform or you instead make spot checks. The engineer in me would obviously argue for the gates as it’s a technical solution to a problem but upon closer inspection the gates might actually have a bunch of unintended downsides. The gate is a very binary access method: you either get through or you don’t based on if you have a valid ticket. It however leaves out a perfectly reasonable affordance which is the idea of riding the train without paying for it. Now obviously one could argue that the whole point of the gate is to prevent this from happening but there are plenty of situations in which it would be entirely legitimate to ride the train without a ticket. A good example for that are emergencies. You cannot really talk to a ticket gate and make your point, it’s a soul-less thing.

类似的情况适用于规则的执行。 例如，要乘坐地铁，您需要买票。 可以通过两种方法对此进行监管：您可以使用登机口阻止没有票的人进入平台，或者进行抽查。 我内部的工程师显然会建议使用闸门，因为这是解决问题的技术方法，但仔细检查，闸门实际上可能会有很多意外的缺点。 登机口是一种非常二进制的访问方法：您通过还是不通过，是否有有效的票证。 但是，它却留下了一个完全合理的负担能力，那就是不用付钱就坐火车的想法。 现在显然有人可以辩称，登机口的全部目的是为了防止这种情况的发生，但是在很多情况下，完全不用火车票就可以乘火车。 紧急情况就是一个很好的例子。 您无法真正与检票口交谈并阐明自己的观点，这是一件没有灵魂的事情。

This is less of an issue for public transportation but it would become a bigger one for cars but cars do not (yet?) enforce laws themselves. There are plenty of people that are not legally allowed to drive a car under normal circumstances but should not be prevented from driving a car in emergency situations.

对于公共交通而言，这不是一个大问题，但是对于汽车来说，这将成为一个更大的问题，但汽车本身（尚未？）并没有执行法律。 在正常情况下，有很多人在法律上不允许开车，但是在紧急情况下，不应阻止很多人开车。

I’m not going to discuss whether digital enforcement is a good thing or not, more that when you take such a strong stance on an issue it’s important to not just consider the situations in which everything goes by design.

我不会讨论数字执法是否是一件好事，更多的是，当您在一个问题上采取如此坚定的立场时，重要的是不要仅仅考虑一切都是设计使然的情况。

Which leads me to the concept of encrypting everything. There is the idea that “there is no such thing as insensitive web traffic” and that the privacy of communication is absolute. For a long time this was not a very contested idea because the total number of encrypted traffic was quite a small percentage of the overall communications. Now however pretty much everyone wants to have their website encrypted which starts to alarm many actors including governments and system administrators.

这使我想到了加密所有内容的概念。 有一种想法是“没有不敏感的网络流量”，并且通信的隐私是绝对的。 长期以来，这并不是一个非常有争议的想法，因为加密流量的总数仅占总体通信的很小一部分。 现在，几乎每个人都希望对其网站进行加密，这开始使包括政府和系统管理员在内的许多参与者感到震惊。

Traditionally many institutions and professions and their customers had legitimate reasons for why they want encryption. That includes banks and lawyers for instance. But not everybody is entitled to privacy in all situations. For instance convicted criminals are not. Likewise many lawful professions need to be heavily surveyed for security. That privacy and safety stand in a big conflict was recently quite dramatically demonstrated when a pilot hid his psychological problems from his employer and intentionally caused a plane to crash.

传统上，许多机构和专业以及他们的客户都有他们为什么要加密的正当理由。 例如，这包括银行和律师。 但是，并非所有人都在所有情况下都享有隐私权。 例如，定罪的罪犯不是。 同样，许多合法职业也需要接受大量安全检查。 当飞行员向雇主隐瞒自己的心理问题并故意导致飞机坠毁时，隐私和安全处于巨大冲突中，这一点最近得到了极大的证明。

However encryption is like a ticket gate in the sense, that there is no way around it. For nobody (if it works). This has a lot consequences I think we did not yet discuss as a society.

但是，从某种意义上讲，加密就像是检票口，无法绕开它。 对于任何人（如果可行）。 我认为这对于我们作为一个社会还没有讨论很多后果。

加密成本 (The Cost of Encryption)

When implemented properly, encryption is a very binary enforcement: there is no way around it. It’s something that we as developers like very much because it just “makes sense” to us. But it does not come for free.

如果正确实施，则加密是一种非常二进制的强制措施：它无法解决。 作为开发人员，我们非常喜欢这件事，因为它对我们“有意义”。 但是它不是免费的。

First of all encryption cannot stand on its own, it needs the concept of trust. The most common form of encryption these days is SSL where the user does not really have much of a choice in defining trust. The trust there is acquired by giving someone at a specific (private!) institution money and a copy of a passport. This system does not scale, and the number of SSL hosts is exploding. Now that everybody and their dog uses SSL on their blogs the total stress put on this system is even larger than in the past and as such slip-ups are only going to increase. It was bad enough to secure the CA system for a few hundred hosts that needed SSL, but now I have no idea how any CA in the world is supposed to verify people’s identities. It’s also making the encryption icon more and more meaningless and puts more and more emphasis on who and for whom things are signed.

首先，加密不能独立存在，它需要信任的概念。 如今，最常见的加密形式是SSL，在这种情况下，用户在定义信任方面确实没有太多选择。 通过给特定（私人！）机构的人钱和护照副本，可以获得那里的信任。 该系统无法扩展，并且SSL主机数量激增。 现在，每个人和他们的狗都在其博客上使用SSL，该系统所承受的总压力甚至比过去更大，并且这种失误只会增加。 为数百个需要SSL的主机保护CA系统已经很糟糕了，但是现在我不知道世界上的任何CA应该如何验证人们的身份。 这也使加密图标变得越来越没有意义，并且越来越强调谁和谁签名了东西。

There is another cost and that’s the actual cost in CPU cycles. SSL is bloody expensive compared to not doing it. First of all there are still services which do not support SNI, so SSL is a big factor in exhausting the IPv4 address space faster than we would otherwise need. As an alternative you can fall back to many subject alternative names on your certificate. This is being executed to ludicrous degrees due to our instance on the use of SSL. The frontend that does SSL offloading for firebase.com for instance currently lists more than 580 subject alternative names. Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user. The certificate in front of “firebase” is also good for “tappinass”. Sure enough, neither firebase nor that other website are holding the private keys to the cert, so they cannot impersonate each other, but their CDN provider can. Don’t get me wrong, there is nothing wrong with that because they chose to outsource this to their CDN, but from a user’s perspective this sort of SSL deployment does not actually guarantee that the communication is secure from their side until they hit the intended server.

还有另一个成本，那就是CPU周期中的实际成本。 与不使用SSL相比，SSL昂贵。 首先，仍然存在不支持SNI的服务，因此SSL是比我们原本需要的速度快耗尽IPv4地址空间的重要因素。 作为替代方案，您可以使用证书上的许多主题替代名称。 由于我们使用SSL的实例，执行此操作的程度非常可笑。 例如，为firebase.com进行SSL卸载的前端当前列出了580多个主题备用名称。 这不仅意味着您正在下载一个很大的证书，而且SSL加密对于您作为用户来说也是一个谎言。 “ firebase”前面的证书也适合“ tappinass”。 可以肯定的是，firebase和其他网站都没有持有证书的私钥，因此它们不能互相模仿，但其CDN提供程序可以。 不要误会我的意思，这没有什么错，因为他们选择将其外包给他们的CDN，但是从用户的角度来看，这种SSL部署实际上并不能保证从他们那一侧进行的通信是安全的，直到他们击中了预期的目标。服务器。

SSL scales really badly intentionally. Until fairly recently there was no real way to scale SSL without handing over your private keys to a your frontend SSL machines. (Cloudflare outline their Keyless SSL method here). The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that. Not everything needs encryption. Especially in cases of big emergencies, being able to access information is crucial. The first thing Germanwings did after their horrific crash when their website was down was to replace it with a static HTML page (unencrypted) with a phone number you could call if you were affected.

SSL确实有意扩展。 直到最近，还没有一种真正的方法来扩展SSL，而无需将私钥移交给前端SSL机器。 （Cloudflare在此概述了其无密钥SSL方法 ）。 部署SSL的成本不应该被低估，强迫SSL脱离人们的思维应该考虑到这一点。 并非所有内容都需要加密。 特别是在紧急情况下，访问信息至关重要。 在网站崩溃后，Germanwings遭受可怕的崩溃后的第一件事就是用一个静态HTML页面（未加密）替换为您可以拨打的电话号码（如果您受到了影响）。

政府拦截 (Government Interception)

A big cost of encryption however is lawful interception. This is not the place to discuss if governments should have the ability to intercept your internet traffic or not but in many cases they have that right. So given a government that is allowed to rule a website illegal there are two ways to get the website offline. One involves going to the hosting provider of that website and tell them to shut it down. This can be very tricky because the website is typically hosted in another country. The second method is to go to the local ISP and tell them to disable access to it. The rather is the better option in the sense that it only affects the citizens of that country and it isolates the problem.

但是，加密的一大成本是合法的拦截。 这里不是讨论政府是否应有能力拦截您的互联网流量的地方，但在许多情况下，它们拥有这项权利。 因此，鉴于允许政府将网站定为非法的政府，有两种方法可以使网站离线。 其中一个涉及到该网站的托管提供商，并告诉他们将其关闭。 这可能非常棘手，因为该网站通常位于另一个国家/地区。 第二种方法是转到本地ISP，并告诉他们禁用对其的访问。 从某种意义上说，宁愿是更好的选择，因为它只会影响那个国家的公民，并且可以隔离问题。

Unfortunately, SSL prevents this. Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic. For Russians for instance github was down for more than a day because ISPs had no other change than taking the whole website down until github changed their servers to blacklist the content in question for Russian IPs.

不幸的是，SSL阻止了这种情况。 不幸的是，因为这意味着如果一个网站托管了部分非法共享内容，则整个网站都将关闭，而不仅仅是法律上有问题的子集。 例如，对于俄罗斯人来说，github宕机了一天多，因为ISP除了关闭整个网站之前没有其他改变，直到github更改其服务器以将有关俄罗斯IP的内容列入黑名单。

These problems will not become less but more and it will require a proper discussion within the legal bodies of our countries. We as the tech community should not make this decision on our countries’ behalf. It should be a technical reason and not a political one.

这些问题不会越来越少，而只会越来越多，需要我们各国的法律机构进行适当的讨论。 作为科技界，我们不应代表我们的国家做出此决定。 这应该是技术原因，而不是政治原因。

强迫中间人 (Forcing The Man in the Middle)

The more we put our money behind encryption the more will we put the problem of active man in the middling on our radar. When a couple of years ago you could get away with pinning SSL certificates in your Windows desktop apps, we are now far away from that. A shocking amount of Windows users run software that MITMs SSL connections to scan for viruses, malware etc. Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary.

我们在加密上投入的资金越多，我们就越会把活跃的人问题放在我们的雷达中。 几年前，当您可以在Windows桌面应用程序中固定SSL证书时，我们就可以摆脱了。 令人震惊的Windows用户运行的软件都使用MITM的SSL连接来扫描病毒，恶意软件等。甚至广告提供商（Superfish咳嗽）也开始破坏SSL流量，因为它变得非常普遍，以至于必须这样做。

I’m firmly of the opinion that none of that would have happened if SSL traffic was less common. From an economical perspective a few years ago nobody would have thought about building a SSL MITM proxy for these purposes. Now however you will find them everywhere. Even reputable companies like Nokia have been found intercepting SSL traffic on their mobile phones.

我坚信，如果SSL流量不那么普遍，那一切都不会发生。 从经济角度考虑，几年前没有人考虑过为此目的构建SSL MITM代理。 但是现在您到处都可以找到它们。 甚至发现像诺基亚这样的知名公司，也都在其手机上拦截SSL流量。

Worst of all is that “SSL everywhere” goes against what it should actually protect as a side effect. There are probably more misconfigured SSL systems that give users the illusion of safety than correctly set up ones. There will be the point in a year or two when the first websites that got forgotten and had SSL configured, will have their certificates expire. And then users will start to get used to clicking certificate warnings away because it’s the only way to get to the website they needed.

最糟糕的是，“无处不在的SSL”与它实际上应保护的副作用背道而驰。 错误配置的SSL系统可能比正确设置的SSL系统给用户带来安全感。 一两年后，第一个被遗忘并配置了SSL的网站的证书将过期。 然后，用户将开始习惯于单击证书警告，因为这是访问所需网站的唯一方法。

复杂性 (The Complexity)

The greatest impact on user’s safety would have been the development of per user encryption for public Wifi access points. Instead what happened is that now every larger website has to implement SSL to protect against the only realistic attack vector which is someone surfing at Starbucks.

对用户安全的最大影响将是为公共Wifi接入点开发每用户加密。 取而代之的是，现在每个大型网站都必须实施SSL，以防御唯一现实的攻击媒介，即有人在星巴克网上冲浪。

But instead we fixed the problem on every single website out there instead of one Wifi standard [1]. But administrators largely don’t understand SSL. And I can’t blame them. Right now the total number of people in the world that probably understand the entirety of SSL are most likely in the low hundreds. I have been dealing with SSL for years now and the more I use it, the more I have to surrender to the complexities in it. When a few years ago I would have said “I understand SSL” I now no longer claim I have any understanding of SSL at all.

但是，相反，我们在每个网站上都解决了这个问题，而不是一个Wifi标准[1] 。 但是管理员在很大程度上不了解SSL。 我不能怪他们。 目前，世界上可能了解SSL整体的人数很可能只有几百个。 我已经使用SSL多年了，使用SSL越多，我就越需要屈服于SSL的复杂性。 几年前，我会说“我了解SSL”，而现在我不再声称对SSL有任何了解。

This is a problem. Because SSL at this point is becoming more and more of a requirement it means there is a crucial part of my stack which I have to fully trust. And it’s written in a way where it’s impossible for a normal human being to understand the internals of it. Cryptography is black magic. One can argue that for as long as SSL engines are Open Source there should be plenty of eyes that ensure that our crypto code is secure, but the truth is that the most popular cryptography library (OpenSSL) is an old and complex mess. Even if the library itself would be okay, there are so many ways to misuse it and it’s really badly documented.

这是个问题。 由于此时SSL的需求越来越高，这意味着我的堆栈中有一个至关重要的部分，我必须完全信任它。 而且它是以一种普通人无法理解其内部结构的方式编写的。 密码学是黑魔法。 可以争论的是，只要SSL引擎是开源的，就应该有很多眼睛可以确保我们的加密代码是安全的，但事实是，最受欢迎的加密库（OpenSSL）既古老又复杂。 即使该库本身可以，但仍有许多方法可以滥用它，并且确实存在不良记录。

As HTTP 2 now basically is TLS only as that’s the only transport that modern browsers implement. Gone are the days where you could fully understand how a web application works. We’re now deep in the territory where a relatively simple text based protocol has been replaced with a multiplexed stream of octets wrapped in a TLS connection. The future is now.

由于HTTP 2现在基本上仅是TLS，因为这是现代浏览器实现的唯一传输方式。 完全了解Web应用程序如何工作的日子已经一去不复返了。 现在，我们已经深陷其中，一个相对简单的基于文本的协议已被封装在TLS连接中的八位字节的多路复用流取代。 未来是现在。

我们可以减少加密吗？ (Can We have Less Encryption?)

I don’t think everyone should be forced to understand SSL and I don’t think everybody should be forced to implement encryption.

我不认为每个人都应被迫理解SSL，也不认为每个人都应被迫实施加密。

To give you an example of how ridiculous our love for SSL has become: PyPI. It’s the Python package service. As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless. It’s plenty to download the package over an untrusted connection and to then verify the checksum with one you downloaded from a secure place. As there is no need to operate on a partial file there is no technical reason why the entire transfer would have to be SSL encrypted.

举例说明我们对SSL的热爱变得多么荒谬：PyPI。 这是Python包服务。 从最近开始，Python软件包安装程序会通过SSL下载每个软件包。 为什么？ 除非您要向某人隐瞒您正在下载似乎毫无意义的特定Python软件包，否则没有任何技术原因。 可以通过不受信任的连接下载软件包，然后使用从安全位置下载的软件包验证校验和。 由于不需要对部分文件进行操作，因此没有技术上的理由说明必须对整个传输进行SSL加密。

Encryption is a good thing, but I believe it needs to be applied carefully. At the same time I think we as people need to start having a serious discussion what effects the widespread deployment of cryptography can have and how we deal with it. Working encryption is pretty much an absolute: there is no way around it. This is something that our countries previously did not have to deal with.

加密是一件好事，但我认为需要谨慎应用。 同时，我认为我们作为人们需要开始认真讨论加密技术的广泛部署会产生什么影响以及我们如何处理它。 有效的加密几乎是绝对的：没有办法解决。 这是我们各国以前不必处理的事情。