TLS 1.3在互联网中的部署和影响

70TLS 1.3在实践中：TLS 1.3对互联网李贤宇美国印第安纳州西拉斐特普渡大学lee3816@purdue.edu金斗元美国田纳西doowon@utk.edu诺克斯维尔田纳西大学权永熙弗吉尼亚大学美国弗吉尼亚州夏洛茨维尔yongkwon@virginia.edu摘要传输层安全（TLS）已成为互联网上安全通信的标准。2018年8月，最新版本的TLS 1.3获得批准，提供了更好的安全性，并与之前的TLS版本保持一致。 在本文中，我们通过在687M连接上应用时间、空间和基于平台的方法，从采用率、安全性、性能和实现方面仔细研究了TLS 1.3在实践中的部署。总体而言，TLS 1.3已被迅速采用，主要是由于第三方平台，如内容分发网络（CDN），为互联网做出了重大贡献。事实上，它弃用了易受攻击的加密原语，并且与TLS 1.2握手相比，大大减少了执行TLS 1.3完全握手所需的时间。我们量化了这些方面，并表明TLS 1.3对不依赖第三方平台的网站是有益的我们还回顾了与TLS库相关的常见漏洞和暴露（CVE），并表明许多最近的漏洞可以通过升级到TLS 1.3轻松解决然而，由于多个平台具有不同的TLS版本或迁移到其他平台，一些网站对TLS 1.3的支持不稳定，这意味着网站可以在某个时间或从某个地区显示较低的TLS版本。此外，我们发现大多数实现（包括TLS库）并不完全支持TLS 1.3的新功能，例如降级保护和证书扩展。CCS概念• 安全和隐私→Web协议安全。关键词TLS安全，TLS 1.3，度量，证书，TLS漏洞ACM参考格式：Hyunwoo Lee，Doowon Kim，and Yonghwi Kwon. 2021. TLS 1.3在实践中：TLS 1.3如何为互联网做出贡献。在网络会议2021（WWW '21）的会议记录，2021年4月19日至23日，斯洛文尼亚卢布尔雅那。ACM，美国纽约州纽约市，10页。https://doi.org/10.1145/3442381.34500571介绍传输层安全（TLS）[15，37]已成为事实上的用于web服务中安全通信的标准协议，本文在知识共享署名4.0国际（CC-BY 4.0）许可下发布。作者保留在其个人和公司网站上以适当的署名传播作品的权利WWW©2021 IW 3C 2（国际万维网大会委员会），在知识共享CC-BY 4.0许可下发布。ACM ISBN 978-1-4503-8312-7/21/04。https://doi.org/10.1145/3442381.3450057就像网上银行。 截至2020年10月，超过90%的互联网流量通过TLS进行通信[20]。 TLS已经从安全套接字层（SSL）发展到其最新版本TLS 1.3，增强了其旧版本的安全性和性能[25]。与TLS相比1.2 [15]例如，TLS 1.3通过删除静态RSA密钥交换来保证完美的前向保密。它还将TLS握手的往返次数从两次减少到一次，旨在提高初始设置的性能。由于TLS在Web生态系统中的重要影响，已经有许多研究旨在了解TLS的各个方面。举几个例子，Holz et al.[22]显示TLS的统计数据1.3 使用和促进其部署的因素。Naylor等人[33] Felt et al.[19]调查HTTPS（HTTP over TLS）[36]在实践中的使用。Platon等人[25]演示TLS生态系统如何应对高调的安全攻击。然而，据我们所知，新的TLS版本对生态系统的影响尚未得到彻底研究。自TLS1.3批准以来已经两年多了（8月12日）。2018年10月10日），我们认为现在是时候分析TLS 1.3在实践中的部署是否符合设计意图。在本文中，我们的目标是密切关注TLS的影响1.3 实际部署，主要关注采用、安全性、性能和实施。具体来说，我们收集了来自北美的837天每天针对Alexa前100万网站的TLS握手消息（总共6.87亿连接），以分析有多少网站采用TLS 1.3以及他们获得了哪些安全利益。此外，我们还评估了与TLS 1.3网站执行TLS握手所需的时间（12月30日为399K）。2020年第31期），与TLS1.2相比，通过升级到TLS 1.3来量化性能提升。总体而言，我们得出结论，TLS 1.3在许多方面对互联网做出了重大贡献，基于以下观察：收养。 TLS 1.3的采用率明显快于以前版本的TLS。在IETF正式批准TLS 1.3协议后，该协议仅用了264天 它比TLS1.2的采用率要快得多，TLS 1.2花了大约五年的时间才达到相同的采用率（即，15%）[4]。我们发现，第三方平台（例如，CDN）是TLS1.3早期阶段高采用率的主要贡献者，因为它们立即采用了TLS 1.3。安全TLS 1.3的采用有助于增强TLS生态系统的整体安全性然而，我们发现19.1%的TLS 1.3网站支持TLS 1.3不稳定。在采用TLS 1.3之后，与网站建立的会话的TLS版本并不总是TLS 1.3。它取决于客户端何时访问网站或客户端连接到它们的位置。这种不稳定的支持可能会削弱某个网站的安全性，71WWW网站可以在特定时间或从特定区域显示较低的TLS版本。因此，在升级到TLS 1.3时，利益相关者应该在时间和地理上仔细管理TLS版本。性能 我们的研究结果表明，TLS所需的时间与TLS 1.2相比，TLS 1.3的完全握手平均减少了57.9%- 77.1%，具体取决于地区。特别是，在第三方平台上提供服务的网站（例如，Cloudflare）通常在地理上位于客户端附近，导致27.9%另一方面，在云平台上运行的网站（通常在地理上远离客户端）的性能提升高达91.1%，这可能会促使个别网站升级到TLS 1.3，以获得更安全和更快的Web服务。实施. 我们检查TLS的新特性是否1.3在服务器端和客户端应用程序上启用，或在TLS库中实现 98个（0.03%）TLS 1.3网站不支持降级保护（详见第2节和第7.1节）。此外，在TLS 1.3获得批准后，当Web浏览器首次检查降级服务器发送的哨兵时，需要516天。许多TLS库没有实现针对证书相关扩展（如签名证书时间戳[27]和OCSP装订[34]）引入的证书扩展字段的解析模块。本文的结构如下。我们总结了TLS 1.3中具有新特性的TLS握手和我们的研究主题（§2）。然后，我们描述我们在本文中使用的数据集以及我们如何收集它们（§3）。基于数据集，我们解释了我们在采用（§4）、安全性（§5）、性能（§6）和实现（§7）方面的结果。我们回顾了相关的工作（§8），并在结束语（§9）中完成了本文。2背景动机2.1TLS 1.3协议传输层安全（TLS）是安全套接字层（SSL）的继承者，由Netscape于1994年设计。 在过去的十年中，最新的TLS版本1.3 [37]已经部署，解决了其前身的关键漏洞（即， TLS 1.2 [15]），例如BEAST和FREAK攻击[25]。TLS的标准化工作1.3于2013年8月开始，并于2018年8月完成，其中包括安全性和性能改进。 本节简要概述TLS 1.3，重点介绍与其前身TLS 1.2的显著差异。TLS 1.3的安全改进TLS 1.2容易受到中间人攻击和降级攻击。例如，POODLE[11]在回退到SSL 3.0时利用了CBC模式填充漏洞TLS 1.3引入了降级保护机制。 当客户端使用较旧的TLS版本（或SSL 3.0）协商TLS 1.3服务器时，TLS 1.3服务器必须在服务器随机数中包含两个预定义值（DOWNGRD01或DOWNGRD00）之一，作为降级信号。 此机制类似于 TLS_TLS_BACK_SCSV[32]，旨在保护会话不会因Web浏览器的TLS回退机制而降级。TLS 1.3还在证书消息中引入了证书扩展字段，以有效地处理与证书相关的TLS扩展。目前，RFC 8446描述了扩展的签名证书时间-篡改（SCT）[27]和OCSP装订[34]，但不仅限于他们。请注意，即使TLS实现具有与SCT和OCSP装订相关的功能，也需要更新TLS实现以处理新的证书消息。TLS 1.3的性能改进。TLS 1.3将握手的两个往返时间（RTT）减少到只有一个RTT。具体来说，ClientHello和ServerHello消息在TLS1.2中的第二个往返中与密钥交换消息组合。此外，还引入了early_data扩展，以无延迟地恢复与先前访问过的网站的TLS会话（所谓的对于恢复的会话，在发送应用程序数据之前没有握手过程它允许客户端将应用程序数据与第一个握手消息一起相比之下，TLS1.2在发送应用程序数据之前需要一个RTT。2.2动机在本文中，我们通过测量真实世界的网站，全面分析了TLS 1.3在实践中的部署我们从四个方面关注TLS 1.3部署的实践，每个方面都从时间，空间和基于平台的角度进行了分析。收养。 第一个方面是TLS 1.3在网站上采用的总体趋势。我们仔细研究了目前有多少网站支持TLS 1.3，以及谁在实践中领导了TLS1.3的部署此外，我们想知道根据Alexa排名或平台（例如，CDN）。 为此，我们提出以下研究问题：目前有多少网站支持TLS 1.3？具体来说，在TLS 1.3部署过程中有什么特定的趋势谁在实践中领导TLS 1.3的部署（例如，顶级Alexa网站或第三方平台？）安全TLS 1.3的主要目标之一是提高TLS的安全性。因此，我们调查了网站在升级到TLS 1.3时获得的安全优势此外，在我们的观察期内，我们可以看到网站是否稳定地支持TLS 1.3例如，如果我们观察到一个支持TLS 1.3的网站禁用了它，并退回到TLS 1.2网站，我们的目标是调查这种情况，以了解其背后的原因。我们提出的关于安全性的研究问题如下：由于TLS 1.3升级，在我们的观察期内减少了（或保护了）多少易受攻击的服务器• 现在的网站是否稳定支持TLS 1.3？性能TLS 1.3的另一个基本目标是通过简化握手过程来提高性能。我们测量了TLS 1.3与TLS 1.2相比，在不同地区完成完整握手所需的时间减少了多少。我们还分析了哪些因素可能加速或阻碍性能增益。特别是，我们提出以下研究问题：网站通过支持TLS 1.3获得了多少性能提升？各地区的业绩增长是否相似谁是具体受益人？·····72TLS 1.3在实践中：TLS 1.3如何为互联网做出贡献WWW'21，2021年4月19日至23日实施. TLS 1.3库应该正确地为用户实现，以实现TLS1.3的好处。我们测量TLS库、Web服务器和客户端应用程序如何正确地预配置TLS 1.3的新功能特别是，我们研究了ServerHello消息中的降级保护，以及证书扩展，包括signed_certificate_timestamp（SCT）和certificate_status（a.k.a，OCSP stapling）。此外，我们还回顾了常见漏洞和暴露（CVE），以了解如何正确实现TLS库 为此，我们提出以下研究问题。网站和TLS库是否已经为TLS 1.3的新功能做好了适当的准备？TLS 1.3部署是否解决了TLS库的任何漏洞3数据收集在本节中，我们将描述用于回答第2.2节中提出的研究问题的数据集。我们使用客户端应用程序制作三种类型的数据集-安全参数（D1），握手消息（D2）和平台信息（D3）1安全参数（D1）。为了了解TLS1.3的采用率和安全影响，我们收 集 了 TLS 协 议 中 的 两 个 hello 消 息 （ ClientHello 和ServerHello）。这些hello消息用于在端点之间协商TLS版本和其他安全参数。 为了收集这些数据，我们实现了一个基于OpenSSL-1的客户端应用程序。1 .一、1a实现了官方批准的TLS1.3协议。 我们的客户端应用程序将ClientHello发送到目标服务器，并在收到ServerHello后立即终止握手，记录两个问候消息和目标服务器的IP地址。每天从配备Intel Xeon E3 CPU和8GB RAM的机器上为每个Alexa 1M网站执行收集。 我们利用2018年4月生成的Alexa 1M网站的单一快照，在我们的观察期内，即从2018年9月1日开始。2018年12月17日2020年31日（共837天）。在我们的观察期间，约84%的网站被持续收集。有17天的网络中断，这是从数据集中修剪出来的。握手消息（D2）。 为了分析TLS1.3 Web服务器（12月39日为399K）中支持的TLS 1.3功能， 为了比较TLS 1.3和TLS 1.2的初始设置时间，我们还收集了TLS 1.2和TLS 1.3的完整握手消息，同时测量了建立会话所用的时间。 这些数据收集自八个不同地区的AWS计算机（2.3GHz CPU和8 GB内存）-北美东部（俄亥俄州）、北美西部（加利福尼亚州）、南美（圣保罗）、西欧（巴黎）、南非（开普敦）、东亚（首尔）、东南亚（孟买）和大洋洲（悉尼）。平台信息（D3）。 为了更好地了解谁升级了Alexa 1M网站的TLS版本，并发现由于平台而导致的任何不同趋势，我们根据负责管理TLS库的人员将TLS网站分为两类。它们可以被定义为1）第一方责任和2）第三方责任1我们将本文中使用的所有数据集、生成数据集的客户端应用程序的源代码以及分析数据集的脚本发布在公共存储库：https://github.com/tls13contribution/tls13.git责任在前者中，网站所有者负责升级TLS库，因为网站运行在基础设施即服务平台（如Amazon Web Services）上。我们将这些网站视为第一方责任（FPR）。另一方面，如果网站使用CDN网络（例如，Cloudflare）或网站构建器（例如，Squarespace）交付内容时，平台提供商负责管理TLS库;换句话说，网站所有者（或管理员）对此不负责。我们将这些网站归类为第三方责任（TPR）。为了识别两个类别（即，FPR和TPR），我们执行以下平台识别过程，如图1所示。首先，作为初步步骤，我们确定每个网站的IP地址和相关组织（的IP）。我们还准备了一个已知TPR平台的列表，例如Cloudflare，公开宣布的IP范围。第二，我们认为一个网站是FPR，如果它的域名和IP地址所有者是相同的。Google就是FPR的一个例子第三，如果网站运行在已知TPR平台列表中的平台上，则我们将该网站称为TPR第四，我们检查一个网站是否运行在任播基础设施上。具体来说，我们通过比较i）两个有利点之间的往返时间和ii）从每个有利点到每个域的往返时间之和，在先前的工作中提出[29]。如果后者明显小于前者（小于50%），我们得出结论，该IP地址可能用于任播，因此被归类为TPR。最后，如果八个不同地区的客户端与多个IP地址访问的网站之间的往返时间非常短，则我们将网站称为TPR。否则，我们将该网站归类为FPR。为此，我们将240，512个网站（60.34%）识别为FPR，158，081个网站（39.66%）识别为TPR。道德考量。为了最大限度地减少数据收集过程中的道德问题，我们限制了发送到公共服务器的请求数量。具体来说，每个域每天只执行一次TCP握手。TLShello消息与我们的客户端交换，这是微不足道的。4TLS 1.3采用在本节中，我们首先测量TLS 1.3在Alexa前100万站点中的采用率然后，我们分析了影响TLS 1.3采用的因素，得出结论，这主要是由CDN和Web托管公司等TPR平台主导的，因为它们可以同时升级TLS库。TLS 1.3随时间推移的采用率我们发现TLS的比率1.3的采用率正在持续增长-从9月11日的11.78%2018年12月17日至48.09%2020年12月31日，如图3所示请注意，TLS 1.3采用率的增长速度远远高于传统TLS版本。特别是，它只需要264天（4月。TLS 1.3（RFC 8446）正式批准后（2019年8月30日2018年10月10日）达到15%以上的采用率。相比之下，从TLS 1.1到TLS 1.2的转变需要大约五年的时间才能达到TLS 1.2批准日期后15%的采用率[4]。2 TLS 1.22TLS 1.2 RFC 文 档 于 2010 年 8 月 发 布 。 2008 年 SSL Pulse （https ：//www.ssllabs.com/ssl-pulse/）报告说，2013年6月，在 17万个流行的TLS网站中，TLS 1.2在Web服务器上的采用率超过了15%··73WWW图1：平台标识。我们将网站运行的平台分为两类，以进行基于平台的分析。第一方责任（FPR）和第三方责任（TPR）。FPR和TPR之间的重要区别在于谁负责管理TLS服务器和库。0.84×1053×1050.60.40.22×1051×1050十月一月四月七月十月一月四月七月十月一月2018 2019 2020日期0十月一月四月七月十月一月四月七月十月一月2018 2019 2020日期图2：按Alexa排名的TLS 1.3采用率。在Alexa顶级1K、10K、100K和1M站点之间，TLS 1.3的采用趋势没有显著差异。图4：由谁负责管理TLS服务器配置的TLS 1.3采用率第一方责任：Web服务器管理员负责管理其TLS服务器。第三方责任：第三方提供商负责管理TLS服务器，例如Cloudflare。4×1053×1052×1051×105Oct2018日期在流行的网站[19，23]。 我们调查TLS1.3的采用率与网站的Alexa排名之间是否存在相关性。我们考虑四种情况-Alexa顶级1K，10 K（1 K-了解相关性。我们发现，所有的箱子显示连续增加类似的模式。 如图2所示，一般来说，排名靠前的网站有更多的TLS 1.3采用率。然而，就增长率而言，排名较低的网站可能会更快地部署TLS 1.3图3：TLS 1.3平台采用率之比持续增长，每天大约增长0.042%。主要贡献者是TPR平台，其管理员可以为他们托管的所有网站升级TLS库升级主要受BEAST和斯诺登泄密等安全事件的影响[25]。另一方面，TLS 1.3正在积极部署。这促使我们调查是什么原因导致TLS 1.3如此快速的部署。热门网站和TLS 1.3. 几项研究表明，排名较高的网站可能会迅速采用新的安全功能。例如，部署了HTTPS和SMTP安全扩展有趣的是，当我们看到低于1K的网站的采用率时，它是最低的，这意味着排名最高的网站在采用TLS 1.3方面比排名较低的网站更为保守在200K和300K之间的站点比在100K和200K之间的站点显示出更高的采用率。我们的结论是，从这些观察结果来看，Alexa排名和TLS 1.3采用率之间没有很强的换句话说，TLS 1.3采用的趋势与HTTPS或SMTP安全扩展支持域的趋势不同基于平台的采用。为了更好地了解TLS1.3快速部署的主要因素，我们比较了流行平台提供商采用率的总体趋势。具体来说，我们选择了七个最受欢迎的平台提供商：TLS 1.2TLS 1.31K TLS 1.31K TLS 1.21K-10K TLS 1.3 10K-100K TLS 1.3 100K-1M TLS 1.31K-10K TLS 1.2 10K-100K TLS 1.2 100K-1M TLS 1.2谷歌SingleHopSiteGround AutomatticSquarespace InhostedCloudflareTLS 1.3总计第三方责任第一方责任总计使用TLS 1.3的TLS 1.3采用率使用TLS 1.3的JanApr7月10日JanApr7月10日Jan2019202074→→TLS 1.3在实践中：TLS 1.3如何为互联网做出贡献WWW'21，2021年4月19日至23日表1：TLS版本升级的变化大多数网站都是从TLS 1.2直接升级的，而一些网站对TLS 1.3的支持不稳定。模式FPR TPR总计1 .一、0→ 1。3 1，267（0.5%）543（0.3%）1，810（0.5%）表2：从2010年9月1日至2011年9月30日期间，对不稳定TLS1.3的网站进行了分析2018年12月17日至2020年12月31日;案例1：升级到TLS 1.3后，机器再次降级;案例2：网站将其服务器迁移或扩展到其他云或CDN网络，其中版本被降级。TPR1 .一、11. 3 20（0.0%）4（0.0%）24（0.0%）1 .一、2个1. 3 174，870（72.7%）70，265（44.5%）245，135（61.5%）1 .一、3 11，702（4.9%）63，815（40.4%）75，517（19.0%）不稳定52，653（21.9%）23，454（14.8%）76，107（19.1%）两者均为2 031人（3.9%）1 636人（7.0%）Cloudflare，Inhosted LP.，SiteGround，Squarespace Inc.，Automattic Inc. SingleHop LLC.，Google LLC.图3显示了总体TLS 1.3部署的变化以及平台提供商TLS 1.3部署随时间的变化。该线展示了总体TLS 1.3部署，而条形图显示了表3：测量了每个案例的平均（和中位数）降级天数; FPR网站的降级天数比TPR网站长。精选平台供应商我们注意到这七家公司在早期阶段涵盖了TLS 1.3的大部分支持，这意味着这些主要平台最初推动了部署速度我们还将整体趋势与FPR平台和TPR平台服务的网站趋势进行了比较。 如图4所示，结果显示TPR平台立即部署了TLS 1.3;因此，我们可以从图中观察到一些阶梯式的增长趋势。另一方面，支持TLS的网站数量1.3以上的FPR平台正在逐渐增加，呈现出与整体形态相似的趋势我们发现，在三月。到2020年，FPR平台上的网站占TLS 1.3采用的50%以上。 根据这些观察，我们得出结论，TPR平台主要在TLS1.3的早期阶段引领TLS 1.3的采用。然而，最近的增长是由FPR平台上提供的网站引起的。此外，关于平台提供者，还有两个有趣的地方. 首先，我们看到11月之间的急剧增加2018年11月11日和11月2018年16日这主要是因为Inhosted在11月11日为1，696个网站启动了TLS 1.3的支持。2018年11月14日，Squares-pace为4，789个网站启用了TLS 1.3。2018年11月15日和其他3，001个网站2018年16日第二，在2月1日和2月2日之间有一个高峰2018年10月和2月2018 年14日这与Google平台有关二月2018年10月10日，只有649个网站支持TLS1.3。2月份，TLS 1.3网站在Google上的数量增加到6，760个和11，962个网站第11和第12，分别下降到664个网站2月。月145安全TLS 1.3的主要目标之一是增强TLS的安全性。通过升级到TLS1.3，网站可以获得多项安全优势，例如强制执行前向秘密和AEAD密码套件。此外，我们还讨论了Web服务器不稳定支持TLS 1.3时的关键安全问题。5.1 保障福利为了更好地了解TLS 1.3的安全优势，我们测量了每个网站在观察期内支持的最高TLS版本。我们首先创建支持TLS 1.3的网站的TLS版本跟踪，以使用安全参数（D1）数据集查看TLS版本的每日更改（更多细节请参见第3节）。 每个跟踪由一系列三个元素组成：日期、IP地址和TLS版本。最后，我们获得了398，593个支持TLS的网站的1.3十二月31日，2020年，并找到350个不同的模式的痕迹。 我们假设不同的IP地址在这个实验中表示不同的服务器。如表1所示，大多数网站都采用了TLS 1.3。它增强了TLS生态系统的安全性值得注意的是，我们发现在我们的观察期内，61.5%的TLS 1.3网站直接从TLS 1.2升级。 只有极少数服务器（0.5%）从TLS 1.0或1.1升级到1.3。此外，有4，829个（支持TLS1.3）网站已从非前向密码套件升级为前向密码套件，为网站提供更高的安全性此外，17，094个站点通过升级到TLS 1.3将非AEAD密码套件更改为 AEAD密码套件5.2不稳定的TLS版本我们在跟踪中观察到76，107例不稳定的TLS版本：TLS 1.3在特定的一天得到支持，但稍后会回落到TLS 1.2。有4，926个高度不稳定的病例（占398，593个踪迹的 他们已经改变了他们的最高TLS版本超过十次。这种不稳定性表明这些网站并不总是保证TLS 1.3的安全性 为了理解不稳定性，我们仔细研究了9月11日以来的不稳定病例。十七日，总240 512人（100.0%）158，081人（100.0%）398，593（100.0%）别人6 012人（11.4%）1 327人（5.7%）总52 653人23 454人情况FPRTPR用例#197.4（78）80.7（47）用例#2211.5（157）121.8（43）两236.5（188）139.7（61）用例#132 013人（60.8%）5 392人（23.0%）用例#212 597人（23.9%）15 099人（64.4%）751100%WWW2018年至12月二零二零年三十一日有两种典型的场景会导致不稳定性-1）降级的服务器和2）迁移到TLS版本较低的服务器，统计数据如表2所示我们还发现，由于多平台服务，特别是当一个平台支持比其他平台更低的TLS版本时，会出现不稳定性。例如，一个网站使用三个平台服务，其中一个仅支持TLS 1.0，而其他平台则启用TLS1.3. 请注意，我们演示了1.00.501.00.50050100050 100 050 100 050 100表3. 它显示了自TLS1.3会话建立以来，网站维持其较低TLS版本的天数。5.2.1TLS版本降级 这两种情况（降级的服务器和迁移到具有较低TLS版本的服务器）可能会导致TLS版本的不稳定性。案例1：服务器降级FPR网站中最常见的情况是Web服务器的TLS版本被降级为TLS，占不稳定FPR跟踪的60.8%1.2 即使升级到1.3。例如，一个网站在12月12日开始支持TLS1.32018年18日，在我们的数据集中，但它（具有相同的IP地址）在2018年1月1日降级为TLS 1.2。2019年16日 大约三周后，它再次支持TLS 1.3。2019年8月案例2：迁移到TLS版本较低的服务器有些网站在某些时期支持TLS 1.3，但由于更改了平台而降级为TLS 1.2（例如，CDN）。例如，一个网站托管在支持TLS的平台1.3 三月之前2019年20日之后，我们发现网站的IP地址被更改为不支持TLS 1.3的另一个类似的案例占TLS 1.3 FPR网站的23.9%和TLS 1.3 TPR网站的64.4%。5.2.2区域差异。 我们调查的区域差异和TLS版本的不稳定性之间的相关性。具体来说，我们使用握手消息（D2）数据集来查看来自八个不同地区的客户端和每个TLS 1.3网站之间的会话的TLS版本我们发现了357个案例，其中来自不同地区的客户端使用不同的TLS版本建立TLS会话。例如，我们的客户端应用程序与北美东部的特定网站建立TLS 1.3会话，而与东亚的网站建立TLS 1.2会话用于连接到服务器的IP两个不同的平台，只提供TLS 1.2。我们认为这种不稳定性应该得到解决，因为网站的安全性依赖于其最低的TLS版本。知道特定网站不稳定的攻击者可能会攻击不同地区的弱服务器，以利用较低TLS版本中的漏洞。业绩改善（%）S. 美国-FPR S. Africa-FPR E. N. 美国-FPR E. 亚洲-FPRS. 美国-TPR S. 非洲-TPR E. N. 美国-TPR E.亚洲-TPR W N.东南亚-FPRW. 欧洲-FPR大洋洲-FPR W N.东南亚-TPRW. 欧洲-TPR大洋洲-TPR图5：TLS 1.3握手的延迟延迟从八个不同的区域测量。6性能增强在本节中，我们将量化TLS 1.3减少了多少延迟我们测量TLS 1.2和TLS 1.3完全握手的时间，并计算性能增益，定义为（TLS 1.3完全握手的经过时间（−（TLS 1.2完全握手的经过时间））×（）测量结果总结在表4中。TLS 1.3与TLS 1.2相比，平均性能提升超过57.9%（在西欧）。 我们观察到南非的改善最显著，因为它（平均）在地理上距离Alexa 1M网站比其他地区更远。请注意，南非到Alexa 1M网站的平均往返时间为138.08 ms，比其他地区的平均往返时间长 我们的人工检查结果显示，Alexa 1M服务器主要位于北美（东部和西部）和西欧。从观察结果中，我们得出结论，服务器和客户端之间的延迟越长，性能的改善就越显著。当我们考虑我们分析的平台时，这种趋势清楚地显示出来 如图5所示，与FPR平台上的网站相比，在TPR平台上运行的网站的延迟改善较小。这是因为TPR平台通常分布在全球范围内，因此服务器往往更靠近客户端;因此，网络距离会导致延迟性能增益的变化。注意，往返时间和FPR增益之间的相关性为0.87。7TLS库的实现在这一节中，我们将研究TLS库是否能够正确、忠实地实现TLS的新特性1.3. 具体来说，我们重点分析了实现的两个方面：1）TLS 1.3的新功能和2）常见漏洞和暴露（CVE）。 我们首先查看TLS 1.3库，检查它们是否实现了降级攻击机制和证书扩展字段的解析例程。然后我们调查外卖。 我们观察到，许多网站在将TLS版本升级到TLS1.3后获得了诸如前向保密性等安全优势。然而，我们也发现了一个安全问题，即网站不稳定地支持TLS版本。TLS版本的不稳定性发生在1）降级TLS版本和2）迁移到具有较低TLS版本的服务器时。建议Web服务器管理员在迁移到其他平台时确保支持TLS1.3。此外，当他们使用多CDN等TPR平台时，还建议他们检查其平台服务是否稳定支持来自不同地区的TLS 1.3。CDF外卖。根据上述观察，我们得出结论，TLS1.3对于因预算或其他原因而无法使用CDN服务的网站更有利我们认为，这一结果可能会促使个别网站升级到TLS 1.3，以提高安全性和性能。CDF76保护Fizz最新视频◆◆WolfSSL 4.6.0中文ⓍⓍ∗TLS 1.3在实践中：TLS 1.3如何为互联网做出贡献WWW'21，2021年4月19日至23日表4：从八个不同地区到TLS 1.3 Web服务器的平均往返时间和性能增益我们测量每个地区到Alexa前100万个网站的往返时间，以量化一个地区距离Web服务器的距离以及TLS 1.3握手的潜在好处 我们发现一个高的相关性之间的往返时间和FPR网站的平均增益（R2= 0。9）。亚洲表5：我们调查TLS库是否包含TLS 1.3的两个新特性请注意，并非所有TLS实现都支持它们。客户. 要检查Web浏览器（即，客户端）正确响应警报消息，我们进行了一个实验，其中一个积极的中间人对手执行降级攻击。具体来说，攻击者在TLS库版本降级证书扩展TLS 1.2通过删除消息中的SupportedVersion字段然后，我们将消息中继到TLS 1.3服务器。反过来，我们的Web服务器AppleCoreTLS 167BoringSSL最新文章◆ ◆MozillaNSS 3.61OpenSSL 1.1.1i ◆ ◆* ：源代码是从公共存储库克隆的二月2021年5月◆：全力支持。答：不完全支持。web服务器和web浏览器是否正确地使用这些特征。最后，我们回顾了TLS库的CVE报告，以衡量TLS实现所造成的安全威胁，特别是与TLS 1.3相关的安全威胁。因此，我们关注TLS 1.3批准后报告的CVE如表5所示，在总共七个支持TLS 1.3的TLS库中，只有BorningSSL、Mozilla NSS和OpenSSL完全支持这两个新特性。7.1 降级攻击防护回想一下，当客户端尝试通过TLS 1.2连接时，TLS 1.3通过在服务器随机值的最后8个字节中插入降级哨兵（DOWNGRD 0或DOWNGRD 1）来防止降级攻击（参见，§2）。如果客户端支持TLS1.3，则客户端必须中止与TLS1.2上的降级哨兵的连接尝试，并向Web服务器发送“非法参数”警报消息。服务器. 为了测量有多少TLS 1.3 Web服务器正确提供了降级保护，我们运行了与TLS 1.3网站执行TLS 1.2握手的客户端应用程序。然后，我们检查ServerHello消息。结果表明，大多数TLS1.3服务器在ServerHello中嵌入了降级哨兵，而98台服务器（0.03%）没有嵌入哨兵。我们发现有39台（98台服务器中的39.8%）位于可能使用Fizz[3]作为TLS库的Facebook平台请注意，Fizz没有实现降级保护机制（参见，表5）。向客户端发回包含DOWNGRD 1的ServerHello消息。我们检查我们控制的Web服务器是否收到来自Web浏览器的“非法参数”警报消息。我们的实验仅在支持TLS 1.3的Web浏览器上进行，包括Firefox （ Linux/Android ） ， Chrome （ Linux/Android ） 和Edge（Android）。结果显示，没有一个浏览器发送“非法参数”警报消息，直到Firefox（版本72）第一次理解ServerHello中的降级哨兵（截至2010年1月1日）2020年7月请注意，这是TLS 1.3获得批准后的516天（8月21日）。2018年第10期）。在此之前，所有浏览器在检测到握手消息被Finished消息篡改时都会发送一条“badmac”警报消息。Chrome于4月15日开始启用降级保护机制。2020年13日（TLS后613天1.3批准），而Edge还不支持它（版本46.01）。这可能并不重要，因为Web浏览器已经删除了不安全的TLS回退机制[2]，该机制需要降级保护机制。然而，出于兼容性的原因，浏览器供应商偶尔会启用TLS回退机制来查看服务器的容忍度[1]，这可能会导致客户端仍然暴露在安全威胁之下。7.2证书扩展TLS 1.3还在证书消息的结构中引入了扩展字段有两个示例-1）签名的证书时间戳（SCT）[27]和2）OCSP装订[34]-在[37]中描述。虽然它们不是TLS1.3的新功能，但需要对TLS实现进行修订，以解析新字段并调用与SCT和OCSP装订相关的函数。因此，我们首先检查TLS库是否正确处理证书扩展。然后，我们测量在实践中使用了多少SCT和OCSP钉合。我们发现六个TLS库中只有三个正确处理了证书扩展字段，如表5所示 这意味着如果服务器将SCT或OCSP响应与证书一起发送，则只有基于这三个库的客户端才能处理SCT和OCSP响应。东部N.美国西方N.美国南美洲西欧南非东亚东南大洋洲往返时间（ms）51.761.2102.940.5138.1120.9136.2126.6平均增益（%）76.763.166.157.976.872.977.159.0FPR增益平均值（%）84.683.386.978.991.188.987.386.4TPR增益平均值（%）69.041.145.234.358.957.866.627.977WWW表6：关于TLS库的CVE我们将漏洞分为三类：1）由于TLS1.3而引入的漏洞，2）如果采用TLS 1.3则可以解决的漏洞，以及3）与TLS的任何特定版本无关的漏洞。TLS库总第1第2第3BoringSSL2011Fizz2002Mozilla NSS3012OpenSSL250421wolfSSL182115总6221347SCT。 在39.9万个TLS 1.3网站中，有71个网站（0.02%）在证书扩展字段中包含SCT。其中，三个SCT显示签名错误。然而，许多TLS库还没有SCT相关的实现。 这意味着即使服务器端准备了SCT，许多基于TLS库而不是BoringSSL和MozillaNSS的客户端也无法解析和处理SCT。OCSP装订。 98，861个网站（占399K TLS 1.3网站的28.4%）在证书扩展字段中提供OCSP响应。在101，155