TLS 1.3协议研究进展

TLS 1.3协议研究进展 Advance in TLS 1.3 Protocol Studies 1 2 first-author 张兴隆, 男，硕士生, 现从事网络密码和TLS 1.3协议方面的研究. E-mail: solace007@sina.cn 张兴隆, 男，硕士生, 现从事网络密码和TLS 1.3协议方面的研究. E-mail: solace007@sina.cn solace007@sina.cn 1 2 3 corresp 程庆丰，E-mail:qingfengc2008@sina.com 程庆丰，E-mail:qingfengc2008@sina.com qingfengc2008@sina.com 3 信息工程大学 网络空间安全学院, 河南 郑州 450004 信息工程大学 网络空间安全学院, 河南 郑州 450004 College of Cybersecurity, Information Engineering University, Zhengzhou 450004, Henan, China College of Cybersecurity, Information Engineering University, Zhengzhou 450004, Henan, China 密码科学技术国家重点实验室, 北京 100878 密码科学技术国家重点实验室, 北京 100878 State Key Laboratory of Cryptology, Beijing 100878, China State Key Laboratory of Cryptology, Beijing 100878, China 西安电子科技大学 计算机学院, 陕西 西安 710071 西安电子科技大学 计算机学院, 陕西 西安 710071 School of Computer, Xidian University, Xi'an 710071, Shaanxi, China School of Computer, Xidian University, Xi'an 710071, Shaanxi, China 传输层安全(transport layer security, TLS)协议主要用于在两个通信应用程序之间提供保密性和数据完整性.TLS 1.3协议是IETF提出的TLS协议最新标准, 具有安全性高和速度快的特点.本文介绍了TLS 1.3协议的流程；对几种重要版本之间的流程和算法进行了对比；总结了国内外公开的针对TLS 1.3协议不同版本的攻击方法；对已有研究的遗留问题进行了总结并对未来研究方向进行了预测. Transport layer security (TLS) protocol is mainly used to guarantee confidentiality and data integrity between two communication applications. TLS 1.3 protocol is the latest standard for the TLS protocol proposed by IETF, which has the characteristics of high security and fast speed. This paper studies the development process and the related algorithms of TLS 1.3 protocol, introduces the differences of detailed process and algorithms between several important versions, sums up the attack methods on different versions of TLS 1.3 protocol; summarizes the existing research issues and predicts future research directions. TLS 1.3协议 握手协议 0-RTT 安全性分析 TLS 1.3 protocol handshake protocol 0-RTT security analysis 引言 1 随着社会的发展和科技的变革, 计算机网络日益普及, 人们开始广泛地使用互联网进行工作、社交、购物、娱乐等活动.中国互联网络信息中心(CNNIC)2018年1月31日发布第41次《中国互联网络发展状况统计报告》 [ 1 1 ] 显示，截至2017年12月, 我国网民规模达7.72亿, 全年共计新增网民4074万人.互联网普及率为55.8%, 较2016年底提升了2.6%.互联网广泛应用的同时, 网络安全也成为了一个不得不重视的问题.随着各种安全问题的出现, 网络安全协议应运而生, 传输层安全(transport layer security, TLS)协议是其中一种应用较为广泛的安全通信协议.TLS协议主要工作在OSI模型中传输层和应用层之间, 用于在两个通信应用程序之间提供保密性和数据完整性. 目前关于TLS协议的综述性文章主要是从攻击或者部署的角度进行归纳总结的, 还没有涉及TLS 1.3协议版本的综述. TLS发展历程 1 最早的TLS协议可追溯到1994年网景公司提出的内部草案SSL 1.0.同年11月, 网景公司发布了SSL 2.0, 虽然这一版本存在很多的安全问题, 但是还是获得了广泛的应用.此后, 网景公司聘请了知名的安全专家, 于1995年完成并公布了SSL 3.0.在20世纪90年代微软与网景的“环球第一次商战”之中, 两大公司关于安全工作也进行了针锋相对的竞争.网景推出SSL 2.0后, 微软于1995年10月发布了保密通信技术(private communication technology, PCT).1996年5月, 互联网工程任务组(internet engineering task force, IETF)启动了SSL相关协议的标准化工作, 决定将标准化之后的协议命名为TLS.1999年1月, TLS 1.0 [ 2 2 ] 的RFC(request for comments)正式发布. 此后, IETF不断对TLS协议进行修改和完善, 相继提出了更新的版本TLS 1.1、TLS 1.2和TLS 1.3.其中TLS 1.1 [ 3 3 ] 添加了针对CBC(cipher-block chaining)块攻击的防护；TLS 1.2 [ 4 4 ] 修改了加密套件和握手协议中的算法, 将原来的MD5-SHA-1算法替换为SHA-256算法, 还做了一些扩展, 例如身份认证加密技术(authenticated encryption ciphers)和高级加密标准(advanced encryption standard, AES)等, TLS 1.2对TLS会话中通过协商使用SSL 2.0不安全协议不再支持.目前, IETF提出了新一代标准——TLS 1.3协议(简称TLS 1.3).从IETF在2014年4月发布第一个TLS版本的草案至2018年3月4日, 共有27个版本的草案面世, 平均不到两个月就会有新版本的草案被提出.截至目前, 最新版本的草案是2018年3月4日IETF挂出的draft-ietf-tls-tls13-26 [ 5 5 ] . TLS协议发展如 图 1 图 1 所示. 与TLS 1.2相比, TLS 1.3删除了一些加密性能比较弱且更少使用的加密算法如椭圆曲线密码算法 [ 6 6 ] 、MD5 [ 7 7 ] 、SHA-224 [ 8 8 ] 等, 弃用静态加密算法RSA [ 9 9 ] , 添加新的Ed25519 [ 10 10 ] 这一更加安全的数字签名算法, 添加新的密钥交换协议等, 其安全性和效率方面的优越性正逐步显现出来.随着对TLS 1.3研究的不断深入和标准化进程的快速推进, 越来越多的人开始关注这一未来标准. 2016年9月, CloudFlare宣布在他们的服务器上添加了对TLS 1.3的支持.2016年10月20日, Mozilla宣布将在2017年发布的Firefox 52中支持TLS 1.3.此外, 其他主流的浏览器厂商如微软和谷歌也分别宣布在Edge和Chrome Canary中支持TLS 1.3. 本文主要从TLS 1.3的流程细节、TLS 1.3与TLS 1.2的主要区别、TLS 1.3草案的各版本之间的区别等几个方面对TLS 1.3工作机制进行阐述；详细介绍了近年来关于TLS 1.3的分析和攻击方法；对已有攻击方法和研究现状进行了归纳总结并预测了未来可能的研究方向. TLS 1.3描述 1 TLS 1.3由两层组成：记录协议(record protocol)和握手协议(handshake protocol).较低层为TLS记录协议, 位于某个可靠的传输层协议(例如TCP)上面.TLS 1.3握手协议包括握手协议和警告协议(alert protocol). 记录协议 2 记录协议是一种分层协议, 这种协议被用来封装几种高层协议(如HTTP, SMTP等).使用由TLS握手协议产生的安全参数, 记录层首先将上层被传输的数据分片成便于管理的块, 然后对数据有选择性地压缩, 计算出消息认证码MAC(如MD5或SHA), 加密(如NULL, DES, 3DES), 最后将结果输出. 图 2 图 2 是TLS记录的主要组成部分.TLS记录协议负责以下三项任务：传输数据，将数据分片(转换成为易于管理的数据块)，加密记录并且传输加密结果.接收到的数据被解密、验证、重组, 然后交付给更高级别的客户端. TLS以记录协议(record protocol)作为其实现方式.记录协议负责在传输连接上交换所有的底层消息, 并可以配置加密.每一条TLS记录以一个短标头起始.标头包含记录内容的类型(或子协议)、协议版本和长度.消息数据紧跟在标头之后. 记录协议从多个重要的宏观角度如消息传输、加密以及完整性验证、压缩、拓展性等方面对通信进行考量, 是一个很有用的协议抽象. 握手协议 2 TLS 1.3握手协议用来产生会话状态的密码参数, 这些参数包括TLS客户端和服务器选择的协议版本、加密算法、相互认证、建立的共享密钥等.一旦握手完成, 通信实体使用已经建立的密钥来保护应用层通信(见 图 3 图 3 ). 握手协议包括三个过程： 1) 密钥交换：建立共享的密钥并且选择密码参数.在这个过程之后的所有通信都是经过加密的； 2) 服务器参数：建立其他的握手参数.例如是否进行客户端认证、支持何种应用层协议等； 3) 认证：对服务器进行认证(包括可选的客户端认证)并且提供密钥确认和验证握手完整性功能. 在密钥交换过程中, 客户端发送ClientHello消息(包含一个随机数、一个协议版本、一系列的密码算法套件、一些D-H密钥交换的集合以及一些预共享密钥交换的集合等).服务器处理ClientHello消息并响应ServerHello消息确定用于连接的加密参数，然后，服务器发送两个消息来建立服务器端的参数. 1) EncryptedExtensions消息：响应那些不决定密码算法的拓展. 2) CertificateRequest消息：如果要求对客户端进行认证的话, 此消息用于请求客户端的证书参数. 此后, 服务器和客户端分别对证书进行验证, 双方各自发送Finished消息, 这条消息包含了之前所有握手消息的认证码(message authentication code, MAC), 这样做是为了防止通过篡改握手消息实现的降级攻击. 警告协议 2 TLS 1.3记录层支持的消息类型之一是警告类型, 和其他消息一样, 警告消息也按照指定的加密方式进行加密.警告的目的是以简单的通知机制告知通信出现异常情况, 警告消息通常会携带Close_notify异常, 在连接关闭时报告错误.Alert_Level字段标识警告的严重程度, 可取值Warning或者Fatal.严重程度为Fatal的消息会立即终止当前连接并使会话失效.发送警告通知的一端不会主动终止连接, 而是由接收端发送严重警告并对该警告自行做出反应. 关闭连接警告(closure alert)用于以有序的方式关闭TLS连接.一旦一端决定关闭连接, 就会发送一个Close_notify警告, 另一端收到这个警告后会丢弃还未写出的数据, 并发送自己的Close_notify警告.这个关闭协议虽然简单, 但是可以有效地避免截断攻击. TLS 1.3与TLS 1.2的差异 1 当前普遍使用的TLS 1.2协议 [ 4 4 ] 在2008年被确定为标准, 目前被大多数浏览器和使用HTTPS的Web服务器所支持 [ 11 11 ] .虽然在一般情况下, TLS 1.2可以保证浏览器和Web服务器的安全, 但是过去几年出现的一些影响较大的攻击行为暴露出TLS 1.2存在的安全缺陷, 这也是IETF着手开发该协议的新版本TLS 1.3的重要原因. TLS 1.3与TLS 1.2相比，最显著的两个优势就是安全性和高速性.为了达到安全新要求, TLS 1.3将TLS 1.2版本中的大量特性删除, 根据一些已经发生的攻击行为 [ 12 12 ~ 14 14 12~14 ] 取消了对不安全加密方式的支持. 表 1 表 1 列出了TLS 4个版本的特点, 表 2 表 2 给出了TLS 1.3(相较于TLS 1.2)不支持的算法. 版本 特点 TLS 1.0 1)结合SSL 2.0和SLTP做出的标准; 2)建立在SSL 3.0协议规范之上, 是SSL 3.0的后续版本; 3)使用“消息认证代码的密钥散列法(HMAC)”; 4)提供更多的特定和附加警报 TLS 1.1 1)添加了CBC模块攻击的保护; 2)提前关闭会话不再导致会话不可恢复; 3)增加了关于TLS的各种新攻击的附加信息注释; 4)填充错误的处理方式更改为使用Bad_record_mac警报 TLS 1.2 1)对加密套件和握手协议中的算法做了改进; 2)用SHA-256代替原来的MD5-SHA-1; 3)对发送警报的时机进行了扩展; 4)基本清理客户端和服务器的能力, 指定他们将接受哪些哈希函数和签名算法 TLS 1.3 1)删除了一些加密性能较弱的算法; 2)添加新的密钥交换协议; 3)删除更改密码规范协议; 4)增加0-RTT握手协议 删除的算法 原因 RSA密钥传输 不支持前向安全性 CBC模式密码 易受BEAST [ 13 13 ] 和Lucky13 [ 14 14 ] 攻击 RC4流密码 在HTTPS中使用并不安全 SHA-1哈希函数 建议以SHA-2取代 任意Diffie-Hellman组 CVE-2016-0701漏洞 [ 15 15 ] 输出密码 易受FREAK和LogJam攻击 在网络中RTT(round-trip time)是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认)，总共经历的时延即往返时延.RTT由三个部分决定：链路的传播时间、末端系统的处理时间以及路由器缓存中的排队和处理时间.其中，前面两个部分的值作为一个TCP连接相对固定，路由器缓存中的排队和处理时间会随着整个网络拥塞程度的变化而变化.所以RTT的变化在一定程度上反映了网络拥塞程度的变化. 在网络协议中，RTT代表了协议的实现效率.2-RTT表示需要两个往返时延的时间；1-RTT表示需要一个往返时延的时间；0-RTT表示零往返时延.在TLS 1.3中，新增加的“0-RTT”模式大大缩短了协议的实现时间，增加了效率. 完整握手的差异 2 静态RSA算法 3 静态RSA算法最早应用在SSL 2.0中, 一直延续使用到TLS 1.2.在客户端和服务器通过ClientHello消息和ServerHello消息共享基本的协议信息后, 服务器向客户端发送他的证书.ServerHelloDone消息表示从此时开始到客户端响应之前将不会再有消息交互. 客户端使用服务器证书中服务器的公钥对预主密钥进行加密, 并将其封装在ClientKeyExchange消息中. ChangeCipherSpec消息表示此消息之后发送的消息将被加密.Finished消息作为客户端在握手协议过程中发送的最后一条消息和使用协商好的加密参数进行加密的第一个消息, 包含交换的所有消息的MAC值. 服务器使用其私钥解密在ClientKeyExchange消息中被加密之后的预主密钥，得到预主密钥, 并导出主密钥和通信密钥.然后，服务器发送Finished消息通知客户端握手完成并切换到加密通信阶段，此时需要两次往返才能建立连接. 图 4 图 4 是使用静态RSA密钥交换的完整TLS 1.2握手. 静态RSA密钥交换的认证原理是通过使用服务器证书的公钥加密预主密钥来进行认证.只有拥有相应私钥的服务器可以解密预主密钥并导出主密钥, 并且发送包含正确MAC值的加密Finished消息. 静态RSA有一个很严重的缺点：不提供前向安全.如果被攻击者窃听了所有的通信消息并且获取了服务器私钥, 那么所有被窃听的TLS会话都将被攻击者解密. TLS 1.3删除了不能确保前向安全的静态RSA算法, 并且删除了Change-CipherSpec协议, 增加了Encrypted-Extensions消息.TLS 1.3握手中每个在ServerHello消息之后发送的消息都是由临时密钥加密的, 这是为了防止被动攻击者窃听通信消息. 1-RTT 3 1-RTT最重要的更改是删除了ServerKeyExchange和ClientKeyExchange消息.TLS 1.3将D-H参数和公钥在特殊的KeyShareextensions中发送, 这是一种包含在ServerHello和ClientHello消息中的新类型的拓展.将此数据放入Hello拓展中也可以使得TLS 1.3握手与TLS 1.2兼容, 因为它并没有改变消息的顺序. 图 5 图 5 是使用D-H密钥交换的TLS 1.3握手. 客户端发送KeyShareEntry值的列表, 每个值由一组D-H参数和临时公钥组成, 服务器选择接受的参数并响应该D-H参数和自己的公钥.如果服务器不支持任何给出的KeyShareEntry值, 那么服务器将请求重试握手或者终止连接. 认证 3 TLS 1.3中的认证更加明确, 不会再使用D-H参数进行签名.服务器将发送一个Certificate-Verify消息, 该消息包含到目前为止交换的所有握手消息的哈希值, 该消息用服务器的私钥进行签名, 客户端使用证书中的公钥验证签名. 恢复握手的差异(预共享密钥模式) 2 完整的握手需要两次往返时间, 因而具有很高的延迟, 而且完整握手需要进行的密钥交换、签名、验证签名以及公钥密码计算等操作费时, 因此, 会话恢复十分重要.由服务器分配的会话ID是标识双方存储的主密钥和建立的连接的惟一标识.客户端可以将该ID包括在下一次握手的ClientHello消息中，以协商和重用先前连接的参数. 如 图 6 图 6 所示, 在TLS 1.2中, 服务器发送ServerHello消息响应客户端的恢复会话请求，为客户端分配惟一的会话ID.因为服务器可以在发送Finished消息后立即发送应用数据, 故该握手实际上是1-RTT时延的. 如 图 7 图 7 所示，还可以使用会话票据(session tickets)来进行会话恢复.由服务器创建并由客户端存储的会话票据包含所有关于连接的必要信息, 它由服务器加密.如果客户端向服务器发送包含此票据的ClientHello消息并且证明它知道票据中存储的主密钥, 那么服务器会发送一个包含空会话票据的ServerHello消息响应.与使用会话ID一样, 该握手是1-RTT时延的. 为了满足前向安全性, 会话票据密钥应该周期性更换, 否则攻击者成功窃取某一次的会话票据密钥将会使得所有被窃听的会话被恢复出来. 以上两个会话恢复机制都保留了在初始握手中建立的客户端和服务器的认证状态, 因此服务器和客户端不必再发送和验证证书, 这也减少了连接时间. TLS 1.3不再使用会话标识符和会话票据进行会话恢复, 这两种方式都被预共享密钥模式(pre-shared key, PSK)取代.如 图 8 图 8 所示. 预共享密钥模式就是在上一次握手完成之后在连接上建立预共享密钥, 然后客户端在下一次访问服务器时重用该预共享密钥. 客户端向服务器发送一个或多个PSK标识.这些PSK标识既是查找数据库的密钥(类似于会话ID), 又是自加密和自认证的密钥(类似于会话票据).如果服务器支持会话恢复, 则选择一种PSK标识作为响应. TLS 1.3会话恢复的认证和TLS 1.2中一样, 客户端和服务器的认证状态都被保留, 双方不需要再发送和验证证书. TLS 1.3增加0-RTT握手 2 自TLS 1.3的版本7开始, 协议建议客户端加密应用数据并将其包含在第一批发送的消息中.在首次握手完成后, 服务器会发送一个ServerConfigu-ration消息, 客户端可以利用此消息在接下来的连接中使用0-RTT握手.ServerConfiguration消息包含一个结构标识符、服务器的半静态(elliptic curve, EC)D-H参数、截止日期和其他细节. 如 图 9 图 9 所示, 客户端发送ClientHello消息并且改变消息的顺序——直接在后面附加应用数据(例如GET和HTTP数据等).在ClientHello消息后的一切消息都将使用静态密钥加密, 该静态密钥是由客户端的临时KeyShareEntry值(也就是客户端选定的D-H参数)和由服务器配置中给定的半静态D-H参数共同导出的.“end_of_early_data”警告消息标志着客户端发送完毕. 服务器如果可以解密客户端发送的应用数据, 则使用其默认消息集来响应, 并且立即发送客户端所请求的消息.ServerHello消息之后的所有消息都将会使用临时密钥加密, 该临时密钥是由客户端和服务器的临时密钥参数导出的.在双方发送完Finished消息后服务器会被重新认证, 接下来发送的应用消息将会使用由主密钥导出的会话密钥加密. 0-RTT握手的安全性 2 0-RTT模式看起来类似于会话恢复或者PSK模式, 但它们之间还是存在重要的差异.0-RTT握手的安全属性弱于其他类型的TLS数据的安全属性，这是因为： 1) 为了防止重放攻击, 服务器必须在主密钥中包含一个随机数. 2) 用来导出静态密钥的在服务器配置中给出的半静态D-H参数是不能提供前向安全性的.我们需要至少一次往返来建立临时密钥.由于服务器配置是可以在客户端之间共享的, 所以会吸引一些恶意客户端尝试去恢复服务器D-H参数, 这就要求对参数的使用截止日期进行限制, TLS 1.3规定允许的最大有效期是7 d. 3) 如果服务器的D-H参数共享受损, 那么此时中间人攻击者可以篡改由客户端发送的0-RTT数据而不会被检测到.这种攻击不会拓展到整个会话, 因为客户端可以通过剩余的握手消息对服务器进行再一次认证. TLS 1.3各版本草案差异 1 随着TLS 1.3标准化的推进, 协议细节不断完善, 截至2017年7月3日, IETF已经发布了22个版本的草案.其中如版本5 [ 15 15 ] 、版本10 [ 16 16 ] 、版本13 [ 17 17 ] 、版本18 [ 18 18 ] 等引起了学术界的广泛讨论和分析, 针对相应版本的研究文章也有很多, 对于TLS 1.3旧版本的分析也促进了新版本的制定工作. 表 3 表 3 详细总结了20个版本的具体改进和变化. 版本 特点 Draft-02 1)增加版本号；2)提供1-RTT模式；3)删除了对静态RSA和D-H密钥交换的支持；4)删除了对压缩的支持；5)删除了对Non-AEAD的支持 Draft-03 1)删除格林威治时间；2)合并RFC4492中对ECC算法的支持；3)重命名{Client, Server}KeyExchange；4)添加明确的HelloRetryRe-quest Draft-04 1)修改了密钥计算方法；2)删除了ChangeCipherSpec协议；3)将新的握手消息重新编号；4)删除了重新协商机制 Draft-05 1)禁止SSL协商 Draft-06 1)禁止RC4算法；2)弃用记录层版本字段；3)使用上下文更新签名格式；4)删除Ⅳ Draft-07 1)增加了初始0-RTT握手；2)替换了PSK+会话票据模式；3)ClientKeyShare消息改为拓展；4)增加了HKDF Draft-08 1)删除签名使用的MD5算法和SHA-224算法；2)AEAD允许的最大记录拓展减少到256字节；3)先前的配置也需要使用数字签名；4)更改Server_configuration的代码点 Draft-09 1)对握手消息改为RSA-PSS签名；2)删除对DSA算法的支持；3)更改HKDF标签使其包括协议版本和长度值；4)不建议使用签名算法，建议使用SHA-1；5)添加MTI算法 Draft-10 1)删除ClientCertificateTypes字段；2)将客户端和服务器密钥共享合并 Draft-11 1)统一认证方式；2)增加了握手后客户端认证；3)删除“Early_handshake”内容类型；4)密钥改变时重置序列号 Draft-12 1)提供PSK密码套件列表；2)将Ticket有效期限定为一周；3)声明服务器可以在第一个数据流发送完之后发送应用数据(0.5RTT) Draft-13 1)允许服务器发送SupportedGroups消息；2)删除了0-RTT客户端认证；3)删除了KeyShareEntry冗余长度字段；4)删除了(EC)DHE 0-RTT Draft-14 1)允许在Fatal_alert警告后恢复会话；2)制定了0-RTT的限制规则；3)阐明0-RTT和PSK如何进行身份交互；4)添加数据限制部分描述 Draft-15 1)禁止了空的Ticket；2)增加0-RTT时间窗口的引导；3)删除旧的PRNG文本 Draft-16 1)修改版本协商；2)完善RSASSA-PSS和EdDSA签名的向后兼容性；3)添加新的Certificate_required警报；4)禁止用0-RTT和PSK进行认证 Draft-17 1)重组PSK密钥交换协议模式；2)将SCT和OCSP转换为证书；3)明确允许使用0-RTT和PSK的条件；4)使用一种警告消息终止0-RTT数据 Draft-18 1)修改Signature_algorithms；2)删除不必要的Resumption_PSK；3)修复拓展表中的签名算法 Draft-19 1)重新构造证书；2)“Ticket_early_data_info”和“early_data”合成一个扩展；3)将“end_of_early_data”变成一个握手消息；4)要求对等公共密钥验证；5)添加状态机 Draft-20 1)添加“Post_handshake_auth”扩展进行握手后的协商验证；2)HKDF-Expand-Label缩短标签；3)重新启用后握手客户端身份验证；4)no_application_protocol-alert引入TLS 1.3拓展；5)增加了对流量分析和旁路攻击的讨论 Draft-21 1)增加“Per-ticket”随机数；2)明确客户端需要与握手密钥一起发送警告；3)推荐一些抵抗重放攻击机制 TLS 1.3攻击现状 1 在TLS 1.3不断完善的进程中, 很多学者对其不同版本的草案进行了分析和攻击尝试, 这在一定程度上促进了TLS 1.3的不断完善和标准化.本部分从不同角度对近几年针对TLS 1.3的攻击现状进行综述. 对握手协议的分析 2 2015年的研究主要表现在以下几个方面： 1) Dowling等 [ 19 19 ] 在ACM CCS会议上针对draft-ietf-tls-tls13-0和draft-ietf-tls-tls13-dh-based草案版本给出了基于Diffie-Hellman握手协议的加密分析, 该握手协议对客户服务器双方进行认证并建立客户和服务器之间的共享会话密钥.作者提出了一种多级密钥交换安全的概念, 证明了该多级密钥交换安全概念可以与任意对称密钥协议组合, 因此记录层所使用的会话密钥是安全的.此外, 他们将TLS 1.3恢复握手阶段看成对称密钥协议, 证明了该组合分析方法可以用于分析恢复握手协议的安全性. 2) Holz等 [ 20 20 ] 调查了电子邮件和聊天基础设施的安全性, 他们在整个互联网范围内扫描来确定安全服务设施的数量, 基于服务器的主动扫描和客户端的被动监听收集了用于建立SSL/TLS会话的参数, 发现了大规模的不安全的服务器, 这些服务器依然提供弱的应用程序身份认证方法.作者除了研究基于TLS协议的应用协议在传输层上提供的认证和加密机制之外, 还研究了在应用层上使用客户端认证的机制.他们在相关协议认证机制的选择方面给出了一些建议. 3) Bhargavan和Leurent [ 21 21 ] 指出虽然大部分软件供应商已经开始逐步淘汰在第三方数字签名应用(如X.509证书等)中使用MD5和SHA-1算法, 但是在TLS、IKE和SSH这些主流安全协议中仍然在使用这种弱散列函数, 因为设计者认为它们在这些协议中的使用仅依赖于第二原像稳固特性, 因此不受可能存在的碰撞的影响.Bhargavan和Leurent发现了一种针对密钥交换协议的新型的记录碰撞攻击, 该攻击依赖于对底层哈希结构的有效碰撞发现算法.他们还具体实施了针对TLS 1.2客户端身份验证的证书转发攻击和针对TLS 1.3服务器身份验证和通道绑定的证书转发攻击.他们详细介绍了针对TLS的实际攻击SLOTH, 该攻击已经导致了几个TLS库的安全更新.作者建议在所有主流网络安全协议中禁用MD5和SHA-1等弱散列函数, 该建议已被纳入TLS 1.3中. 4) Li等 [ 22 22 ] 在IEEE S & P会议上提出了一个多级多阶段安全模型, 该模型是对Bellare-Rogaway认证密钥交换模型的一个变体.他们证明了该模型涵盖不同TLS握手模式之间的各种交互并提供了相当的安全保护.TLS 1.3草案的握手协议符合多次握手安全的概念, 证明了TLS 1.3安全保护设计的健全性.该多阶段安全模型具有普遍适用于具有不同会话模式的通信协议的特性. 5) Jager等 [ 23 23 ] 指出TLS中RSA默认的填充方式是PKCS#1v1.5, 此方式易受到旁路攻击.虽然TLS 1.3已不支持PKCS#1v1.5, 但是这仍然不足以避开其弱点.以下是一个简化了的中间人攻击的例子(流程如 图 10 图 10 ). Step 1   客户端C发送TLS 1.3 ClientHello和ClientKeyShare消息. Step 2   攻击者A截获信息, 选择TLS-DHE-RSA, 向C回答ServerHello消息, 其中包含了D-H指数. Step 3   A向服务端S发送ClientHello消息, S返回ServerHello消息和它的证书.A用该证书应答C. Step 4   为了完成TLS 1.3 Session的建立, A需要计算CertificatVerify, 包含之前握手信息的签名.攻击者利用PKCS#1 v1.5的Oracle构造一个RSA签名. Step 5   A和C完成握手后, 就实现了中间人攻击. 这个攻击是Online的, 在客户端没有发起ClientHello消息时, A是无法构造RSA签名的.攻击的可行性在于利用Oracle构造签名的时间要短于客户端断开连接的时间. 2016年的研究有： 1) Dowling等 [ 24 24 ] 分析了草案TLS 1.3 draft-ietf-tls-tls13-10的握手协议, 延续并扩展了之前关于TLS 1.3草案的分析, 进一步说明了草案10提供了所有导出密钥的前向安全性.遗憾的是, 协议的模块化分析不再可行, 特别是由于在draft-10中引入了一个名为NewSessionTicket的新消息, 因此应用程序传输密钥的组成在其通用形式中是不可能的.此外, 他们还分析了draft-ietf-tls-tls13-10的预共享密钥握手模式(PSK和PSK-DHE), 该模式取代了draft-ietf-tls-tls13-05中的恢复握手模式.两个协议都从先前建立的密钥开始以导出新密钥, 但是PSK-DHE模式在开始时添加了另一个Diffie-Hellman密钥协商步骤.PSK握手只实现了密钥安全, 无法保证前向安全性, 这与之前分析的draft-ietf-tls-tls13-05是一样的.对于PSK-DHE握手, 预共享密钥和临时Diffie-Hellman密钥的组合实际上实现了前向安全性. 2) Krawczyk [ 25 25 ] 在ACM CCS会议上提出了一个简单有效的编译器, 能将单向认证(UA)密钥交换协议升级到互相认证(MA)密钥交换协议, 同时证明了一大类UA协议可以由此工具编译从而完成转换.该工具主要是针对正在进行标准化的TLS 1.3协议提出的, 尤其是针对客户端认证机制.Krawczyk提出的方法支持以一般和模块化方式对认证机制进行分析, 在“功能安全”概念的辅助下引入了一个广义的密钥交换模型. 3) Somorovsky [ 26 26 ] 在ACM CCS会议上提出TLS攻击模型TLS-Attacker, 这是一个用于评估TLS库安全性的开源框架.TLS-Attacker允许安全工程师使用简单的接口创建自定义TLS消息流和任意修改消息内容.基于TLS攻击者, 他还提出了一个两阶段的模糊方法来评估TLS服务器行为.该方法自动搜索加密失败和边界漏洞的情况.它可以在广泛使用的TLS库(包括OpenSSL、Botan和MatrixSSL)中发现异常的填充Oracle漏洞和溢出漏洞. 对记录协议的分析 2 1) 2015年, Levillain等 [ 27 27 ] 基于TLS 1.3的主要应用HTTPS，提出了对TLS 1.3记录协议的安全性分析, 指出现有的防护措施通常是针对特定的攻击, 有时甚至是相互矛盾的.所以他们对TLS 1.3记录协议进行了深入的安全性分析并提出了针对一般攻击方法的深入防护对策.Levillain等 [ 27 27 ] 首先列举了从2011年到2014年针对TLS记录协议的一些攻击实例，如BEAST、CRIME、TIME、Lucky 13、RC4 biases、POODLE等.在此之后又对这些攻击进行了对比分析, 综合分析结果给出了一种屏蔽机制并且分析了该机制的安全性和高效性. 2) 2017年, Bhargavan等 [ 28 28 ] 就TLS 1.3记录协议进行分析, 构建记录层的安全模型, 计算AES-GCM和ChaCha20-Poly1305密码套件的具体安全范围, 实现了第一个可验证的TLS 1.3记录协议.他们将记录层的实现插入到现有的TLS库中, 并确认该组合与Chrome和Firefox可以进行互操作. 对0-RTT的分析 2 1) 2016年, Krawczyk和Wee [ 29 29 ] 提出了用于TLS 1.3协议的密钥交换协议OPTLS协议, 给出了OPTLS协议的设计原理和密码性质分析.OPTLS协议的主要目的就是保证TLS 1.3的0-RTT要求, 同时使得前向安全性成为强制性要求, 并且使椭圆曲线成为协议的主要加密基础. OPTLS提供了一个简单的设计框架, 该框架可以支持以上所有要求.同时OPTLS统一和模块化的逻辑有助于协议的规范、分析、性能优化和未来维护.TLS 1.3版本9的草案(draft-ietf-tls-tls13-09)采用了OPTLS框架的4种工作模式和密钥导出方法. 2) 2017年, Fischlin和Günther [ 30 30 ] 使用重放攻击的手段对TLS 1.3协议中的0-RTT握手进行分析.他们分析了draft-ietf-tls-tls13-12中基于Diffie-Hellman的0-RTT握手的密钥保密性和draft-ietf-tls-tls13-14中基于预共享密钥的0-RTT握手的密钥保密性；扩展了以前的安全模型, 同时阐明重放攻击下0-RTT安全性的限制.虽然他们也强调了对TLS 1.3草案的分析应当被认为是正面地讨论其密码强度而非恶意地对其进行攻击，但是所用到的重放攻击的方法对TLS 1.3草案和谷歌的QUIC协议还具有很大威胁, 其他研究者可以从这方面入手对这两个协议进行分析研究. 3) 2017年, Günther等 [ 31 31 ] 提出了一种新的0-RTT密钥交换协议的构想, 即利用同步时间来构建一个0-RTT密钥协商协议, 但是只讨论了协议架构而并未涉及具体算法.他们指出解决0-RTT密钥协商协议前向安全和重放攻击的问题, 关键思想不是修改协议, 而是修改服务器处理和存储密钥的方式.他们提出了增加一个时间元件, 这个时间元件要求客户端和服务器维护一个同步时钟.在每个时间间隔内, 密钥长度线性增长, 但是在一个时间段结束时, 服务器可以“清空”密钥, 就是说将密钥长度减少到时间间隔的对数因子，这就在效率方面解决了密钥长度线性增长的问题. 协议实现 2 1) 2016年, Moghimifar和Stebila [ 32 32 ] 开发了一个在TLS上基于单个加密操作运行时间的保护模型，用于控制Web服务器的每秒连接数量.该模型允许我们预测系统性能与文件大小的比例.该模型还可以预测改进的密钥交换算法对连接速度的影响.例如, 在1 KB文件的HTTPS服务器上运行具有AES-128-GCM和HMAC-SHA-256的ECDSA-nistp256算法, 临时Diffie-Hellman密钥交换性能2倍的提升仅仅使连接速度提升10%. 2) 2017年, Bhargavan等 [ 33 33 ] 研究了TLS 1.3能否抵抗现有的一些攻击和实现问题.他们就TLS 1.3草案版本18建立了安全模型并用JavaScript代码进行了实现, 建立了能够互操作的TLS 1.0~1.3的协议——RefTLS, 分析了协议的安全性, 证明了其能够抵抗现有攻击. 此外, 随着对TLS 1.3研究的不断深入, 国内外还有很多相关的文章发表在一些著名的期刊或者会议上 [ 34 34 ~ 47 47 34~47 ] .例如，2016年Cremers等 [ 48 48 ] 使用Tamarin验证程序分析了TLS 1.3 draft-ietf-tls-tls13-10, 该工作为TLS 1.3中几种复杂协议模式交互的安全性提供了第一个证据；2016年CCS会议上, Zhang等 [ 49 49 ] 介绍了一种使用代数消息认证码设计匿名密码认证密钥交换(APAKE)协议的新方法, 可将APAKE集成到TLS中以呈现匿名客户端认证模式, 极大地提高了认证效率；2016年, Fischlin等 [ 50 50 ] 首次提供了严格的正式化密钥确认, 通过分析证明了TLS 1.3 draft-ietf-tls-tls13-10版本中可以在完全握手中实现客户端和服务器的密钥确认. 总体上看, 近年来国内外对于TLS及相关协议如SSL、OpenSSL、HTTPs等的研究呈上升趋势.自2013年以来, 在安全领域的顶尖会议如ISOC NDSS、IEEE Security and Privacy、USENIX Security和ACM CCS上, 关于TLS的研究有近50篇论文, 其中对于TLS 1.3协议的研究占据了相当的比重. 通过查阅大量文献发现, 当前大部分攻击都是通过向终端注入恶意代码来破坏终端完整性, 进而窃取通信内容, 这就导致了现有TLS协议面临一个无法避免的问题：当终端的完整性处于未知状态时, 使用TLS协议构建的安全隧道与其进行通信就会存在泄露通信内容的风险.通过这种方式可以对TLS 1.3协议进行攻击, 从而获取通信内容.根据文献显示, 2016年徐震等 [ 51 51 ] 提出了可信增强的方法, 即利用可信计算组织(TCG)有效解决上述问题, 但是上述方法建立可信TLS连接的时间大约是建立标准TLS连接的3~4倍, 影响用户上网体验, 所以目前广泛应用的TLS协议以及TLS 1.3协议仍然没有对这方面进行改进, 研究者可以尝试进行攻击. 2017年2月23日, 谷歌宣布找到了SHA-1攻击方法的实例.这一举动震惊了密码学界, 这意味着曾经被广泛应用的SHA-1算法被宣判了死亡.值得一提的是, 早在2015年10月5日发布的draft-ietf-tls-tls13-09草案关于SHA-1算法就作出了“Deprecate SHA-1 with signatures”的声明，禁用了SHA-1算法, 有效地防止了这一冲击. 同样值得一提的是, 近几年利用格基约化算法对网络协议如HTTPS以及OpenSSL中签名算法ECDSA的攻击研究进展迅速.目前已知最好结果是2016年ACM CCS会议上Fan等 [ 52 52 ] 给出的结果, 他们在利用完美侧信道攻击得到完整无误DA链的前提下，仅使用4个签名就可成功恢复签名私钥.这对使用ECDSA签名算法的网络协议产生了巨大的安全威胁.TLS 1.3使用的Ed25519算法也是椭圆曲线密码算法的一种, 因此可以考虑尝试通过格方法对TLS 1.3的加密和签名过程实施攻击. 存在的问题及思考 1 已有研究存在的问题 2 自TLS 1.3被提出以来, 不管是标准化组织IETF还是从事网络安全分析的学者专家都致力于分析协议缺陷从而完善协议细节, 为了使TLS 1.3尽早成为国际新标准而努力.本小节针对当前TLS 1.3研究存在的问题进行阐述. 1) 协议设计方面, 协议设计者改变协议实现细节的主要依据是公开论文指出协议漏洞, 虽然漏洞弥补相对来说比较及时, 但是大部分时间都是小修小补, 对于整体的安全性改善不明显, 而且还存在自相矛盾的情况. 2) 在协议实现方面, TLS 1.3实现工具还比较单一, 缺少功能完整的TLS实现工具和调试工具, 而且已有的针对TLS 1.0~TLS 1.2的实现工具在TLS 1.3上还很难实现互操作. 3) 在协议攻击方法方面, 已有工作集中围绕形式化分析工具和一些公开的漏洞进行综合利用, 指出协议可能适用的攻击方法, 方法缺少创新性, 没有广泛地结合前沿理论如格方法.攻击大多数时间依赖于整个互联网范围内的搜索, 在攻击成本方面花费巨大. 未来研究方向 2 结合当前TLS 1.3发展态势和攻击方法研究现状, 针对TLS 1.3，可能的研究方向包括： 1) 分析设计TLS 1.3细节, 针对其功能和性能完善方面深入研究.国内针对TLS 1.3的研究还比较少, 详细分析协议细节并研究攻击方法的更是寥寥无几.因此, 在当前TLS 1.3步入标准化的大背景下, 对协议细节进行深入研究对在我国广泛应用和推广该协议具有巨大意义, 对其安全性进行深入研究可以有效防护我国网络安全. 2) 开发完整性和兼容性较好的协议实现和调试工具.TLS 1.3还处于标准化初级阶段, 由于版本问题, 当前的TLS协议调试工具都存在或多或少的兼容性缺陷, 新工具的开发是一个亟待解决的问题. 3) 深入研究旁路攻击技术, 结合最新理论前沿如格技术, 对TLS 1.3握手协议中的签名和加密过程进行攻击, 破解明文或者实现身份伪装.旁路攻击技术是当前学术界十分流行的新技术新方法, 已经被广泛应用于算法和协议的分析中.TLS 1.3作为一种网络协议, 使用的加密签名算法是否可以采用相关方法进行攻击值得深入讨论. 4) 在相关的研究领域如0-RTT协议以及Early data安全性等方向深入研究, 进一步增强TLS 1.3安全性和高效性.TLS 1.3的高效性主要体现在0-RTT握手以及Early data数据上, 作为新增的功能, 其安全性被学术界广泛研究, 进一步深入挖掘其安全性缺陷或者结合其他技术弥补其安全缺陷是十分有价值的课题. 5) 关注记录协议和警告协议的安全性, 进一步寻找可能存在的安全缺陷.从已有的文献来看，当前针对TLS 1.3的研究主要集中于对握手协议的分析, 作为协议的重要组成部分, 记录协议和警告协议的研究却十分稀少, 研究者可以尝试分析这两个协议, 或许可以另辟蹊径找到安全漏洞. 总结 1 作为新一代传输层安全标准, TLS 1.3以其安全性和高效性成为各大网站和浏览器供应商的新宠.可以预见, 未来完成标准化的TLS 1.3将会得到普遍应用.因此, 对其进行学习和研究是十分必要的.虽然随着协议草案版本的不断更新, TLS 1.3在安全性和高效性已经做出了很大的改善, 但是可以断定其中仍然存在新的问题值得大家研究. 在TLS 1.3标准化进程日益推进的今天, 对其安全性的分析和漏洞的挖掘都是值得研究的方向, 并且充满机遇与挑战.这一方向的研究不但具有深刻的学术意义，更具有巨大的现实价值, 未来必将吸引更多学者的关注和深入研究. 参考文献 中国互联网络信息中心.第41次《中国互联网络发展状况统计报告》[R/OL]. [2018-05-03] . http://www.cac.gov.cn /2018-01/31/ c _1122347026. htm http://www.cac.gov.cn/2018-01/31/c_1122347026.htm . China Internet Network Information Center.The 41st China Statistical Report on Internet Development[R/OL]. [2018-05-03] . http://www.cac.gov.cn /2018-01/31/ c _1122347026. htm http://www.cac.gov.cn/2018-01/31/c_1122347026.htm . DIERKS T, ALLEN C.The TLS Protocol Version 1.0(IETF RFC 2246)[S/OL]. [1999-01-30] . http://www.rfc-editor.org/rfc/rfc 2246. txt http://www.rfc-editor.org/rfc/rfc2246.txt . DIERKS T, RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.1(IETF RFC 4346)[S/OL]. [2006-04-30] . http://www.rfc-editor.org/rfc/rfc 4346. txt http://www.rfc-editor.org/rfc/rfc4346.txt . DIERKS T, RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.2(IETF RFC 5246)[S/OL]. [2008-12-30] . http://www.rfc-editor.org/rfc/rfc 5246. txt http://www.rfc-editor.org/rfc/rfc5246.txt . DOI: 10.1017/CBO9781107415324.004 http://dx.doi.org/10.1017/CBO9781107415324.004 . RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.3-draft-ietf-tls-tls13-26[DB/OL].[2018-03-20] . https://tools.ietf.org/html/draft-ietf-tls-tls 13-26 https://tools.ietf.org/html/draft-ietf-tls-tls13-26 . MILLER V S. Use of Elliptic curves in cryptography[C]// CRYPTO '85 Advances in Cryptology . Berlin: Springer-Verlag, 1985: 417-426. https://link.springer.com/chapter/10.1007%2F3-540-39799-X_31 RIVESTR L. The MD5 Message-Digest Algorithm (IETF RFC 1321)[S/OL]. [1992-04-30] . http://www.ietf.org/rfc/rfc 1321. txt http://www.ietf.org/rfc/rfc1321.txt . DOBRAUNIG C, EICHLSEDER M, MENDEL F, et al . Analysis of SHA-512/224 and SHA-512/256[C]// Proceedings of International Conference on the Theory and Application of Cryptology and Information Security . Berlin: Springer-Verlag, 2015: 612-630. https://link.springer.com/chapter/10.1007%2F978-3-662-48800-3_25 RIVEST R L, SHAMIR A, ADLEMEN L. A method for obtaining digital signatures and public-key cryptosystems[J] . Communications of the ACM , 1978, 21 (4): 120-126. BERNSTEIN D J, DUIF N, LANGE T, et al . High-Speed High-Security Signatures[C]// CHES'11 Proceedings of the 13 th International Conference on Cryptographic Hardware and Embedded Systems . Berlin: Springer-Verlag, 2011: 124-142. https://link.springer.com/chapter/10.1007/978-3-642-23951-9_9 项川, 潘无穷, 黎火荣, 等.支持商密算法TLS浏览器的设计与实现[J].信息网络安全, 2017(4): 26-33. XIANG C, PAN W Q, LI H R, et al . Research and implementation of TLS browser supporting commercial cryptographic algorithm[J]. Netinfo Security , 2017(4): 26-33 (Ch). Security Content Automation Chinese Protocol.CVE-2004-2770[R/OL]. [2017-12-10] . http://cve.scap.org.cn/CVE -2004-2770. html http://cve.scap.org.cn/CVE-2004-2770.html . Security Content Automation Chinese Protocol.CVE-2013-0169[R/OL].[2017-12-10] . http://cve.scap.org.cn/CVE -2013-0169. html http://cve.scap.org.cn/CVE-2013-0169.html . Security Content Automation Chinese Protocol.CVE-2016-0701[R/OL]. [2017-12-10] . http://cve.scap.org.cn/CVE -2016-0701. html http://cve.scap.org.cn/CVE-2016-0701.html . RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.3 - draft-ietf-tls-tls13-05[DB/OL].[2017-12-30] . https://tools.ietf.org/html/draft-ietf-tls-tls 13-05(2015) https://tools.ietf.org/html/draft-ietf-tls-tls13-05(2015) . RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.3 - draft-ietf-tls-tls13-10[DB/OL]. [2018-03-30] . https://tools.ietf.org/html/draft-ietf-tls-tls 13-10(2015) https://tools.ietf.org/html/draft-ietf-tls-tls13-10(2015) . RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.3 - draft-ietf-tls-tls13-13[DB/OL]. [2018-03-30] . https://tools.ietf.org/html/draft-ietf-tls-tls 13-13(2016) https://tools.ietf.org/html/draft-ietf-tls-tls13-13(2016) . RESCORLA E. The Transport Layer Security (TLS) Protocol Version 1.3 - draft-ietf-tls-tls13-18[DB/OL]. [2018-03-30] . https://tools.ietf.org/html/draft-ietf-tls-tls 13-18(2016) https://tools.ietf.org/html/draft-ietf-tls-tls13-18(2016) . DOWLING B, FISCHLIN M, GVNTHER F, et al . A cryptographic analysis of the TLS 1.3 handshake protocol candidates[C]// Proceedings of the 22 nd ACM SIGSAC Conference on Computer and Communications Security . New York : ACM Press, 2015: 1197-1210. https://www.researchgate.net/publication/301419709_A_Cryptographic_Analysis_of_the_TLS_13_Handshake_Protocol_Candidates HOLZ R, AMANN J, MEHANI O, et al . TLS in the wild: An internet-wide analysis of TLS-based protocols for electronic communication[J]. Computer Science , 2015, 21 (4): 120-126. BHARGAVAN K, LEURENT G. Transcript Collision Attacks: Breaking Authentication in TLS, IKE and SSH[DB/OL]. [2018-02-03] . http://www.mitls.org/down/oads/transeript-collisons.pdf http://www.mitls.org/down/oads/transeript-collisons.pdf . LI X Y, XU J, ZHANG Z F, et al . Multiple Handshakes Security of TLS 1.3 Candidates[C]// 2016 IEEE Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2016: 486-505. DOI: 10.1109/SP.2016.36 http://dx.doi.org/10.1109/SP.2016.36 . JAGER T, SCHWENK J, SOMOROVSKY J, et al . On the Security of TLS 1.3 and QUIC against Weaknesses in PKCS#1 v1.5 Encryption[C]// ACM Conference on Computer and Communications Security . New York: ACM Press, 2015: 1185-1196. DOI: 10.1145/2810103.2813657 http://dx.doi.org/10.1145/2810103.2813657 . DOWLING B, FISCHLIN M, GVNTHER F, et al . A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol[EB/OL]. [2018-02-02] . http://eprint.iacr.org /2016/081 http://eprint.iacr.org/2016/081 . KRAWCZYK H. A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)[DB/OL].[2018-02-12] . http://eprint.iacr.org /2016/711 http://eprint.iacr.org/2016/711/2016/711 . SOMOROVSKY J. Systematic fuzzing and testing of TLS libraries[C] // Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security . New York: ACM Press, 2016: 1492-1504. LEVILLAIN O, GOURDIN B, DEBAR H, et al . TLS record protocol: Security analysis and defense-in-depth countermeasures for HTTPS[C]// Proceedings of the 10 th ACM Symposium on Information, Computer and Communications Security. New York: ACM Press, 2015: 225-236. DOI: 10.1145/2714576.2714592 http://dx.doi.org/10.1145/2714576.2714592 . BHARGAVAN K, DELIGNAT-LAVAUD A, FOURNET C, et al . Implementing and proving the TLS 1.3 record layer[C]// 2017 IEEE Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2017: 362-379. DOI: 10.1109/SP.2017.58 http://dx.doi.org/10.1109/SP.2017.58 . KRAWCZYK H, WEE H. The OPTLS protocol and TLS 1.3[C]// 2016 IEEE European Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2016: 81-96. DOI: 10.1109/EuroSP.2016.18 http://dx.doi.org/10.1109/EuroSP.2016.18 . FISCHLIN M, GVNTHER F. Replay attacks on zero round-trip time: The case of the TLS 1.3 handshake candidates[C]// 2017 IEEE European Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2017: 82-113. DOI: 10.1109/EuroSP.2017.18 http://dx.doi.org/10.1109/EuroSP.2017.18 . GVNTHER F, HALE B, JAGER T, et al . 0-RTT Key Exchange with Full Forward Secrecy[DB/OL].[2018-02-12] . https://link.springer.com/chapter/ 10.1007/978-3-319-56617-7_18 https://link.springer.com/chapter/10.1007/978-3-319-56617-7_18 . MOGHIMIFAR F, STEBILA D. Predicting TLS performance from key exchange performance: Short paper[C]// Proceedings of the Australasian Computer Science Week Multiconference . New York: ACM Press, 2016: 44-55. https://dl.acm.org/citation.cfm?id=2843360 BHARGAVAN K, BLANCHET B, KOBEISSI N. Verified models and reference implementations for the TLS 1.3 standard candidate[C]// 2017 IEEE Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2017: 402-422. DOI: 10.1109/SP.2017.26 http://dx.doi.org/10.1109/SP.2017.26 . BADERTSCHER C, MATT C, MAURER U, et al . Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer[DB/OL].[2018-02-12] . https://link.springer.com/chapter /10.1007%2F978-3-319-26059-4_5 https://link.springer.com/chapter/10.1007%2F978-3-319-26059-4_5 . LANGLEY A, CHANG W, MAVROGIANNOPOULOS N, et al . IETF RFC 7905: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)[S/OL].[2018-03-02] . https://datatracker.ietf.org/doc/rfc 7905/ https://datatracker.ietf.org/doc/rfc7905/ . GIESEN F, KOHLAR F, STEBILA D, et al . On the security of TLS renegotiation[C]// Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security . New York: ACM Press, 2013: 387-398. DOI: 10.1145/2508859.2516694 http://dx.doi.org/10.1145/2508859.2516694 . BÖCK H, ZAUNER A, DEVLIN S, et al . Nonce-disrespecting adversaries: Practical forgery attacks on GCM in TLS[C]// WOOT '16 Proceedings of the 10 th USENIX Conference on Of fensive Technologies . Berkeley: USENIX Association, 2016: 15-25. https://www.researchgate.net/publication/305082645_Nonce-Disrespecting_Adversaries_Practical_Forgery_Attacks_on_GCM_in_TLS BELLARE M, TACKMANN B. The Multi-user Security of Authenticated Encryption: AES-GCM in TLS 1.3[DB/OL].[2018-02-12] . https://link.springer.com/chapter /10.1007%2F978-3-662-53018-4_10 https://link.springer.com/chapter/10.1007%2F978-3-662-53018-4_10 . QVNTHER F. Modeling Advanced Security Aspects of Key Exchange and Secure Channel Protocols [D]. Munich: Technische Universität, 2018. http://tubiblio.ulb.tu-darmstadt.de/94925/ MOELLER B, BOCHUM R U. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)(IETF RFC 4492)[S/OL]. [2018-02-12] . https://datatracker.ietf.org/doc/rfc 4492/ https://datatracker.ietf.org/doc/rfc4492/ . BERGSMA F, DOWLING B, KOHLAR F, et al . Multi-ciphersuite security of the secure shell (SSH) protocol[C]// Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security . New York: ACM Press, 2014: 369-381. DOI: 10.1145/2660267.2660286 http://dx.doi.org/10.1145/2660267.2660286 . LAN X, XU J, ZHANG Z, et al . Investigating the multi-ciphersuite and backwards-compatibility security of the upcoming TLS 1.3[J]. IEEE Transactions on Dependable and Secure Computing , 2017, 99 (2): 1. WACHS M, SCHEITLE Q, CARLE G. Push away your privacy: Precise user tracking based on TLS client certificate authentication[C]// Proceedings of Network Traffic Measurement and Analysis Conferenc e. Washington D C: IEEE Computer Society, 2017: 243-252. DOI: 10.23919/TMA.2017.8002897 http://dx.doi.org/10.23919/TMA.2017.8002897 . BHARGAVAN K, BOUREANU I C, FOUQUE P A, et al . Content delivery over TLS: A cryptographic analysis of keyless SSL[C]// 2017 IEEE European Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2017: 51-59. DOI: 10.1109/EuroSP.2017.52 http://dx.doi.org/10.1109/EuroSP.2017.52 . BAGARIA S, BALAJI R, BINDHUMADHAVA B S. Detecting Malignant TLS Servers Using Machine Learning Techniques[DB/OL].[2018-04-02] . https://www.researchgate.net/publication/ 3171641 39_ Detecting_Malignant_TLS_Servers_Using_Machine_Learning_Techniques https://www.researchgate.net/publication/317164139_Detecting_Malignant_TLS_Servers_Using_Machine_Learning_Techniques . RESCORLA E. Cleaning up flaws in TLS implementations: technical perspective[J]. Communications of the ACM , 2017, 60 (2): 98-98. HALE B, JAGER T, LAUER S, et al . Simple Security Definitions for and Constructions of 0-RTT Key Exchange[DB/OL].[2018-02-12] . https://link.springer.com/chapter /10.1007/978-3-319-61204-1_2 https://link.springer.com/chapter/10.1007/978-3-319-61204-1_2 . CREMERS C, HORVAT M, SCOTT S, et al . Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication[C]// 2016 IEEE Symposium on Security and Privacy . Washington D C: IEEE Computer Society, 2016: 470-485. DOI: 10.1109/SP.2016.35 http://dx.doi.org/10.1109/SP.2016.35 . ZHANG Z F, YANG K, HU X X, et al . Practical anonymous password authentication and TLS with anonymous client authentication[C]// Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security . New York: ACM Press, 2016: 1179-1191. DOI: 10.1145/2976749.2978354 http://dx.doi.org/10.1145/2976749.2978354 . FISCHLIN M, GVNTHER F, SCHMIDT B, et al . Key confirmation in key exchange: A formal treatment and implications for TLS 1.3[C]// 2016 IEEE Symposium on Security and Privacy . Washington D C: IEEE Press, 2016: 452-469. https://www.researchgate.net/publication/306301850_Key_Confirmation_in_Key_Exchange_A_Formal_Treatment_and_Implications_for_TLS_13 徐震, 陈路, 于爱民.可信增强TLS协议的设计与实现[J].华中科技大学学报(自然科学版), 2016, 44 (3): 44-48. XU Z, CHEN L, YU A M.Design and implementation of trusted enhanced TLS protocol[J]. Journal of Huazhong University of Science and Technology(Natural Science Edition ), 2016, 44 (3): 44-48 (Ch). FAN S Q, WANG W B, CHENG Q F. Attacking OpenSSL implementation of ECDSA with a few signatures[C]// Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security . New York: ACM Press, 2016: 1505-1515. DOI: 10.1145/2976749.2978400 http://dx.doi.org/10.1145/2976749.2978400 . 10.14188/j.1671-8836.2018.06.001 TP309 whdxxblxb-64-6-471 国家高技术研究发展(863)计划(2015AA016007)；国家自然科学基金面上项目(61872449)；密码科学技术国家重点实验室开放课题(MMKFKT201514) 2017-08-10 2018-12-24 2020-11-30 版权所有© 2018 《武汉大学学报(理学版)》编辑部 Copyright © 2018 Journal of Wuhan University(Natural Science Edition). All rights reserved. 2018 武汉大学学报(理学版) 6 64