TLS1.0.jpeg

开场白

我的博客在2020年正式用上了TLS1.3,那它其实香不香?在学习的过程中发现一个有趣的地方,IETF有意无意的让RFC号(request for comment)都保持以“46”结尾。

RFC2246,TLS1.0.发布于1999年;

RFC4346,TLS1.1发布于2006年;

RFC5246,TLS1.2发布于2008年;

RFC8446,TLS1.3发布于2018年;

SSL/TLS究竟是什么关系?

很多教科书都会这样描述:TLS1.0可以称为SSL3.1,TLS1.1可以称为SSL3.2,TLS1.2称之为SSL3.3。虽然这两个协议都是为了保障数据的通信安全,但实际上SSL协议和TLS协议有什么区别吗?

首先网上对SSL和TLS所属的工作层次有很多争论,我认为不论是OSI模型或者TCP/IP模型,都只是便于我们研究抽象概念的工具。按照微软的定义,TLS协议和 SSL协议都位于应用程序协议层和 TCP/IP 层之间,在此层中,可以保护应用程序数据并将其发送到传输层。而按照维基百科的定义,TLS协议和SSL协议都归属于表示层,但其也认为并不完全恰当。

我认为两者最主要的差别是建立SSL连接和TLS连接(指 handshake)是不一样的。一方面,SSL握手通过端口进行显式连接,而TLS则是通过协议进行隐式连接。另一方面,SSL和TLS使用的密码套件不一样。密码套件的组成包括密钥交换算法,认证算法,对称加密算法和消息认证码(MAC)算法。每个SSL版本或TLS版本都有其所支持的密码套件,并且TLS协议仍在不断的推出更安全的套件,以提高安全性和连接性能,也因此TLS协议成为了当今主流,而SSL已经从历史舞台退出。

综上,SSL和TLS本质是两种不同的协议,且SSL和TLS是无法互相兼容,但SSL和TLS都是为了安全而生。

已知的SSL/TLS问题

自2020年3月起,各大浏览器都陆续宣布将慢慢的不再支持TLS1.0和TLS1.1协议,因为旧版本的SSL或TLS容易被攻击者利用,引发安全问题,那究竟问题都有哪些?

  • FREAK(Factoring RSA Export Keys)攻击,本质是因为加密密钥的长度太短,不足以保护数据的安全。
  • LogJam漏洞,本质上是因为在DH密钥交换过程中使用的公钥强度小于1024bits,以至于无法保护数据的安全。
  • Poodle (Padding Oracle on Downgraded Legacy Encryption)攻击。本质是是SSL3.0中使用了不安全的CBC块加密(Cipher Block Chaining)模式,使得选择明文攻击成为可能。为此攻击者常常还会发起降级攻击,尝试协商并且使用SSL3.0作为通信协议,进而实现Poodle攻击。也存在针对TLS协议的Poodle攻击,称之为TLS Poodle。
  • Beast 攻击,本质是在TLS1.0版本中使用了不安全的CBC块加密模式,使得选择明文攻击成为可能。为此攻击者常常还会发起降级攻击,尝试协商并且使用TLS1.0作为通信协议,进而实现Beast攻击。
  • Lucky 13 攻击,本质是使用了不安全的的CBC块加密模式和基于MAC-then-Encrypt的认证加密模式。影响范围包括 TLS 1.1和TLS1.2。
  • Royal Holloway 攻击。本质是使用了不安全的RC4流加密(Rivest Cipher 4 Stream Cipher)算法。攻击者可以利用相同的纯文本进行加密通信,对大量会话中得出的密文进行统计分析,从而进行纯文本恢复攻击。
  • SLOTH(Security Losses from Obsolete and Truncated Transcript Hashes )攻击,本质是使用了不安全的MD5算法,使得TLS握手的密钥交换和消息认证过程存在安全风险,影响范围包括TLS1.2。
  • HeardBleed 漏洞,本质是使用了不安全的OpenSSL拓展组件导致的内存泄漏,影响范围包括OpenSSL的1.0.1至1.0.1f 版本。
  • 绕过CA证书检查(CVE-2021-3449 and CVE-2021-3450),本质是使用了不安全的OpenSSL版本,影响范围包括OpenSSL 1.1.1h及后续版本,在OpenSSL 1.1.1k中修复了这个问题。

通过上面的例子,我们发现在旧版本的SSL/TLS主要是密钥强度和算法设计上存在问题。TLS1.3的标准文件中则针对了上述的问题做了许多强制性要求,只有满足条件的密码套件才能被用于TLS1.3。关于选择明文攻击(Chosen-Plaintext Attack),文本恢复攻击,块加密,流加密的相关内容,本博客之前的文章中已有涉及,欢迎查阅。

什么是密码套件

密码套件(Ciphers Suite)的组成包括密钥交换算法,认证算法,对称加密算法和消息认证码(MAC)算法。下面是一台CentOS 8中OpenSSL支持的密码套件,Kx代表密钥交换(Key Exchange),Au代表认证(Authenticate),Enc代表加密(Encryption),Mac代表消息认证码(Message Authentication Code)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@t3 ~]# cat /etc/redhat-release 
CentOS Linux release 8.3.2011
[root@t3 ~]# openssl version
OpenSSL 1.1.1g FIPS 21 Apr 2020

[root@t3 ~]# openssl ciphers -v
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
TLS_AES_128_CCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
......
......
......
......
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1

ssl-handshake-ciphers.png

在TLS1.3加密通信之前,客户端和服务器端会进行密码套件的协商。Client Hello的请求中就会列举客户端所支持的全部密码套件,当服务器收到了Client Hello后,会选择双方都支持的密码套件,最终通讯将使用该密码套件对应的算法处理,套件在数据包中用十六进制格式显示。在TLS1.3中是完全禁止重新协商的,意味如果服务器端发现客户端发过来的可选密码套件都不是“我”同意使用的,通信会被中止。这可以防止降级攻击的发生。

譬如下面图二中Server Hello中的0x1301则是协商的结果,因为密码套件是按照优先级顺序排列的。0x1301的意思是在TLS协议通信时,数据加密部分,将使用128bit密钥的GCM(Galois Counter mode)模式的AES对称加密算法,消息完整性部分,将使用SHA256哈希算法。那么密钥交换的方式呢?TLS1.3标准对密码套件的选择进行了许多改进,譬如强制要求只能使用满足完美向前兼容(Perfect Forward Secrecy)的密钥交换算法,因为达不到PFS要求,所以基于RSA的密钥交换算法无法在TLS1.3中使用,也因此TLS1.3协议中可选择的密码套件数量远少于TLS1.2协议的密码套件数量,目前支持TLS1.3的密码套件就只有5种。通过查表得出0x1301使用的密钥交换是采用ECDH的方式,即采用基于椭圆曲线的DH密钥交换算法(Elliptic Curve Diffie-Hellman)。

image1 client hello cipher.png
image2 server hello cipher.png

在TLS1.2的协议中,有可能会出现密码套件仅显示AES256-SHA,代表其加密部分使用AES对称加密算法,数据验证使用SHA算法,而密码套件中缺少描述的密钥交换和认证都将默认使用RSA算法,如0x35。下面的网址可用于查询密码套件与十六进制数的映射关系,以及Mozilla推荐的密码套件配置。

https://testssl.sh/openssl-iana.mapping.html

https://wiki.mozilla.org/Security/Server_Side_TLS

TLS1.3之认证加密

TLS1.3的认证加密强制要求满足AEAD(Authenticated encryption with associated data)。AEAD满足信息安全中对数据的CIA原则,即数据保密性,数据完整性,数据真实性(Confidentiality, Integrity and Authenticity)

首先我们假设一切的通信环境都是不安全的,此时我们引入公钥算法(非对称加密)来实现参数交换,使得通信双方可以安全的协商出用于加密的参数,之后的通信都将用这个参数实现对称加密。这样做的好处是可以安全的得到仅有通信双方才知道的加密参数(由密钥交换获得),而且对称加密算法较于非对称加密算法的运算速度更快,开销更小。此时加密和解密数据都是同一个密钥,但是我们解密得出的内容并不知道是否正确或者是否被篡改,消息认证(完整性)则是为了解决这个问题。解决完整性问题的思路可以有以下3种:

  • Encrypt-then-MAC (EtM) ,首先对明文进行加密,然后根据得到的密文生成消息认证码(Message Authentication Code, MAC)。密文和它的MAC一起发送。IPsec通信使用的就是Encrypt-then-MAC类型的认证加密,目前SSH也支持EtM类型认证加密。
  • MAC-then-Encrypt (MtE) ,基于明文生成MAC,然后将明文和MAC一起加密以生成基于两者的密文。发送密文(包含加密的MAC)。SSL通信和Lucky 13的例子中就是使用了Encrypt-then-MAC类型的认证加密。
  • Encrypt-and-MAC (E&M) ,基于明文生成MAC,并且明文在没有MAC的情况下被加密。明文的MAC和密文一起发送。早期的SSH通信使用的就是Encrypt-and-MAC类型的认证加密。

其中EtM的安全性和灵活性在理论上优于另外两种方案,但是要想实现加密之后再进行MAC的操作是很困难的。上述三种类型的认证加密(EtM, E&M, MtE)在对抗选择明文攻击或抗伪造能力上,都存在缺陷。于是乎AEAD类型的认证加密被设计出来,AEAD吸取了许多类似EtM的思路,但它的加密和MAC的运算是可以同时进行的,譬如AES-GCM算法。

TLS1.3中常见的AES-GCM算法和Chacha20-Poly1305算法都满足AEAD的要求。其中的AES-GCM算法,因为在加密过程的初始向量不会重复使用,所以这避免了类似Poodle的攻击发生(选择明文攻击)。TLS1.3中不再使用RC4流加密和AES-CBC块加密等不安全的算法,因为AES-CBC块加密方式仅能完成数据加密,不能完成数据认证,而AES-GCM不仅可以完成数据加密,还可以使用GMAC运算可以完成数据认证。且因为CBC块加密模式本身设计的原因导致它在数据加密时,不能实现并行运算,运算速度不及GCM模式。Chacha20-Poly1305算法则深受Google公司的喜爱,在Chrome和Android上面很早就开始使用Chacha20-Poly1305算法。

AEAD.png

TLS1.3之密钥交换算法

TLS1.3的密钥交换算法强制要求满足完美向前保密(Perfect Forward Secrecy)的要求。首先,我们要厘清RSA密算法和DH算法的区别,下面的内容我们仅仅在密钥交换的角度比较RSA算法和DH算法的区别,因为DH算法无法实现数字签名的功能,而RSA算法可以。TLS1.3加入了基于椭圆曲线的签名算法,如ECDSA (Elliptic Curve Digital Signature Algorithm, 亦称EdDSA) 算法。在运算速度上,虽然ECDSA签名运算远不及RSA算法快,但是在维持安全性相同的情况下,ECDSA的所需要密钥长度远短于RSA密钥。另外TLS1.3可以同时支持ECDSA和RSA证书的,但是不支持DSA证书。

密钥交换之性能差异

在计算机的加密运算角度上,RSA算法(指用公钥加密数据)比DH算法,甚至ECDH算法都要更快,而且RSA算法的开销更小。在算法支持的角度上,DH算法可以支持椭圆曲线算法的,这使得ECDH(Elliptic Curve Diffie-Hellman)可以使用较短的密钥长度就可以实现较高的安全性。譬如RSA算法要想达到等同于256bit密钥的ECDH安全性,就需要使用约3000bit的密钥长度。但如果DH公钥中还包括DH参数的话,那么它相较于RSA算法还是需要编码更多信息在公钥。

密钥交换之安全性差异

RSA算法其安全性是基于大整数的因素分解是困难的,而DH算法其安全性是基于在有限域上计算离散对数是困难的,两个算法在密钥强度足够健壮的情况下,都是安全的。其次RSA算法和DH算法的专利都已经过失效,大家都可以自由的学习这两个算法的实现原理,其中美国联邦政府更加倾向于使用DH算法。RSA算法的标准主要是由一家叫RSA的私人公司制定,2013年棱镜门事件期间,曾经报道过RSA公司和美国政府合作在算法添加后门的丑闻。

DH算法最大的优势就是可以使用临时密钥(Ephemeral key)替代私钥进行密钥交换,这是让DH算法符合完美向前保密(PFS)重要原因。因为RSA算法和静态的DH算法是使用固定的密钥直接参与运算,如果私钥泄漏或者被攻破的话,那么包括之前全部的加密通信都存在安全风险。而如果使用类似DHE(Diffie-Hellman Ephemeral)的算法,因为避免了私钥直接参与运算,这使得在私钥泄漏或者被攻破的情况下,攻击者也无法解密之前所截获的加密通信。因为当协商完成之后,临时密钥替代私钥参与到了对称加密算法中,而每个会话使用的临时密钥都是不一样的,所以每个会话里所使用的对称加密密钥也是不一样的。

因为临时密钥的特性,使得企业中常见的入侵防御系统(Intrusion Prevention System)或者防火墙等设备都需要升级才能处理TLS1.3流量。此外,使用临时密钥的DH密钥交换依然不能实现身份验证,因为密钥每次都不同,任何一方都不能确定密钥是否来自预期的一方,所以TLS1.3中还应用了ECDSA签名校验,新的PSK(Pre-shared key)机制,和基于HMAC的密钥生成算法(HMAC-based Extract-and-Expand Key Derivation Function,简称HKDF)等技术,他们都是为了提高TLS1.3协议的整体安全性。

decryption-profile-tlsv13-as-min.png

老朋友TLS1.2

TLS1.3中还有两个比较有意思的新特性,第一个,ServerHello之后的所有握手消息都使用了加密处理,提前进入加密通信状态,减少明文握手信息泄漏。第二个,增加0-RTT(Round-trip time),使得会话恢复的速度更快,免去再次握手,节省开销。这两个特性都跟TLS的握手有关系,所以我们有必要了解目前主流的TLS1.2协议是如何完成握手的。我将通过浏览器访问nginx.org建立TLS1.2握手连接,结合Wireshark抓包来剖析握手过程,下图是整个TLS1.2的握手流程,从DNS开始到HTTP数据传输,总共经历5个RTT,其中TLS1.2握手部分占用2个RTT。

tls1.2 handshake.jpg

Client Hello阶段

当TCP协议完成三次握手之后,我们开始进入TLS的握手阶段,第一步是Client Hello,由客户端发起,告知服务器端准备进入TLS握手连接。Client Hello数据包中有非常多的信息,我列举说明其中的一些:

协议版本(Version),表明客户端所期待支持的TLS协议版本;

客户端随机数(Client Random)一共有32字节,其中28字节是随机生成,剩下的4字节是与客户端的时间设置有关。随机数的是为了保护初始数据交换的完整性,也具有防止重放攻击的作用。

会话ID(Session ID),用于表明是不是需要恢复之前的会话,为空则表示没有会话需要恢复。

密码套件(Cipher Suites),表示客户端支持的密码套件,有优先级之分,默认第一个是客户端首选的密码套件。

压缩(Compression),客户端可以提出它所支持的数据压缩算法,在TLS1.3中的记录协议里是禁止使用压缩的。

拓展(Extensions),这部分涉及的内容非常丰富,涉及很多新增的标准协议,主要是为了让TLS协议在不修改协议本身的情况尽可能多的为TLS添加新功能。TLS1.3也是通过在原有TLS1.2的基础上添加许多拓展,来实现TLS1.2兼容TLS1.3标准,便于TLS1.3的推广和部署工作。

Client Hello.png

Server Hello阶段

Server Hello的数据包里面函盖的字段内容和Client Hello的数据包的差不多,只不过服务器端会对客户端提供的参数进行选择,所以每个字段里就只剩下一个选项,譬如例子中连接ngnix.og的时候,就选择密码套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。需要注意的是,服务器端并不会直接按照客户端Hello数据包中期待的TLS协议版本去连接,而是根据服务器的配置信息给客户端进行回应。在这个阶段中,服务器端会生成服务器端随机数(Server Random),并且还会将服务器的证书发送给客户端来证明自己的身份。

Server Hello.png

Cert.png

Key Exchange阶段

因为在Server Hello阶段中,服务器选择了使用ECDHE的密钥交换算法,所以服务器在发送Hello包之后,会继续发送Server Key Exchange数据包给客户端,这里面包含服务器端的协商参数(Server Params),服务器会使用私钥对Server Params里的公钥进行签名,以确保真实性。到这一步,服务器已经将与客户端进行握手所需要的参数都发送给客户端,可以发送Server Hello Done数据包表示完成,并等待客户端验证和回应。

紧接着,客户端也会生成协商参数(Client Params),加上已经通过明文传输得到的Server Parmas,利用这两个协商(Client Params 和 Server Params)参数便可以通过ECDHE算法安全的计算得出预主密钥(Pre-Master Key),预主密钥并不会直接拿来使用,而是连同已经通过明文传输得到的客户端随机数和服务器端随机数一起进行哈希运算,哈希算法采用上文Server Hello的密码套件中选定的SHA256执行运算,得到固定长度的主密钥(Master Key),因为有两个随机数(Server Random + Client Random + Pre-Master Key)共同参与哈希运算,所以可以保证不同客户端的握手之间,使用不一样的对称加密密钥,且一定程度上保证了对称密钥的随机性。由于预主密钥(Pre-Master Key)是安全的且只有通信双方才知道,所以哈希运算后产生的主密钥(Master Key)也是安全的。主密钥也不会参与到实际的通信中,而是通过密钥生成算法,以主密钥作为初始变量,拓展出一系列派生的密钥串来实现加密,如客户端发送会话用的是对称加密密钥串A,服务器端发送会话用的是对称加密密钥串B。

最后客户端也会发送客户端协商参数(Client Params)给服务器端,之后进入Encrypted Handshake Message状态,表示后续通信将使用对称加密传输。服务器端得到Client Params和Server Params参数,利用同样的办法也可以运算得到一系列派生的对称加密密钥串,也将进入Encrypted Handshake Message状态。

在双方准备告知对方握手结束(完成)之前,会先发送Change Cipher Spec数据包,将之前发送的数据做个信息摘要,然后加密发送。如果双方的加密和解密都正常,那么握手就可以结束。至此,无论客户端还是服务器端派生出来的对称加密密钥串,都符合完美向前安全的条件,接下来的HTTP通信就可以愉快的进行加密传输。

Server Params.png

Client params.png

ECDHE密钥交换原理

为了方便大家理解ECDHE(Elliptic Curve Diffie-Hellman Ephemeral )的工作原理,我解释一下为什么在明文传输Client Params,Server Parmas,Server Random,Client Random这四个参数的情况下,通信双方还是可以安全的协商出“共享的秘密”,其实这也正是密钥交换技术所要解决的问题。

首先ECC算法的运算流程在本博客之前有一篇文章单独介绍过,我简单总结一下。我们有如下一个二元三次方程组,当a和b的值是恒定的,x和y的数值作为变量的时候,我们就会得到一条曲线。假设a=-1,b=5,那么得到下面的曲线。
$$
y^2=x^3+ax+b
$$

发挥你的想象力,我们发现在坐标的第一区间和第四区间的曲线两端是可以被无限延长的,这其实就跟我们的密钥长度有关,也就是为什么当我们取的密钥长度越长的时候,安全性会更高,因为这个曲线在有限域上的可选数值就越多。根据ECC算法的流程,只要我们一开始给出两个固定的点的坐标,那么我们就可以通过运算得到新的第三个点,第三个点又可以通过运算得到第四个点,第四个点又可以通过运算得到第五个点…….我们可以一直重复的运算下去,假设最后经过N次重复运算得到的点是P。攻击者即使获取了P的坐标和NP运算得出的值,因为科学道理蜘蛛蚂蚁(破解离散对数是困难的),反正攻击者是没办法轻易的逆向破解出N的值,而N的值在ECDHE中可以看作是私钥。在无法确定N值的情况下,最好的攻击办法就剩下穷举,而实际应用的ECDHE算法中,对公开的底数(g)和公开的模数(p)的选择性是有要求的,一般底数是很小的数,常见一般用2,而模数则会选择使用数值很大的素数,暴力破解的难度和成本都变得非常巨大。譬如下图的计算例子中,a和b都是私钥,通过计算后得出的A和B则是可公开的信息,用于交换密钥环节使用。

使用传统计算机(冯诺依曼架构)很难计算离散对数,但是量子计算机已经出现了能够快速计算的算法(Shor’s Algorithm)。如果真能够开发出实用的量子计算机,那么DHE/ECDHE的安全性就会受到极大的挑战,现在正在研究可以替代ECDH的SIDH(超奇异椭圆曲线同源密钥交换算法)—–前奇虎360技术专家罗剑锋(Chrono)

ECDHE.png

TLS1.3的握手过程

通过TLS1.2的整体握手流程图可以得知,正常的TLS1.2握手是需要2-RTT,而正常的TLS1.3一般只需要1-RTT,甚至在利用Early-data和pre_shared_key拓展的情况下可以实现0-RTT,即无须再次握手就可以直接恢复之前的会话,实现加密传输。上述两处优化对移动设备的上网体验上有巨大的提升,下面我将用浏览器访问我本地部署的AdGuard服务的网页端,然后使用Wireshark来抓取TLS1.3的握手数据包。

Client Hello阶段

TLS1.3的Client Hello数据包中新增加了许多拓展,其中的application_layer_protocal_negotiation(APLN)和server_name就是与我们耳熟能详的HTTP2和SNI的设定有关。为了实现1-RTT,我们的思路就是在Client Hello阶段和Server Hello阶段完成在TLS1.2握手对应阶段的后续全部工作,包括密钥交换和加密验证,这样就可以节省一个RTT(Round Trip Time)。为了省去不必要的RTT,客户端不会被动的等待服务器端回应对密码套件的选择,在Client Hello阶段就直接猜测服务器端可能会使用哪种密码套件中的密钥协商算法,然后把所有猜测用到的算法里需要的参数都给服务器端即可。因为TLS1.3对密码套件的挑选要求很高,导致服务器本身可选择的密码套件范围也很小,目前TLS1.3协议就只有5种密码套件类型可选,所以客户端发送全部TLS1.2和TLS1.3协议里,猜测可能会用到参数给服务器,也不会造成数据包过大的问题。

这里就用到了supported_versions,supported_groups,key_share和signature_algorithms等等系列拓展来实现把猜测的参数发给服务器。supported_versions用于告诉对方客户端支持的TLS版本,让对方视情况选择TLS协议版本。supported_groups用于列举出服务器端可能会用到的椭圆曲线算法,譬如在抓取本地AdGuard网页的记录中tls.handshake.extensions_supported_groups就包括6种不同的椭圆曲线算法。key_share则提供了基于X2559和基于P-256两种椭圆曲线的公钥参数,它相当于是客户端的协商参数,并且用signature_algorithms字段的签名算法对它进行签名。

至此,客户端相当于在握手过程中,把相当于Client Params和Client Random都告诉了服务器,接下来就看服务器选择哪种密码套件,就能知道服务器用了哪些参数。

client hello.png

Key—share.png

Server Hello阶段

服务器端通过Client Hello阶段已经拿到了密钥交换运算需要的参数,按照类似TLS1.2的流程,可以派生出用于对称加密密钥的信息。最后,服务器端马上主动发起ChangeCipherSpec的请求,验证对方是否也可以计算出一样的派生密钥,并且把密钥交换需要的服务器端参数告诉客户端,同时还告诉客户端已经选择使用的密码套件。

客户端收到已选择的密码套件和服务器端协商参数之后,派生出同样的对称加密密钥,也发出ChangeCipherSpec的请求,验证双方得出的对称加密密钥是否一致。最后客户端将进入HTTP的数据发送阶段,因此,TLS1.3只需要1-RTT就完成了握手。

server hello.png

TLS1.3的0-RTT

https://blog.cloudflare.com/introducing-0-rtt/

TLS1.3特性总结

TLS1.3在性能和安全方面都有提升。相比与TLS1.2协议,TLS1.3的变化是巨大的。它新增了许多特性,如提前加密TLS握手信息,支持0-RTT,TLS1.3强制要求必须使用AEAD结构(Authenticated Cncryption with Additional Data)的对称加密算法,TLS1.3需要强制性满足完美前向保密(Perfect Forward Secrecy)等等。也是因为上述特性,意味着TLS1.3必然要移除许多特性,如删除静态RSA密钥协商,删除DH密码套件,禁用安全性不足的对称加密算法,不再使用MD5和SHA1算法,不再使用传统的分组加密模式等等。此外TLS1.3是完全禁止重新协商的和协议记录压缩。

TLS1.3值得吗?

开场白中提到的,TLS1.3香不香?或者说应用TLS1.3值不值得?

为了让我的博客应用TLS1.3,我手动编译了Nginx,因为需要添加高版本的OpenSSL组件才能兼容TLS1.3。这对需要应用TLS1.3的个人或小型企业来说,实现起来不算太困难,但TLS1.3特性所带来的提升对个人或小企业来说也似乎不那么重要。而对有高并发,海量用户访问需求的中大型企业来说,因为他们的架构本身就很复杂,如果要应用TLS1.3的话,会涉及到很多方面的改动。原有的TLS1.2甚至TLS1.1也不见得让他们无法接受。毕竟TLS1.2从2008年发布至今,已经经历十余年的应用,TLS1.3的覆盖仍需时间。

最后,即便工程师们把TLS标准设计的再安全,也无法阻止你把123456作为密码。

solawinds password.jpg

参考资料

https://tools.ietf.org/html/rfc8446

https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

https://time.geekbang.org/column/article/110354