cas开发_全球开发商cas被认为有害

cas开发

Originally published at https://httptoolkit.tech.

最初在 https://httptoolkit.tech上 发布 。

Certificate infrastructure is built on trust. If you trust the wrong thing, it all falls down. Unfortunately, we developers do it all the time anyway. YOLO.

证书基础结构建立在信任之上。 如果您相信错误的事情，一切都会崩溃。 不幸的是，我们开发人员始终都会这样做。 YOLO。

A remarkable number of dev tools & practices encourage or require you to globally trust a certificate authority (CA) that they provide or generate locally. If you do so these, anybody with access to the key for that CA can rewrite any HTTPS traffic between you and anything, and take almost complete control of your internet traffic.

大量的开发工具和实践会鼓励或要求您全局信任它们在本地提供或生成的证书颁发机构(CA)。 如果这样做，则有权访问该CA密钥的任何人都可以重写您与任何人之间的所有HTTPS通信，并几乎完全控制您的Internet通信。

We don’t need to do this. These tools could easily work without globally installed CAs, and they open you to unnecessary risks by not doing so. We can do better.

我们不需要这样做。 这些工具无需全局安装的CA就可以轻松工作，并且如果不这样做，就会使您面临不必要的风险。 我们可以做得更好。

是谁做的 (Who does this?)

Lots of different dev tools, for a couple of different reasons.

由于多种不同的原因，许多不同的开发工具。

First, there’s a selection of tools that generate HTTPS CAs & certificate for local development servers, and trust them for you globally & automatically. That lets you easily run a local HTTPS server on a hostname where certs aren’t otherwise available, like localhost or other local hostnames ( my-docker-container:8080). That's often useful because more and more web features are limited to only HTTPS origins.

首先，有一些工具可以为本地开发服务器生成HTTPS CA和证书，并在全球范围内自动为您信任它们。 这样一来，您可以轻松地在无法提供证书的主机名上运行本地HTTPS服务器，例如localhost或其他本地主机名( my-docker-container:8080 )。 这通常很有用，因为越来越多的Web功能仅限于HTTPS起源。

The tools doing this include:

执行此操作的工具包括：

In addition to local HTTPS servers, there’s also a world of HTTPS debugging tools, in a similar space to HTTP Toolkit itself. These tools let you intercept, inspect & rewrite HTTPS traffic between a client and a server, for testing, debugging & prototyping. They typically intercept HTTPS traffic from your whole system, and require/strongly encourage you to trust their CA certificates globally to do so.

除了本地HTTPS服务器之外，还有很多HTTPS调试工具，与HTTP Toolkit本身的空间类似。 这些工具使您可以拦截，检查和重写客户端与服务器之间的HTTPS通信，以进行测试，调试和原型设计。 他们通常拦截整个系统的HTTPS流量，并要求/强烈鼓励您在全球范围内信任其CA证书。

There’s a host of examples of these, from Fiddler on Windows, to Charles on Mac, or Burpsuite (Java, cross platform), all following that same pattern.

有很多示例，从Windows上的Fiddler到Mac上的Charles或Burpsuite (Java，跨平台)，都遵循相同的模式。

A few of these server & debugging tools do recognize that there’s risks inherent in this (although they do it anyway). Warnings abound:

这些服务器和调试工具中的一些确实认识到了其中固有的风险(尽管他们还是这样做)。 警告比比皆是：

Mkcert:

Mkcert：

Warning: the rootCA-key.pem file that mkcert automatically generates gives complete power to intercept secure requests from your machine. Do not share it.

警告 ：mkcert自动生成的rootCA-key.pem文件具有完全的功能来拦截来自计算机的安全请求。 不要分享。

Devcert:

开发证书：

This exposes a potential attack vector on your local machine: if someone else could use the devcert certificate authority to generate certificates, and if they could intercept / manipulate your network traffic, they could theoretically impersonate some websites, and your browser would not show any warnings (because it trusts the devcert authority).

这暴露了本地计算机上的潜在攻击媒介：如果其他人可以使用devcert证书颁发机构生成证书，并且如果他们可以拦截/操纵您的网络流量，则从理论上讲他们可以假冒某些网站，并且您的浏览器不会显示任何警告(因为它信任devcert权威)。

Burp Suite:

打p套房：

If you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a user-specific location. If untrusted people can read local data on your computer, you may not wish to install Burp’s CA certificate.

如果在浏览器中安装了受信任的根证书，则具有该证书的私钥的攻击者即使没有使用拦截代理，也可能会在没有明显检测的情况下将您的SSL连接居中。 为了防止这种情况，Burp会为每个安装生成唯一的CA证书，并且此证书的私钥存储在您计算机上的用户特定位置。 如果不受信任的人可以读取您计算机上的本地数据，则您可能不希望安装Burp的CA证书。

If only we could avoid these warnings somehow, and do something safer instead…

如果我们能以某种方式避免这些警告，而是做些更安全的事情……

可能出什么问题了？ (What could possibly go wrong?)

Doing this but showing warnings isn’t the right choice. Firstly because it’s rarely necessary at all (we’ll get to that), but mainly because nobody reads warnings. Silently creating new risks on your machine and then waving away concerns with “well we warned you” is a touch rude. We should all encourage our users to do the safe thing by default, so far as possible.

这样做但显示警告不是正确的选择。 首先，因为它根本没有必要(我们将介绍)，但主要是因为没有人阅读警告。 静静地在您的计算机上创建新的风险，然后用“好吧，我们警告您”挥之不去。 我们所有人都应鼓励用户尽可能默认地执行安全操作。

As a case in point, both Preact-CLI & Webpack-Dev-Server support automatic local HTTPS, so that users can easily use HTTPS locally by trusting their CA certificates. In 2017 it was discovered by Mike North that both projects were using a shared default CA whose HTTPS key & certificate was published as part of the tool.

举例来说，Preact-CLI和Webpack-Dev-Server都支持自动本地HTTPS，因此用户可以通过信任自己的CA证书轻松地在本地使用HTTPS。 在2017年它被发现由Mike北这两个项目都使用一个共享的默认CA，其关键的HTTPS证书与出版作为工具的一部分。

Anybody who trusted the certs from either tool before June 2017 and hasn’t heard about this now trusts a compromised CA, which means they 100% trust pretty much anybody to send them anything, until that CA expires. For webpack-dev-server, that CA cert is valid until 2026, 10 years after it was issued. Oops.

任何在2017年6月之前信任任一工具的证书并且从未听说过此事的人现在都信任一个受损的CA，这意味着在该CA失效之前，他们100％几乎信任任何人向他们发送任何东西。 对于webpack-dev-server，该CA证书有效期至2026年，即颁发该证书后的10年。 哎呀。

It’s hard to get precise numbers on how many users this affected, but the Webpack-Dev-Server package was installed 27 million times before the fix for this was released, so even with conservative estimates this was Very Bad.

很难获得影响到多少用户的准确数字，但是Webpack-Dev-Server软件包在此补丁发布之前已安装了2700万次，因此即使保守估计也很糟糕。

To quote Mike’s disclosure:

引用Mike的披露：

As a result of this vulnerability, an attacker could very easily and reliably eavesdrop on, and tamper with HTTPS traffic across ALL DOMAINS, undetected. Essentially HTTPS is completely compromised, and no data is secret or safe anymore.

由于此漏洞，攻击者可以非常容易且可靠地窃听并篡改跨所有域的HTTPS流量，而未被发现。 本质上，HTTPS完全被破坏，并且不再有任何数据是秘密或安全的。

This happened because the private key was shared & fully public. All the tools above generate fresh CA certificates & keys on every developer’s machine, so they’re not immediately vulnerable to this specific issue. They avoid the worst case, but this shows what happens if users keys are exposed, and just because we’ve fixed the worst case, that doesn’t make that risk go away.

发生这种情况是因为私钥是共享的且完全公开。 上面的所有工具都会在每个开发人员的计算机上生成新的CA证书和密钥，因此它们不会立即受到此特定问题的影响。 他们避免了最坏的情况，但这显示了如果公开用户密钥会发生什么，并且仅仅因为我们已经解决了最坏的情况，这并不会消除这种风险。

In fact, in some ways it’s got even worse since 2017, with the new Signed HTTP Exchanges feature (live in Chrome 73). In the past, abusing a trusted CA certificate would require you to intercept a machine’s HTTPS traffic to the target domain. Nowadays you can instead generate signed HTTP exchanges from domain X using an exposed CA, then host that exchange on your own domain Y. Anybody visiting & trusting the CA will treat that as real traffic from X. Now domain Y can now run JS in domain X’s origin, or poison its cache to inject code later. Drive-by attacks, no interception of traffic necessary.

实际上，自2017年以来，通过新的Signed HTTP Exchanges功能(在Chrome 73中有效)，自2017年以来情况甚至更糟。 过去，滥用受信任的CA证书将需要您拦截计算机到目标域的HTTPS通信。 如今，您可以改为使用暴露的CA从域X生成签名的HTTP交换，然后将交换托管在您自己的域Y上。任何访问并信任CA的人都将其视为来自X的真实流量。现在域Y现在可以在域中运行JS X的来源，或毒害其缓存以稍后注入代码。 偷渡式攻击，无需拦截流量。

And then there’s everything else on your system that trusts your installed CA certificates. I wouldn’t be surprised if this worked to defeat code signing checks, attack many app’s automated update processes, and make you vulnerable in lots of other places. You can be too trusting.

然后，系统上的所有其他内容都将信任已安装的CA证书。 如果这样做可以打败代码签名检查，攻击许多应用程序的自动更新过程，并使您在许多其他地方容易受到攻击，我不会感到惊讶。 您可能太信任了。

有什么机会？ (What’re the chances?)

Once you have a CA certificate like this installed, all certificate-based security on your machine becomes contingent on you keeping the private key of that CA secret. That’s easier said than done, especially given that many users are unaware of the risks, where the key is stored, or even that it exists.

一旦安装了这样的CA证书，计算机上所有基于证书的安全性都将取决于您对该CA的私钥保持秘密。 说起来容易做起来难，尤其是考虑到许多用户不知道风险，密钥的存储位置甚至是密钥的存在。

To use a CA like this locally you generally need the CA private key in a user-readable file, so you can use it (or you need to run your dev tools as root, which brings fun new risks). That means you have a user-readable file on your computer that is a catastrophic security risk if it’s ever exposed.

要在本地使用这样的CA，通常需要在用户可读文件中使用CA私钥，以便可以使用它(或者需要以root用户身份运行开发工具，这会带来很多新的风险)。 这意味着您的计算机上有一个用户可读的文件，如果暴露该文件，则会带来灾难性的安全风险。

If somebody ever gets access to your machine, if you accidentally commit this file to a project, if you back it up to the wrong place, or if a rogue app on your machine quietly reads it, you now have a huge & invisible problem.

如果有人访问过您的计算机，如果您不小心将该文件提交到项目中，或者将其备份到错误的位置，或者如果计算机上的恶意应用程序安静地读取了该文件，那么您现在将面临一个巨大且看不见的问题。

As an industry we spend a lot of effort elsewhere avoiding exactly this kind of risk. We password protect our SSH keys, we salt & hash passwords in databases, and we encrypt our password manager’s database on disk. You don’t want a “if you can read this, you own my computer” user-readable file on your computer. You definitely don’t want tools to generate one for you and quietly & automatically store it somewhere.

作为一个行业，我们在其他地方花费了大量的精力来避免这种风险。 我们用密码保护SSH密钥，在数据库中添加盐和哈希密码，并在磁盘上加密密码管理器的数据库。 您不需要计算机上的“如果您能读懂，您拥有我的电脑”的用户可读文件。 您绝对不希望工具为您生成一个文件并悄悄地将其自动存储在某个地方。

To be fair, it is possible in the HTTPS devserver case to have a CA key that’s only root-readable, and to cache user-readable certificates & keys per-domain instead. A tool then needs to prompt for sudo/admin rights for initial setup for each domain, and when certs expire. That definitely helps, but only for servers; it’s not practical for debuggers, where you might talk to many domains unpredictably.

公平地说，在HTTPS devserver的情况下，有可能只有根可读的CA密钥，而是在每个域中缓存用户可读的证书和密钥。 然后，一个工具需要提示您为每个域的初始设置以及证书到期时的sudo / admin权限。 这肯定有帮助，但仅适用于服务器。 对于调试器而言，这是不切实际的，在调试器中，您可能无法预测地与许多域进行对话。

Even for servers this isn’t perfect: only root-readable doesn’t mean “100% secure forever”, each per-domain key still needs to be user-readable so remains vulnerable, and your dev tools need to prompt you at intervals for authorization as your certs expire, which isn’t great either (and potentially opens a UX hole for others to steal the root-readable CA key).

即使对于服务器来说，这也不是完美的：仅根目录可读性并不意味着“永远100％安全”，每个域密钥仍然需要用户可读，因此仍然容易受到攻击，并且您的开发工具需要定期提示您证书过期时进行授权，这也不是一件好事(并且可能会为其他人打开UX漏洞，以窃取根可读的CA密钥)。

That brings me to one of the consequences of this whole mess: because refreshing global CAs is hard, managing global CAs is much easier with long-lived certificates, which makes things even worse if they ever do get exposed. Your dev tools do not need certificates that last 10 years.

这使我想起了整个混乱的后果之一：由于很难刷新全局CA，因此使用长期存在的证书来管理全局CA要容易得多，如果暴露了这些证书，情况甚至会更糟。 您的开发工具不需要持续10年的证书。

Even if the CA key is never exposed, at the very least you’re giving random developer tools you just downloaded permission to inspect & rewrite everything you ever see and do on the internet for years into the future. That should sound scary — as we saw with Webpack & Preact-CLI, great dev tool authors are not necessarily security experts.

即使CA密钥从未公开过，至少您还给了随机的开发人员工具，您刚刚下载了许可，可以检查并重写在未来数年内在Internet上看到和执行的所有操作。 这听起来很可怕-正如我们在Webpack＆Preact-CLI中所看到的那样，出色的开发工具作者不一定是安全专家。

Fundamentally, the problem here is that globally installing CA certificates for local development tools violates the principle of least privilege. Nobody uses these tools intending to redefine their long-term definition of trust for the whole internet, but that’s what they’re doing. Instead, we should trust these tools to verify traffic to the specific domains we care about, for the client we’re using, whilst we’re using the tool.

从根本上讲，这里的问题是，为本地开发工具全局安装CA证书违反了最低特权原则 。 没有人会使用这些工具来重新定义整个互联网的长期信任定义，但这就是他们正在做的事情。 相反，我们应该信任这些工具，以便在使用该工具的同时，为正在使用的客户端验证到我们关注的特定域的访问量。

Fortunately, we can do exactly that.

幸运的是，我们可以做到这一点。

如何更好地工作？ (How could this work better?)

For 99% of cases you don’t need to trust these CA certificates globally. When running an HTTPS server, you only need to trust it in your HTTP client whilst the server is running, and only for that one domain. When debugging a client, you only need to trust the certificate within that client, during that one debugging session.

在99％的情况下，您无需全局信任这些CA证书。 运行HTTPS服务器时，仅在服务器运行时才需要在HTTP客户端中信任它，并且仅针对该域。 在调试客户端时，您只需要在一个调试会话中信任该客户端中的证书。

We can and should do exactly that. The real only argument against this I’ve seen is that it’s hard, but that’s really not true, even before you compare this with the complexity of automatically elevating privileges & globally installing certificates for every possible browser & OS.

我们可以并且应该做到这一点。 我所见过的唯一真正的反对意见是，这很难，但事实并非如此，甚至在您将其与自动提升特权和为每个可能的浏览器和操作系统全局安装证书的复杂性进行比较之前，也是如此。

Let’s talk about browsers, for example. If you’re running a local HTTPS server for development, that’s probably your client of choice. To trust a CA in Chrome temporarily for that one Chrome process, without affecting other or future Chrome processes, and without trusting anything system-wide, you need to:

例如，让我们谈谈浏览器。 如果您正在运行本地HTTPS服务器进行开发，则可能是您选择的客户端。 要在一个Chrome进程中临时信任Chrome中的CA，而又不影响其他或以后的Chrome进程，并且不信任整个系统的任何内容，您需要：

This is not that hard. That same option also works out of the box for other Chromium-based browsers, from Edge to Brave.

这并不难。 对于从Edge到Brave的其他基于Chromium的浏览器，该选项也可以直接使用。

Firefox doesn’t have one single option to trust this certificate, but you can create a new Firefox profile, trust it manually there (or automatically using ), and then use that profile just when you need it. Setting this up and selecting the profile is automatable, and in fact devcert & mkcert already do most of the setup (but against your global user profile).

Firefox没有一个选项可以信任此证书，但是您可以创建一个新的Firefox配置文件，在此手动信任(或自动使用)，然后在需要时使用该配置文件。 设置并选择配置文件是自动的，事实上devcert和mkcert已经完成了大多数设置(但是针对您的全局用户配置文件)。

For non-browser HTTPS clients, there are good options too. In most cases, certificate trust can be configured just with an environment variable. That means you can set this variable in the script you use to run your tests or start your client, and you’re done.

对于非浏览器的HTTPS客户端，也有不错的选择。 在大多数情况下，仅可以使用环境变量来配置证书信任。 这意味着您可以在用于运行测试或启动客户端的脚本中设置此变量，然后完成。

For starters, for anything that uses the OpenSSL defaults you can set the SSL_CERT_FILE environment variable to point to the certificate path. This covers many apps and popular tools out of the box, from curl to apt-get, notably including most code running in Ruby, Python, PHP, and other similar languages.

对于初学者，对于使用OpenSSL默认值的任何内容，都可以将SSL_CERT_FILE环境变量设置为指向证书路径。 它涵盖了开箱即用到apt-get的许多应用程序和流行工具，特别是包括以Ruby，Python，PHP和其他类似语言运行的大多数代码。

There’s a few other special cases, depending on what you’re building. Node.js ignores this variable, but provides its own NODE_EXTRA_CA_CERTS env var which works similarly. A few other specific libraries need their own configuration too, like Python's popular Requests library ( REQUESTS_CA_BUNDLE), and Perl's LWP ( PERL_LWP_SSL_CA_FILE). For Java you need to build a truststore for your app that includes the cert, which means running one command.

还有其他一些特殊情况，具体取决于您要构建的内容。 Node.js会忽略此变量，但会提供其自己的NODE_EXTRA_CA_CERTS变量，其工作原理类似。 其他一些特定的库需要自己的配置太像Python的流行请求库( REQUESTS_CA_BUNDLE )，以及Perl的LWP( PERL_LWP_SSL_CA_FILE )。 对于Java，您需要为您的应用构建一个包括cert的信任库，这意味着运行一个命令 。

While this isn’t trivial, it wouldn’t be hard to bundle it into a zero-config package that did make this effortless. For any of these languages, it’s very possible to temporarily trust a given certificate for effectively all HTTPS traffic, with no global side effects or long-term risk.

尽管这并非易事，但将其捆绑到零配置程序包中并不难，这确实使它毫不费力。 对于这些语言中的任何一种，都可以临时信任给定的证书来有效地处理所有HTTPS流量，而不会产生全局副作用或长期风险。

As a last step, we could also limit the power of the CA certificates themselves. Support for the Name Constraints certificate extension is rapidly growing. This lets you create a CA that’s only trusted to sign certificates for a whitelisted range of domains, so that trusting a CA doesn’t mean giving them a blank cheque for the whole internet.

最后，我们还可以限制CA证书本身的功能。 对名称约束证书扩展的支持正在Swift增长 。 这样，您就可以创建仅受信任的CA对白名单范围的域的证书进行签名，因此信任CA并不意味着对整个Internet进行空白检查。

With improvements like this, in 99% of cases we can directly trust the certificate only when and where we need it, from browsers to backend code to shell scripts to CLI tools. It’s simply not necessary to globally trust certificate authorities just to use simple dev tools.

通过这样的改进，在99％的情况下，我们只能在需要的时间和地点直接信任证书，从浏览器到后端代码再到Shell脚本再到CLI工具。 仅仅使用简单的开发工具就不必全局信任证书颁发机构。

我们应该做什么？ (What should we do?)

Ok, so this is happening, it’s bad, and it’s unnecessary. How do we fix it?

好的，这正在发生，很糟糕，而且没有必要。 我们该如何解决？

• Tools that set up a local HTTPS server by globally trusting the CA should drop that, and instead add commands to start browsers that trust the cert directly, and encourage users to use that instead by default.
  通过全局信任CA来设置本地HTTPS服务器的工具应删除该证书，而应添加命令以启动直接信任该证书的浏览器，并鼓励用户默认使用该证书。
• Automated tests & scripts that talk to local HTTPS servers should not require installing global certs, but should instead trust the certs just by configuring their clients, and only during the test.
  与本地HTTPS服务器通信的自动化测试和脚本不应要求安装全局证书，而应仅通过配置客户端并在测试过程中信任证书。
• HTTPS debuggers should take control of the clients they care about, and inject settings directly into them, rather than requiring global trust & intercepting all traffic from the entire system.
  HTTPS调试器应该控制他们关心的客户端，并将设置直接注入到它们中，而不是需要全局信任和拦截来自整个系统的所有流量。
• Anybody building logic that decides which certificates to trust should include an escape hatch like the above, rather than only trusting the OS store, and should implement name constraints.
  决定信任哪些证书的任何构建逻辑的人都应像上面一样包含转义符，而不是仅信任OS存储，并应实施名称约束。
• Tools should aim to generate CA certificates with name constraints & short lifetimes by default. For many use cases you could even go further, and generate a fresh CA for every session.
  默认情况下，工具应旨在生成具有名称限制和较短生存期的CA证书。 对于许多用例，您甚至可以走得更远，并为每个会话生成一个新的CA。
• Developers (and everybody else) should stop trusting & installing CA certificates globally without a really really rock-solid good reason that they fully understand.
  开发人员(以及其他所有人)应该停止在全球范围内信任和安装CA证书，而没有一个他们完全理解的坚如磐石的良好理由。

Phew. Sound good?

ew 听起来不错？

Of course, a big part of why I’m writing this is my work in HTTP Toolkit solving the exact same problem. HTTP Toolkit is an open-source HTTPS debugger that has tools to intercept traffic from single clients, by injecting proxy settings & trusting certificates only where they’re necessary, doing exactly the above. With this, you capture & rewrite only the traffic you’re interested in, you don’t have any of the global trust problems we’ve talked about here, and you never need to give anything any extra permissions.

当然，写这篇文章的很大一部分是我在HTTP Toolkit中解决完全相同的问题的工作。 HTTP Toolkit是一个开放源代码的HTTPS调试器，它具有通过拦截代理设置和仅在必要时信任证书的工具来拦截来自单个客户端的流量的方法，完全可以完成上述操作。 这样，您就可以仅捕获和重写您感兴趣的流量，您不会遇到我们在此处讨论的任何全局信任问题，并且您无需授予任何额外的权限。

That implementation is all open source, so if you’re interested or working on something similar then go take a look at how HTTP Toolkit launches Chrome with interception, or all the env vars it uses to intercept arbitrary CLI commands.

该实现都是开源的 ，因此如果您有兴趣或从事类似工作，那就看一看HTTP Toolkit是如何通过拦截启动Chrome的 ，或它用于拦截任意CLI命令的所有env变量的。

Have any thoughts on this? Get in touch on Twitter, by email, or join the discussion on HN & reddit.

有什么想法吗？ 通过电子邮件 与Twitter取得联系，或加入有关HN ＆ reddit的讨论。

Originally published at https://httptoolkit.tech.

最初在 https://httptoolkit.tech上 发布 。

翻译自: https://medium.com/@pimterry/global-developer-cas-considered-harmful-4057e1cd0a3b

cas开发