CloudFlare伦敦办事处每周举行内部技术会谈（由发言人选择免费午餐）。我最近的一篇文章解释了TLS的最新版本1.3，它是如何工作的，以及为什么它更快、更安全。你可以看下面的完整谈话，也可以阅读我的总结成绩单。更新：你可能想看我最近和扩展的33c3谈话。问答环节开始了！请将有关TLS 1.3的问题发送至tls13@cloudflare.com或者把它们留在下面的discus评论中，我会在一篇即将发表的博客文章中回答它们。.post内容iframe{margin:0；}总结成绩单为了理解tls1.3为什么很棒，我们需要退一步，看看tls1.2是如何工作的。我们将特别介绍现代tls1.2，这是最近的浏览器在连接到CloudFlare edge时使用的那种。客户机首先发送一个名为ClientHello的消息，该消息基本上是说"嘿，我想用这些密码套件之一讲tls1.2"。服务器接收到它，并用一个ServerHello来回答："当然，让我们讲tls1.2，我选择这个密码套件"。服务器同时发送密钥共享。这个密钥共享的细节会根据选择的密码套件而改变。在使用ECDHE时，密钥共享与椭圆曲线Diffie-Hellman算法混合使用。要理解的重要部分是，为了让客户机和服务器就加密密钥达成一致，它们需要接收彼此的部分，或者共享。最后，服务器发送网站证书（由CA签名）和ClientHello和ServerHello的签名，包括密钥共享，这样客户机就知道这些是可信的。客户机接收所有这些信息，然后生成自己的密钥共享，将其与服务器密钥共享混合，从而生成会话的加密密钥。最后，客户机向服务器发送其密钥共享，启用加密并发送一条完成的消息（这是迄今为止发生的事情的记录的哈希）。服务器也是这样做的：它混合密钥共享来获取密钥，并发送自己完成的消息。在这一点上，我们完成了，我们最终可以发送有用的数据加密连接。请注意，在传输HTTP请求之前，这需要在客户机和服务器之间往返两次。互联网上的往返旅行可能很慢。输入TLS 1.3。虽然TLS1.0、1.1和1.2没有什么不同，但1.3是一个巨大的飞跃。最重要的是，建立TLS 1.3连接所需的往返时间减少了一次。在tls1.3中，客户端不仅发送ClientHello和支持的密码列表，而且还猜测服务器将选择哪种密钥协商算法，并为此发送密钥共享。（注：视频称密钥协商算法为"密码套件"。同时，该规范已更改为分离支持的密码套件（如AES-GCM-SHA256）和支持的密钥协议（如ECDHE P-256）这为我们节省了往返的时间，因为一旦服务器选择了密码套件和密钥协商算法，它就可以生成密钥，因为它已经拥有客户端密钥共享。这样它就可以提前一个来回切换到加密包。所以服务器发送ServerHello，它的密钥共享，证书（现在是加密的，因为它有一个密钥！），并且已经完成了消息。客户机接收所有这些信息，使用密钥共享生成密钥，检查证书并完成，只需往返一次就可以立即发送HTTP请求。可能是几百毫秒。一种现有的加速TLS连接的方法称为恢复。这是当客户机以前连接到该服务器，并使用上次记住的内容来缩短握手时间时发生的情况。TLS1.2中的工作原理是服务器将向客户端发送会话ID或会话票证。前者只是服务器可以追溯到会话的参考号，而后者是一个加密的序列化会话，允许服务器不保持状态。下一次客户端连接时，它会在ClientHello中发送会话ID或票证，服务器会像"嘿，我知道你，我们已经就一个密钥达成了协议"，跳过整个密钥共享舞蹈，直接跳到结束，节省了往返的时间。因此，如果客户机以前连接过，我们有一种方法在1.2中实现1-RTT连接，这是非常常见的。那么1.3有什么好处呢？当恢复可用时，1.3允许我们进行0-RTT连接，同样节省了一次往返，最终根本没有往返。如果您在连接到1.3服务器之前就可以立即开始发送加密数据（如HTTP请求），而不需要任何往返，则TLS基本上没有开销。当1.3客户机连接到1.3服务器时，他们同意使用一个恢复密钥（或PSK，预共享密钥），服务器会给客户机一个会话票证，帮助客户机记住它。票证可以是PSK的加密副本，以避免状态或参考号。下一次客户机连接时，它在ClientHello中发送会话票证，然后立即发送用PSK加密的HTTP请求，而不用等待任何往返。服务器从会话票证中找出PSK并使用它来解密0-RTT数据。客户机还发送一个密钥共享，以便客户机和服务器可以为实际的HTTP响应和其余连接切换到新的密钥。0-RTT有几个注意事项。由于PSK没有与新一轮的Diffie-Hellman达成一致，它不提供针对会话票证密钥泄露的前向保密性。也就是说，如果攻击者在一年内以某种方式获得了会话票证密钥，它可以解密会话票证、获取PSK并解密客户端发送的0-RTT数据（但不能解密连接的其余部分）。这就是为什么要经常轮换而不是持久化会话票证密钥（CloudFlare每小时都会轮换这些密钥）。tls1.2根本没有提供任何前向保密性，以防会话票证密钥的泄露，因此即使使用0-rtt1.3，也是对1.2的改进。更麻烦的是重放攻击。由于会话票证服务器是无状态的，所以它们无法知道之前是否已经发送了0-RTT数据包。假设客户机发送的0-RTT数据不是一个httpget（"嘿，向我发送这个页面"），而是一个httppost，执行一个类似"hey，send Filippo 50$"的事务。如果我在中间，我可以截获ClientHello+0-RTT包，然后将其重新发送到服务器100次。不需要知道任何钥匙。我现在有5000美元。每次服务器都会看到一个会话票证，打开它来找到PSK，使用PSK解密0-RTT数据并找到里面的HTTP POST，而不知道有什么可疑的东西。解决方案是服务器不能执行在0-RTT数据中接收到的非幂等运算。相反，在这些情况下，它们应该强制客户端执行完整的1-RTT握手。这可以防止重放，因为每个ClientHello和ServerHello都有一个随机值，并且连接都有序列号，所以无法逐字重放记录的流量。谢天谢地，大多数时候客户机发送的第一个请求不是一个状态改变的事务，而是像GET这样的幂等的事务。TLS1.3不仅适用于缩短往返行程。它也是更好，更强大的密码。最重要的是，很多东西都被移走了。1.3标志着设计方法的转变：过去TLS委员会会接受任何有意义的建议，而像OpenSSL这样的实现将增加对它的支持。比如心跳，这是一种很少使用的导致心脏出血的功能。在1.3中，所有的东西都被仔细检查过是否真的是必要的和安全的，否则就作废了。很多东西都不见了：旧的静态RSA握手没有Diffie-Hellman，它不提供前向保密性然后CBC的MAC加密模式，这些模式负责杂耍，幸运13，狮子狗，幸运小20。。。被AEADs取代弱原语，如RC4，SHA1，MD5压缩重新谈判自定义FFDHE组RSA PKCS 1.5版显式nonce我们将在以后的博客文章中更详细地讨论这些问题。其中有些不一定是设计破坏的，但它们很危险，很难正确实施，而且很容易出错。tls1.3和密码学的新的优秀趋势是在设计阶段减少出错的可能性，因为人类并不完美。新版本的协议显然不能规定旧的实现的行为，1.3也不能提高1.2系统的安全性。那么，如果明天tls1.2完全崩溃，那么如何确保既支持1.2和1.3的客户机和服务器不会被代理诱骗使用1.2呢？MitM可以将ClientHello改为"我最多想谈TLS1.2"，然后使用它发现的任何攻击使1.2连接成功，即使它篡改了握手的一部分。1.3有一个聪明的解决方案：如果1.3服务器因为看起来客户端不支持1.3而不得不使用1.2，它会在服务器随机值中"隐藏一条消息"。真正的1.2版会完全忽略它，但是支持1.3版的客户机会知道要查找它，并且会发现它被欺骗降级到1.2版。服务器Random是用1.2中的证书签名的，所以即使1.2的碎片被破坏，也不可能伪造。这是非常重要的，因为它将允许我们在未来继续支持1.2，即使它被发现是较弱的，不像我们曾经做过的SSLv3和POODLE。在1.3版本中，我们将确信那些可以做得更好的客户不会面临风险，这使我们能够确保互联网适合所有人。所以这是TLS1.3。意味着未来几年互联网加密的坚实、安全、稳健、简单、必要的基础。而且它更快，所以没有人会因为性能原因而不执行它。tls1.3仍然是一个草案，在最终定稿之前可能会有所改变，但是在CloudFlare，我们正在积极开发一个与当前实验性浏览器兼容的1.3堆栈，所以现在每个人都可以得到它。TLS 1.3