周一，我们宣布了通用SSL，为所有使用CloudFlare免费计划的网站启用HTTPS。通用SSL代表着我们通过HTTPS服务的站点数量从数万个大幅增加到数百万个。无论是在评论还是面对面，人们都问我们服务器如何处理这些额外的负载。简单地说，答案是这样的：我们发现，使用正确的硬件、软件和配置，web服务器上SSL的成本可以降到几乎为零。现代五金CloudFlare的整个基础设施都建立在现代商品硬件上。具体来说，我们的web服务器运行在Intel制造的cpu上，这些cpu的设计考虑了密码学。所有基于Westmile CPU微体系结构（于2010年推出）及更高版本的Intel CPU都有专门的加密指令。对于CloudFlare的通用SSL部署来说，重要的是AES-NI指令，它加快了高级加密标准（AES）算法的速度。还有一组称为无进位乘法（CLMUL）的指令，用于计算二进制有限域上的数学运算。CLMUL可用于加速Galois Counter mode（GCM）中的AES：我们首选的加密模式，因为它能抵抗像BEAST这样的最近的攻击。正如我们在TLS入门教程中所描述的，服务器根据客户机支持的密码套件选择在连接中使用的算法。在我们的配置中（在GitHub上可用），我们优先考虑基于AES的密码，并且更喜欢AES-GCM而不是AES-CBC。CloudFlare服务器提供的绝大多数HTTPS数据都是用AES加密的。下面是我们平均每天使用的密码分类：AES-CBC:62.8013%AES-GCM:36.2813%3DES:0.9170%RC4:0.0003%AES在我们的现代处理器上几乎没有性能成本，CloudFlare服务器加密的99%的数据都使用AES，因此成本非常小。请注意，在这些密码中，RC4是第二快的；然而，出于安全原因，我们取消了它的优先级，尽管由于一些奇怪的客户端配置，我们无法完全删除它。现代密码图片©Trevor Perrin 2014TLS连接有两个潜在的代价高昂的部分：数据加密和握手。使用AES-NI和CLMUL，数据加密基本上是免费的；但是，握手有两个昂贵的步骤。一个是私钥操作，另一个是密钥建立（这在我们的无密钥SSL帖子中描述）。在通用SSL中，私钥操作和密钥建立都使用椭圆曲线密码。私钥操作采用椭圆曲线数字签名算法（ECDSA），密钥建立采用短暂椭圆曲线Diffie-Hellman（ECDHE）。椭圆曲线加密允许您使用比传统RSA更小的密钥。例如，256位椭圆曲线密钥的强度相当于3072位RSA密钥。在一般情况下，较小的密钥允许椭圆曲线加密比RSA快5-10倍。对于通用SSL，我们选择了椭圆曲线P-256，它由Shay Gueron和Vlad Krasnov（目前在Intel）进行了优化的汇编代码实现。这个实现本周被合并到OpenSSL中，并为ECDHE和ECDSA提供了2-3倍的额外加速。选择这个椭圆曲线可以将TLS握手的计算负担降低一个数量级。直到本周推出通用SSL之前，互联网上除了100个站点都使用基于RSA的证书。通用SSL是第一个大规模部署TLS的ECDSA密钥。这是将椭圆曲线的优点带到web上的第一个主要步骤。会话共享即使使用快速椭圆曲线密码，非对称步骤（密钥建立和数字签名）仍然是TLS握手中最昂贵的部分。对于返回网站的访问者，我们有一个快捷方式，可以消除服务器执行这些昂贵操作的需要。这个快捷方式称为会话恢复，它内置于TLS规范中。在我们关于无密钥SSL的帖子中，我们提到了我们为改进会话恢复所做的新工作。恢复TLS连接不仅在延迟方面更快—减少了到服务器的一次往返，而且由于服务器可以跳过昂贵的非对称加密操作，所以它也更加轻量级。TLS协议有两种恢复会话的方法：会话票证和会话id。在会话ID恢复中，服务器存储会话信息以备以后重用。对于会话票证，会话信息由只有服务器知道的密钥加密，并在握手时以"会话票证"的形式发送给客户端。当客户机想要恢复会话时，它可以将会话票证发送到服务器，服务器可以对其进行解密并恢复会话。通过将连接信息存储为以后可以重用的方式，握手的昂贵部分就不必了。Zi Lin和Kyle Isom为实现无密钥SSL跨机器共享会话和会话票证所做的工作允许我们恢复连接，即使连接到不同的CloudFlare服务器。对于基于SSL会话票证的恢复（在Chrome和Firefox中使用），会话可以在全球范围内恢复；对于基于会话ID的恢复（所有其他浏览器），会话可以从同一数据中心的任何机器上恢复。延迟加载CloudFlare可以从世界上任何地方的任何CloudFlare服务器（包括TLS站点）为任何客户的站点提供服务。这种灵活性使我们能够高效地处理攻击，并在数据中心均匀地分担负载。nginx这样的Web服务器被设计成使用静态配置。如果站点的某些内容发生更改（如证书），则需要重新加载服务器配置。重新加载会导致服务器从磁盘读取数据并重新初始化内部状态，从而导致服务器资源紧张。当您有数以百万计的客户能够随时更改其证书时，通常需要重新加载。在CloudFlare的规模上，这可能会导致性能瓶颈。延迟加载证书有助于缓解这一瓶颈。通过使用CloudFlare工程师Piotr Sikora对nginx的自定义修改，我们能够仅在需要时将证书动态加载到内存中。现在，如果一个站点更改了它们的证书，服务器不必重新加载每个证书。这一变化使我们的服务器能够扩展到处理数百万个HTTPS站点。展望未来通过结合现代硬件、现代算法、延迟加载和会话恢复技术，我们能够将通用SSL的CPU使用率降低到几乎为零。希望我们的经验有助于揭穿SSL的一个神话：SSL可以在web服务器上以最小的额外负担进行大规模的实现。