初始问题报告几个月前，我们偶尔会听到.NET开发人员报告说，他们在维护客户网站的HTTPS会话时遇到了困难。建立连接工作正常，但它们会定期断开连接，从而导致异常，使应用程序崩溃。大约在同一时间，我们也开始听说微软的另外两个产品Internet Explorer和它的继承者Edge也在我们的Edge上遇到了麻烦。就在几周前，我们已经更新了TLS会话票证的处理方式，以便更高效、更安全。我们怀疑这些改进是导火索，我们把调查重点放在那里。我们了解到的是，这个问题比.NET或IE要严重得多，一直到SChannel安全包，它为大量的微软应用程序提供TLS功能。TLS会议票然而，在深入了解这个故事之前，有必要确切了解TLS会话票证是什么，它们对HTTPS有何好处，以及CloudFlare在大规模使用TLS会话票证时做了哪些优化。（如果您想跳过初级读物，直接跳到关键点，请单击此处。）概述RFC4507（自RFC5077弃用）于2006年首次引入，它提出了一种"使传输层安全（TLS）服务器能够恢复会话并避免保持每个客户端会话状态的机制"。然而，在服务器可以免除自己维护状态的责任之前，它必须首先"将会话状态封装到一个票证中并将其转发给客户机"。然后，客户机保存此票证，并在下次需要发出HTTPS请求时将其呈现给服务器，跳过了最初建立TLS会话所需的大部分来回过程。与标准的协议协商消息不同，双方执行所谓的"简化握手"，直接使用先前商定的会话细节。此快捷方式将连接设置时间缩短了50%以上，因为往返次数从两次减少到一次。注意，票证的生存期和持续有效性取决于服务器和客户机：服务器向客户机传递"会话生存期提示"，客户机决定是否愿意在到期之前一直重用会话。如果没有，或者对会话完整性有任何疑问，任何一方都可以强制进行完全握手并重新生成票证。继续会话图1-完整TLS握手与缩写TLS握手要通知服务器浏览器可以使用会话票证（不是所有的都可以），连接的用户代理必须首先公布其对会话票证的支持，否则在创建和加密票证上没有任何花费周期。为了传递此功能，客户机在初始ClientHello消息的会话票证扩展中发送一个空值。当服务器看到这个扩展时，它知道要保留会话的协商细节，例如TLS协议版本、密码套件和用于加密请求和响应的对称密钥。然后，这些细节被打包在一个数据结构中，用只有服务器知道的"会话票证密钥"加密，然后发送到客户端以安全保存。因为服务器知道只有它才能解密和查看票证内容，所以它不需要保存一个副本来检查是否有篡改（例如，会话生存期的不当延长），而是依赖客户端来执行此操作。这种分布式存储使得rfc5077会话票证比它们的前一代会话id具有更高的可伸缩性。会议票规模的挑战因此，HTTP服务器使用只有它才能访问的密钥加密会话票证。然而，在CloudFlare的例子中，"服务器"实际上是覆盖全球的数千台机器，并响应来自尽可能靠近浏览器（网络方面）的请求。在我们36个国家的76个数据中心网络中，每台机器都设计用于处理所有类型的请求，包括SSL/TLS握手和应用程序数据的处理。请求被路由到负载最小的服务器，并且远离降级的网络状况（或整个设备停机）。在单个会话期间与多个服务器进行事务处理不应（也不会）降低性能：以一台服务器上的完全握手开始的TLS会话可以通过任何其他服务器上的简短握手恢复（当然，假设客户机持有适当的票证）。这使我们的会话票证实现复杂化，因为这意味着每台机器都需要立即访问相同的会话票证密钥。解决这个密钥分发问题的一种简单（读：不安全）方法是随机生成一次这个48字节的密钥，并将其添加到复制到每个服务器的配置文件中。在启动时，服务器将读取密钥并无限期地使用它来发布新的票证和解密现有的票证。这种方法最明显的问题（除了在配置文件中存储机密的反模式之外）是密钥很少更改。因此，"前向保密"的密码学性质受到了极大的损害。前向保密很重要，因为它使得加密流量的历史捕获变得毫无价值，即使服务器的私钥被泄露。CloudFlare会议门票CloudFlare对这个问题的解决方案（在以前的博客文章中有所记录）是在我们整个全球网络中频繁地重新生成和同步这些会话票证密钥。我们目前每小时做一次。这意味着我们需要一种机制来翻转会话票证密钥。例如，如果客户端在12:00pm实例化一个HTTPS会话，并且在下午1:00pm之后继续使用该票证，那么我们的边缘网络将使用一个全新的会话票证密钥重新加密票证。为了实现这一点，我们的web服务器必须同时拥有以前所有可能加密票证的密钥的完整历史记录（即，每小时一个密钥可以追溯到64800秒的最长会话生命周期），并且可以立即访问每个新生成的密钥。以前的密钥专门用于解密客户端提供的票证，而新密钥用于"刷新"现有票证上的加密，并加密全新会话的票证。返回Microsoft这些先前发出的会话票证（用我们新生成的密钥重新包装并以简短的握手方式发送回客户机）的处理就是我们观察到基于Microsoft SChannel构建的每个用户代理都崩溃的地方。续签会议票（或不续签）根据会话票证规范，服务器可以出于任何原因拒绝以缩略握手方式提交给它的会话票证，并强制进行完全协商。执行此操作时，它只需在收到来自客户端的完成消息后立即发送NewSessionTicket消息。然后，客户机保存新票据并将其用于后续请求。下面的图2中记录了这个消息流，它不会给我们的客户'.NET和IE访问者带来任何问题。也就是说，它不是我们发现的bug的一部分。*表示可选消息图2-服务器拒绝票证，执行完全握手，并发出新的会话票证这种行为的一个常见示例是在重新启动之后，当服务器失去对其所有现有会话密钥的访问时。拒绝和替换客户端发送的会话票证的另一个原因是服务器可以保持前向保密性：密钥的生存期越短，攻击者必须强行破解并解密流量的窗口就越小。虽然强制进行完全握手并发送新的会话票证是循环会话票证密钥的一种方法，但更有效的方法是在简短的握手过程中对票证进行解密，用新密钥重新加密，然后将其发送回与服务器Hello相同的数据包中的客户端。来自RFC 5077：如果服务器成功地验证了客户机的票证，那么它可以通过在缩略握手中的ServerHello之后包含NewSessionTicket握手消息来更新票证。客户机应该在验证服务器的新连接的完成消息后尽快开始使用新票证。此用例如下图3所示，重点是对Microsoft有问题的NewSessionTicket消息：图3-服务器在缩略握手期间发出新的会话票证SChannel的问题虽然这种"内嵌"的NewSessionTicket机制在Chrome或Firefox中可以正常工作（Safari仍然不支持rfc5077），但它会给使用微软的SChannel（即运行在windows8、8.1、Server 2012、Server 2012 R2、RT、RT 8.1上的所有版本的internetexplorer、Edge和.NET版本，和10）。我们发现，在本文末尾提到的好友的出色故障排除帮助下，当Microsoft UA看到NewSessionTicket时，它要么立即中止连接并抛出异常（.NET），要么降级（！）从TLS 1.2到TLS 1.0。显然，这两种情况都不可取，但后者是一个合理的安全问题：SSL/TLS降级攻击在过去曾被利用过，将来几乎肯定会再次被利用。细节细节对于那些勇敢的人，下面是一个简单的步行通过包捕获。CloudShark上提供的第一个捕获包含初始TLS握手的单个TCP流。第二个捕获（也可以在线获取）既包括原始流，也包括建立会话的第二次尝试。简而言之，这就是发生的事情：客户端向服务器提供一个现有的会话票证。服务器"翻转"会话票证密钥。客户端在收到新票证时中止连接。客户端降级到TLS 1.0并重试。第1部分：向服务器提交票据从下面的pcap屏幕截图中可以看到，internetexplorer11客户端（192.168.2.225）启动