它可能（或者不一定！）令人惊讶的是，几个月前，我们迁移了Cloudflare的edge SSL连接终止堆栈，以使用BoringSSL:Google的crypto和SSL实现，最初是OpenSSL的分支。我们花了几个月的时间来实现这一目标，而不会对客户流量造成负面影响。我们在前进的道路上遇到了一些困难，必须克服一些挑战，但我们最终在一个比几个月前更好的地方结束了。TLS 1.3条我们已经写了大量关于TLS1.3的博客。我们最初的tls1.3协议栈要求我们的主SSL终端软件（基于OpenSSL）将TCP连接传递到基于fork-of-Go的crypto/TLS标准库的独立系统，该库是专门为只处理tls1.3连接而开发的。这被证明是一个方便的实验，我们可以在相对安全的情况下推广到我们的客户群。然而，随着时间的推移，这个独立的系统开始使我们的生活变得更加复杂：我们与SSL相关的大多数业务逻辑都需要在新系统中复制，这导致了一些细微的错误，并使得向所有客户机推出诸如Client Auth之类的新功能变得更加困难。碰巧，BoringSSL支持tls1.3已经很长时间了（它是第一个使用此特性的开源SSL实现之一），所以现在我们所有的边缘SSL流量（包括tls1.3连接）都由同一个系统处理，没有重复，没有增加复杂性，也没有增加延迟。耶！奇特的新密码，第1部分：TLS1.2（及更早版本）的X25519当建立SSL连接时，客户机和服务器将协商特定于连接的密钥，然后这些密钥将用于加密应用程序流量。有几种不同的方法可以实现这一点，最流行的方法是ECDH（椭圆曲线Diffie-Hellman）。长话短说，这取决于客户端和服务器之间协商的椭圆曲线。在很长一段时间内，唯一得到广泛支持的曲线是由NIST定义的曲线，直到Daniel J.Bernstein提出了Curve25519（X25519是基于Curve25519的ECDH所使用的机制），Curve25519已经迅速普及，现在是许多流行浏览器（包括Chrome）的默认选择。tls1.3连接已经支持这一点，使用BoringSSL，我们现在可以在我们的边缘为tls1.2（及更早版本）连接支持基于X25519的密钥协商。X25519现在是我们网络上使用的第二种最流行的椭圆曲线算法：新密码，第2部分：TLS1.2的RSA-PSSTLS1.3引入的另一个变化是对RSA签名采用PSS填充方案（RSASSA-PSS）。对于所有TLS1.3连接，这将取代更脆弱、历史上容易出现安全漏洞的RSASSA-PKCS1-v1.5。自从Bleichenbacher的CRYPTO 98论文表明SSL/TLS也容易受到此类攻击以来，RSA PKCS v1.5就一直容易受到已知的密文攻击。攻击者利用一个"oracle"，在本例中是一个TLS服务器，该服务器允许他们确定给定的密文是否已根据PKCS1-v1.5的规则正确填充。例如，如果服务器返回正确填充与不正确填充的不同错误，则可以将该信息用作甲骨文（这就是Bleichenbacher在1998年破坏SSLv3的原因）。如果不正确的填充导致握手所花费的时间与正确填充的时间不同，这称为计时预言。如果攻击者有权访问oracle，则只需15000条消息就可以获得足够的信息，从而在不拥有密钥的情况下执行RSA密钥操作。这足以让攻击者解密用RSA加密的密文，或伪造签名。伪造签名允许攻击者劫持TLS连接，而解密密文则允许攻击者解密任何不使用前向保密的连接。从那时起，SSL/TLS实现已经采取了一些缓解措施来防止这些攻击，但是它们很难纠正，正如最近发布的F5漏洞所显示的那样。通过切换到BoringSSL，我们使RSA PSS也可用于tls1.2连接。这已经在"野生"中得到了支持，并且是现代浏览器（如Chrome）在处理RSA服务器证书时的首选方案。月球的黑暗面除了我们现在向所有客户提供的这些令人兴奋的新功能之外，BoringSSL还有一些最终用户不会注意到的内部功能，但这让我们的生活变得轻松多了。我们的一些SSL特性需要我们在内部OpenSSL fork中维护的特殊补丁，但是BoringSSL提供了这些特性的替代品（以及更多！）开箱即用。一些例子包括我们现在用来实现无密钥SSL的私钥回调支持，我们用来支持分布式会话ID缓存的异步会话查找回调（对于那些由于任何原因不支持会话票证的客户端的会话恢复），它的等优先级密码分组允许我们提供ChaCha20-Poly1305密码和AES-GCM密码，让客户决定他们喜欢哪个，或者它的"select_certificate"回调，我们使用它来检查和记录ClientHellos，并根据用户的配置动态启用功能（我们以前使用的是后者的"cert_cb"回调，OpenSSL也支持它，但是我们遇到了一些限制，比如您不能用它动态更改支持的协议版本，或者在会话恢复期间没有执行它）。丢失OCSP的情况除了添加新特性外，BoringSSL开发人员还忙于删除大多数人不关心的特性，以使代码库更轻巧、更易于维护。在大多数情况下，这是非常好的：大量的代码已经从BoringSSL中删除，没有人注意到。然而，OCSP也是其中一个被砍掉的特性。我们非常依赖于边缘的这一特性来自动为所有客户机提供OCSP装订。所以为了避免失去这个功能，我们花了几个星期的时间来做一个替换，而且，惊喜！我们最终得到了一个比我们开始时更可靠的OCSP管道。你可以阅读更多关于我们在这篇博客文章中所做的工作。ChaCha20-Poly1305草案另一个被删除的特性是对遗留的ChaCha20-Poly1305密码的支持（不要与RFC7905中标准化的密码混淆）。这些密码是在标准化过程完成之前由一些浏览器部署的，最终与后来批准的标准密码不兼容。我们查看了我们的指标，发现很大一部分客户仍然依赖于此功能。这些将是旧的移动客户端，没有AES硬件卸载，也没有更新软件来获得更新的ChaCha20密码。我们决定将对这些密码的支持添加到我们自己的内部BoringSSL fork中，这样那些老客户机仍然可以利用它们。我们将继续监视我们的指标，并在使用率显著下降时决定是否删除这些指标。慢垒64：维尼，维迪，维奇在测试部署期间，我们注意到了一个有点恼人的问题，那就是NGINX实例的启动时间增加了。有了性能和火焰图，我们查看了发生了什么，并意识到CPU在BoringSSL的base64解码器中花费了大量的时间。结果是，我们在NGINX配置的不同部分从磁盘（以PEM格式，使用base64）加载CA可信证书，并且由于BoringSSL的更改，它的目的是使base64解码器的时间保持恒定，但也使它比OpenSSL中的解码器慢几倍时代也遭受了损失。当然，精明的读者可能会问，为什么要从磁盘多次加载这些证书？事实上，没有什么特别的原因，除了这个问题一直没有被注意到，直到它真正成为一个问题。所以我们修改了配置，只在实际需要的配置部分从磁盘加载证书，并从此过着幸福的生活。结论尽管有一些小问题，但整个过程还是相当顺利的，这也归功于BoringSSL代码库的坚如磐石的稳定性，更不用说它的大量文档了。我们不仅得到了一个比以前更好、更易于维护的系统，而且还设法为开源社区做出了一点贡献。最后，我们要感谢BoringSSL开发人员，感谢他们在项目中倾注了大量的工作，并在此过程中为我们提供了帮助。