概述早在12月初，我们就向全世界宣布了"不让浏览器掉队"的倡议。从那时起，我们已经向访问者提供了超过5000亿个SHA-1证书，否则这些用户将无法使用HTTPS安全地与客户的站点进行通信。一直以来，我们一直在使用最新的椭圆曲线加密技术向现代浏览器提供更新的SHA-2证书，这表明人们不必牺牲安全性来容纳全世界的互联网用户。（如果您在CAs于2015/12/31停止颁发SHA-1证书之前无法获得，您仍然可以注册付费计划，我们将立即生成一个计划，以服务于您的传统访问者。）在我们宣布这些新的好处给我们的付费通用SSL客户后不久，我们就开始听到其他正在实现（或已经实现）类似功能的技术领导者的意见。乍一看，识别只支持SHA-1的传入连接的逻辑似乎很简单，但当我们在Facebook、Twitter和Mozilla上与我们的朋友交谈时，我意识到每个人都在采取稍微不同的方法。更复杂的是，在CloudFlare，我们不仅希望在SHA-1和SHA-2之间进行优化，还希望在RSA和更新的、但不太受普遍支持的ECDSA证书之间进行优化。如果不正确地解决"最佳证书"问题，TLS握手将失败，或者被完全不推荐使用SHA-1的浏览器显式中止；正确地解决它，客户机和服务器将在两个端点之间建立性能最好、最安全的连接。证书优化逻辑在几万亿次请求之后，我们确信我们的方法对CloudFlare的客户及其访问者非常有效。如果您采取了另一种实现方法，或者发现我们的逻辑有任何异常/潜在的改进，请在下面插话。我们将继续致力于撤销对SHA-1的支持，如果正如我们的首席执行官所说，"在我们的证书优化逻辑中发现了一个允许某种形式的降级攻击的漏洞，在这种情况下，现代浏览器可能会被诱骗接收到一个用不安全协议签署的证书，而且该漏洞无法修补。"。TLS握手在web浏览器可以与web服务器安全地交换"应用程序数据"（如HTTP GET或POST请求和响应）之前，它必须首先建立安全会话的加密参数。这种精心设计的舞蹈，称为SSL/TLS握手，只要您单击、键入或重定向到包含"https://"方案的URL，就会立即开始。（下面描述的过程也适用于来自任何用户代理的连接，而不仅仅是浏览器，所以可以用"移动应用程序"、"命令行实用程序"或其他任何可以通过HTTPS进行通信的东西来代替。）关于嵌入的、可遍历的包捕获的说明下图包含了一个实际的SSL/TLS记录，它是一个基于浏览器的WireShark版本。要查看握手的详细信息，请展开标记为"securesockets Layer"的最下面一行，然后向下钻取，直到看到"handshake Protocol:Client Hello"。注意，由于CloudShark使用旧版本的WireShark，一些扩展将呈现为"Unknown"，但是这些对于理解我们的证书交换逻辑是无关紧要的。第一步-客户你好在与服务器上的端口443建立TCP连接后，您的浏览器将发送一条ClientHello消息，其中包含它支持的最新版本的TLS；用于密钥交换的随机生成的数据；用户要浏览的网站的主机名；它支持的其他功能或扩展；以及支持的加密算法的排序列表。如果会话以前是与支持会话ID或会话票证的服务器建立的，则发送此恢复数据的目的是为了简化过程并避免"完全"握手；但是，下面的步骤假定完全握手，而不是简化握手。_图1-Chrome发送给网站_第2步-服务器你好如果ClientHello的基本参数对web服务器是可接受的，它将用一个ServerHello来响应，其中包含它自己的随机数据、它支持的客户端发送的扩展的子集，以及它从客户端提供的每个选项（最大支持的）TLS版本、密码套件和压缩方法中所做的选择。对CloudFlare edge支持的密码套件感兴趣的人可以在GitHub上找到它们。_图2-服务器Hello消息发送者网站镀铬_步骤3-（服务器）证书在发送ServerHello之后，即不等待客户机的响应，服务器立即发送证书消息。此消息至少包含与请求站点匹配的叶证书，但也可以包含链中的其他证书，如CA中间层。稍后我们将回到这条消息，因为此时必须执行任何服务器端逻辑来确定要呈现给浏览器的最佳证书（SHA-2ecdsa、SHA-2rsa或SHA-1rsa）。图3-证书消息发送者网站镀铬步骤4-证书链验证虽然在大多数TLS握手图中并不是一个明确的步骤，但是在SHA-1弃用的上下文中，在这里暂停一下并回顾这个过程是很重要的。当Chrome、Firefox和internetexplorer等浏览器放弃（或计划放弃）对SHA-1证书的支持时，他们正在修改的是这个证书验证逻辑，以显式地拒绝此类证书[1]。相反，当我们考虑只能使用SHA-1证书的浏览器时，如果使用SHA-2链进行验证，它们将遇到关键的握手中止错误。（更糟糕的是，web服务器几乎肯定无法区分SHA-2验证错误和间歇性网络问题。）收到证书消息后，浏览器[1:1]必须首先在叶证书（即对请求站点的主机名有效的证书）和系统由于包含在根存储中而显式信任的特定CA根之间建立链。当连接到诸如CloudFlare这样的HTTPS提供者时，这个过程是快速而明确的，它将整个链捆绑在一起：leaf和intermediate（s）。但是对于那些没有这样做的人，这个过程可能会比较慢，并且容易出错，因为用户代理有时会被迫在信息不足和不完整的情况下在其他路径之间做出决定。然后，对于组装链中的每个证书，浏览器提取由颁发证书颁发机构（CA）提供的签名，并使用颁发者的公钥进行验证。为此，浏览器使用指定的哈希算法（通常为SHA-1或SHA-256）创建X509结构的待签名（TBS）证书部分中包含的数据摘要（例如，过期日期、有效主机名等）。然后，它获取该摘要以及颁发者的公钥和签名，并通过签名算法的"verify"函数运行它。如果这个verify函数的输出为"true"，则浏览器知道该结构是完整的，并且从CA审查它时起没有变化，因为只有拥有相应私钥的人才能生成有效的签名。图4-验证证书签名剩余步骤（5+）证书验证ClientKeyExchange、ChangeCipherSpec和Finished之后的握手步骤对于我们的证书优化逻辑来说并不重要，因此这里不详细讨论它们。总而言之，在任何一端（ClientKeyExchange）生成相同的主键，并使用快速、对称的分组密码算法（如AES）来加密流量（ChangeCipherSpec）。逻辑树现在我们已经了解了用户代理如何与服务器建立TLS会话，接下来让我们将注意力转向CloudFlare如何具体地确定要呈现的证书，以及相应地确定要使用的密码套件。我们很快就会看到，这个逻辑必须在ServerHello和证书消息被发送到客户机之前执行。幸运的是，在解析ClientHello之后，我们已经拥有了所需的一切。下面是我们的edge遍历的逻辑树，为客户机的ClientHello制定适当的响应。我们为每个决策点贴上了与下面标题相对应的数字，以便您能够理解流程中的每个步骤。在尝试使用您自己的区域验证此逻辑之前，请记住：i）此流仅适用于付费计划免费计划始终会看到SHA-256/ECDSA证书；ii）您可能禁用了旧版浏览器支持，因此请确保在CloudFlare仪表板中的"加密"选项卡上进行确认。图5-付费计划的证书优化逻辑决策0：计划类型第一个检查非常简单：如果区域使用自由计划，我们将中止其余检查，并立即返回SHA-256/ECDSA证书。我们采取这种捷径的原因是，在入职期间，只有一个证书是为空闲区域生成的，因此除了SHA-256/ECDSA之外，没有其他候选证书可以考虑。决策1：存在签名算法扩展执行的下一个检查是是否存在签名算法扩展（0x000d）。在1.2版的TLS中添加了这个扩展，它"向服务器指明在数字签名中可以使用哪些签名/哈希算法对。"规范（RFC 5246）还包括：这个扩展的语义有点复杂，因为密码套件指示允许的签名算法，而不是哈希算法。如果客户机只支持默认的哈希和签名算法（在本节中列出），它可能会省略signature_algorithms扩展。如果客户机不支持默认算法，或支持其他哈希和签名算法（并且它愿意使用它们来实现