9. TLS协议的安全分析
安全分析,重中之重,也是大家最关心的。
安全分析的第一步是建立攻击模型,TLS的攻击模式是:
- 攻击者有充足的计算资源
- 攻击者无法得到私钥,无法得到客户端和服务器内存里面的密钥等保密信息
- 攻击者可以抓包,修改包,删除包,重放包,篡改包。
这个模型其实就是密码学里面一般假定的攻击模型。
好了,在这个模型下,TLS的安全性分析如下:
9.1. 认证和密钥交换 的安全性
TLS有三种认证模式:双方认证,服务器认证,无认证。
只要包含了有服务器端认证,就可以免疫 man-in-the-middle 攻击。但是完全匿名的会话是可以被 MITM 攻击的。匿名的服务器不能认证客户端。
密钥交换的目的,是产生一个只有通信双方知道的共享密钥 pre_master_secret 。pre_master_secret 用来生成 master_secret 。 master_secret 用来生成 Finished 消息,加密key,和MAC key。通过发送正确的Finished消息,双方可以证明自己知道正确的 pre_master_key。
9.1.1 匿名密钥交换
匿名密钥交换是一种历史遗留的不安全方式。 匿名密钥交换缺失认证(Authentication),所以绝大多数场景下,我们应该禁用这种方式。
9.1.2. RSA 密钥交换和认证
当使用RSA的时候,合并了密钥交换 和 服务器端认证。
RSA公钥包含在服务器证书中。要注意的是,一旦服务器证书的RSA私钥泄露,之前用该证书保护的所有流量都会变成可以破解的,即没有前向安全性(Perfect Forward Secrecy)。
需要前向安全性的TLS用户,应该使用 DHE 或者 EC
TLS users desiring Perfect Forward Secrecy should use DHE 类的CcipherSuite。这样,如果私钥泄露,只需要更换私钥和证书就行,不会有更大的损失。
RSA密钥交换和认证的安全性基于,在验证了服务器的证书之后,客户端用服务器的公钥加密一个 pre_master_secret 。成功地解密 pre_master_secret 并产生正确地 Finished 消息之后,就可以确信服务器拥有证书对应的私钥。
如果使用了客户端认证,通过 CertificateVerify 消息来认证客户端。客户端会签署一个之前所有握手消息的hash值,这些握手消息包括 服务器的证书,ServerHello.random 。其中服务器证书确保客户端签署了和本服务器有关的绑定(即不能重放和别的服务器的握手),ServerHello.random 确保签名和当前握手流程绑定(即不能重放)。
9.1.3. Diffie-Hellman 密钥交换和认证
当使用 DH 密钥交换的时候,服务器:
- 或者发送包含固定 DH参数的证书
- 或者发送一组临时DH参数,并用 ECDSA/RSA/DSA 证书的私钥签署。而且在签署之前,临时DH参数和 hello.random 都参与hash计算,来确保攻击者不能重放老的签名值。
无论如何,客户端都可以通过验证证书,或者验证签名,来确保收到的DH参数确实来自真正的服务器。
如果客户端有一个包含固定 Diffie-Hellman 参数的证书,则证书包含完成密钥交换所需的参数。要注意的是,这种情况下,客户端和服务器每次都会协商出相同的 DH 结果(就是 pre_master_secret)。
为了尽可能减少 pre_master_secret 存在在内存里面的时间,当不再需要的时候,尽快将其清除,pre_master_secret 应该尽早转换成 master_secret 的形式。
为了进行密钥交换,客户端发送的 Diffie-Hellman 参数必须和服务器发送的兼容。
如果客户端有一个标准的 DSA 或者 RSA 证书,或者 客户端没有被认证,那么客户端在ClientKeyExchange中发送一组临时参数,或者可选地发送一个CertificateVerify消息来证明自己的身份。
如果相同的 DH 密钥对,被多次用于握手协商,不管是由于客户端或服务器使用了固定DH密钥的证书,还是服务器在重用 DH 密钥,都必须小心避免 small subgroup 攻击。实现都必须遵循 rfc2785 中的标准。
最简单避免 small subgroup 攻击的方法是使用一种 DHE CipherSuite,并且每次都握手都生成一个新的 DH 私钥 X。如果选择了一个合适的base(例如2),g^X mod p 的计算可以非常快,因而性能开销会最小化。并且每次都使用一个新的DH密钥,可以提供前向安全性。当使用 DHE 类的CipherSuite时,实现必须每次握手都生成一个全新的DH私钥(即 X )。
由于TLS允许服务器提供任意的 DH 群,客户端必须确认服务器提供的DH 群的大小适合本地策略。
客户端必须确认 DH 公共指数有足够的大小。
如果DH群已知的话,客户端做简单比对就行了,因此服务器可以使用一个已知的群,来方便客户端的检查。
9.2. 版本回退攻击
由于 TLS 历史上出现过多个版本,服务器端实现可能会兼容多个版本的协议,而像 SSL 2.0 这样的版本是有严重安全问题的,因此攻击者可能会尝试诱骗客户端和服务器,来使TLS连接回退到 SSL 2.0这种老版本。
TLS 对此的解决办法,就是PreMasterSecret里面包含版本号。
9.3. 针对握手过程的攻击
攻击者可能会尝试影响握手过程,来使双方选择不安全的加密算法。
对这种攻击的解决办法是,如果握手消息被篡改了,那么在Finished消息里,客户端和服务器都会计算 握手消息的hash,如果攻击者篡改了握手消息,那么双方得出的hash就不一样,这样Finished消息就会验证不过。就会发现攻击。
9.4. 针对 Resuming Sessions 的攻击
当使用 session resuming的时候,会产生新的 ClientHello.random 和 ServerHello.random ,并和session的 master_secret 一同被hash。只要master_secret没有泄漏,并且PRF中用来生成加密key和MAC key的hash算法是安全的,连接就是安全的,并且独立于前一个连接(被恢复的前一个连接)。
只有在客户端和服务器都同意的情况下,才会做session resuming。只要有任意一方怀疑 session 泄漏,或者证书过期/被吊销,就可以要求对端做完整的握手。
一个session的生命周期建议定位24小时。由于如果攻击者获得了 master_secret 就可以在session ID过期之前伪装成被泄漏者,所以要加一个生命期限制。
运行在不安全环境的应用程序,不应该把session ID写入持久存储。
9.5. 针对应用数据保护的攻击
master_secret 和 ClientHello.random 及 ServerHello.random 一起做 hash,来生成每个连接唯一的加密key和MAC key(就算是session resuming得到的连接,也是不同的)。
在CBC和stream cipher的情况下,
发送出去的数据,在发送前用MAC保护,来避免消息重放,避免篡改。
MAC根据 MAC key,序列号,消息长度,消息内容,固定字符串算出。
消息类型字段(content type)是必须的,来确保握手消息,ChangeCipherSpec消息,应用数据消息不会被混淆。
序列号用来确保删除包或者打乱包顺序的攻击无法得逞。
由于序列号是64位的,可以认为不会回绕。
从一方发给对端的消息,不能被插入对端发来的字节流中,这是用于两端使用不同的 MAC key。
类似地,server write key 和 client write key相互独立。因此stream cipher的key只使用了一次,避免了类似问题。
如果攻击者获取了加密key,那么就可以解密所有的消息。
类似地,泄漏MAC key,会使攻击者可以篡改消息。
AEAD就简单了。
9.6. 显式 IV的安全性
如前文所述,TLS 1.0是把前一条消息的最后一个block,当作下一条消息的第一个IV的,这促成了2004年公开的 BEAST 攻击,后来就改成这种显式IV的更安全的方式了。
9.7. 加密和MAC组合模式的安全性
前文介绍CBC和AEAD时已有分析,此处略过。
9.8. DOS 攻击下的安全性
TLS容易遭受某些 DoS 攻击。例如,攻击者创建很多TCP连接,就可以让服务器忙于做 RSA 解密计算。然而,由于TLS运行在TCP之上,只要操作系统TCP栈的 SYN-ACK里seqnum是随机的,攻击者就无法隐藏自己的ip,这样就可以和一般的TCP连接一样做DOS防御。
由于TLS运行在TCP上,每个独立的连接都可能遭受一系列DOS攻击。尤其是,攻击者可以伪造RST包,来中断一条TCP+TLS连接。或者伪造部分TLS记录,导致连接阻塞挂起。不过这些攻击都是任何TCP协议都有问题,不是TLS特有的。
9.9.Session Ticket 的安全分析
Ticket必须: 1.有MAC (即 authenticated,不可篡改),2.加密(即保密)。
下面分析在各种攻击方法下的安全性。
9.9.1. 无效的Session
TLS协议要求当发现错误的时候,把TLS session变为无效。
这不会影响到ticket的安全性。
9.9.1. 窃取 Tickets
攻击者或者中间人,可能会窃取到ticket,并且尝试用来和server建立会话。
然而,由于ticket是加密过的,并且攻击者不知道密钥,窃取到的ticket无法使攻击者恢复会话。
TLS服务器必须使用强加密和MAC算法,来保护ticket。
9.9.2. 伪造 Tickets
一个恶意用户可能会伪造,或者篡改一个ticket,来恢复一个会话,来延长ticket的生命周期,或者假装成另一个用户。
然而,由于服务器使用了强的校验保护算法,比如带密码的 HMAC-SHA1 ,因此无法得逞。
9.9.3. DoS 攻击
推荐ticket 格式中的 key_name 字段帮助服务器有效地拒绝不是自己签发的票据。
因此,一个攻击者可能发送大量的ticket,让服务器忙于验证ticket。
然而,只要服务器使用了高效的加密和MAC算法,就不会有问题。(现实中,加密和MAC算法效率都极高,这根本不是问题)
9.9.4. 加密 Ticket 的key 的管理
加密ticket的key的管理,推荐的做法:
- key 应该用密码学安全的随机数生成器生成,按照RFC4086。
- key 和加密算法最少应该是 128 比特安全程度的。
- key 除了加密和解密ticket以外,不应该有其他用途。
- key 应该定期更换
- 当ticket格式更换,或者算法更换时,应该更换key
9.9.5. Ticket 的有效期
TLS服务器控制ticket的生命周期。服务器根据配置来决定可以接受的ticket生命周期。
ticket的生命周期可能会长于24小时。TLS客户端可能会接受到一个ticket生命周期的提示,当然,客户端本地的策略最终决定ticket保存多久。
9.9.6. 其他的 Ticket 格式和分发方法
如果没使用推荐的ticket格式,那必须小心地分析方案的安全性。尤其是,如果保密数据比如保密密钥传输给了客户端,那必须用加密方式传输,来防止泄露或篡改。
9.9.7. Identity Privacy, Anonymity, and Unlinkability
ticket的加密和加MAC,就保证了敏感信息不会泄露。
由于在ticket解密之前的TLS握手,无法隐藏客户端的特征,因此中间人可能根据相同的ticket被复用,发现相同的ticket属于相同的用户。TLS对这种情况不提供保证。
10. TLS扩展:
https://tools.ietf.org/html/r...
几个比较重要的TLS扩展:
- Server Name Indication (SNI)
由于在SNI提出之前,tls握手过程中没有字段标明客户端希望连接服务器端的哪个域名,这样如果一个服务器端口上有多个域名,服务器就无法给出正确的证书。随着ipv4地址空间紧张,这个问题越发突出。因此提出了SNI。 - TLSEXT_ALPN
上层协议协商,就是在握手过程中,标明TLS里面是什么协议,例如 http2就是 h2 - Maximum Fragment Length Negotiation
主要用于嵌入式环境,需要客户端发送。 - Session Ticket
Session Ticket,就是把session cache加密后存入客户端,这样服务器端就不需要任何存储了。 - TLSEXT_SAFE_RENEGOTIATION
重协商 - Certificate Status Request:
OCSP ,OCSP 主要是为了减少客户端查询 证书撤销列表(Ceritificate Revoke List)的网络调用,而提出的。
11. TLS的配套:PKI体系
11.1. X.509 证书
X.509是PKI的一个标准,其中内容包括:
- 公钥证书
- 证书撤销列表,CRL
- 证书路径验证算法(CA/证书 链的格式)
X.509使用ASN.1语法做序列化/反序列化
ASN1 就是一个数据序列化/反序列化格式,跟 protobuf 差不多,可以算作竞争对手。
DER 就是用 ASN1 序列化某些数据结构的格式。
PEM 就是 DER做base64,加上一些其他字段。
证书链,以一个或多个CA证书开头的证书的列表,其中:
- 每一个证书的 Issuer 和下一个证书的 Subject 相同
- 每一个证书都被下一个证书的私钥签署
- 最后一个证书是 根证书(“root CA”),在TLS握手中不会被发送
证书里面包含公钥,和其它一些字段(比如证书用途,有效期,签发者等等)
x509.v3证书的字段:
mozilla的ca证书列表
https://www.mozilla.org/en-US...
https://www.apple.com/certifi...
苹果对CA提的要求:
1.CA必须取得完整的 WebTrust for Certification Authorities audit (WebTrust CA审计:http://www.webtrust.org/)
2.你的root CA证书必须为apple平台的用户提供广泛的商业价值。例如,一个组织内内部使用的证书不能被接受为root证书。
3.你签的证书必须含有可以公开访问的CRL地址。
Webtrust审计介绍:
Webtrust是由世界两大著名注册会计师协会(美国注册会计师协会,AICPA和加拿大注册会计师协会,CICA)制定的安全审计标准,主要对申请对象的系统及业务运作逻辑安全性、保密性等共计七项内容进行近乎严苛的审查和鉴证。只有通过Webtrust国际安全审计认证,才有可能成为全球主流浏览器根信任的证书签发机构。
https://www.geotrust.com/
的网站上右下角,有个图标:
点开就可以看到 KPMG 对 geotrust 公司的 webtrust 审计报告:
https://cert.webtrust.org/Sea...
2011年 荷兰CA公司DigiNotar颁发假google,Facebook,微软证书被发现,后发现被入侵,导致该公司破产。
http://www.cnbeta.com/article...
11.2.现有PKI体系暴露出的问题
http://googleonlinesecurity.b...
https://blog.mozilla.org/secu...
https://www.dfn-cert.de/dokum...
https://www.cs.utexas.edu/~sh...
解决方案:
(1). public key pin
https://developer.mozilla.org...
(2). HSTS
http://www.chromium.org/hsts
收录进chrome的默认HSTS列表: https://hstspreload.appspot.com/
(3). Certificate Transparency
https://www.certificate-trans...
12. TLS协议历史上出现过的漏洞,密码学常见陷阱
12.1. TLS的漏洞
漏洞分析很耗时间,这里总结一些资料,有兴趣的自己看吧。
虽然TLS的设计已经尽可能的严密,但是随着技术进步的滚滚车轮,历史上还是出现过很多漏洞,
可以参看这个rfc,做了总结:
[Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)] 链接 https://tools.ietf.org/html/r...
还有这个文档:
[The Sorry State Of SSL] 链接 https://hynek.me/talks/tls/
http://hyperelliptic.org/inte...
TLS 协议最近一些年被爆出过的设计缺陷,尤其是在用的最多的 AES-CBC 和 RC4 上。
AES-CBC 发现了:
- padding oracle 攻击
- BEAST 攻击
- Lucky 13 攻击
- TIME 攻击
- POODLE攻击
2013 年, AlFardan发表了对 RC4 的一个攻击分析,展示如何恢复 RC4 传输的连接上的数据。这种恢复攻击利用了RC4的一些已知弱点,例如RC4最初的一些字节的显著统计特征。
最近几年,TLS的代码实现引起了安全研究者的关注,这导致了新漏洞不断发现。
2014年,OpenSSL库爆出了好几个漏洞,例如 HeartBleed,还有 CVE-2014-6321 ( Microsoft SChannel 的实现漏洞)等.
TLS的问题:
• 很多问题是由于TLS使用了一些“史前时代”的密码学算法(- Eric Rescorla)
• CBC 和 Mac-Pad-then-Encrypt
• RSA-PKCS#1v1.5 的 RSA padding
• RC4 的任何使用
• 很蠢的设计:临时 RSA 密钥协商,GOST 类CipherSuite,Snap Start 等
• 可怕的向后兼容要求,导致迟迟不能废弃一些老算法。
The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software
http://crypto.stanford.edu/~d...
https://www.cs.utexas.edu/~sh...
[Why Eve and Mallory Love Android An Analysis of Android SSL (In)Security] 链接 https://www.dfn-cert.de/dokum...
12.2. 密码学常见陷阱
先举几个加密协议被破解的例子,给大家助兴:
- [人人网使用256比特RSA加密登录密码,3分钟可破] 链接 https://www.91ri.org/8928.html
- [Flickr length extension attack 漏洞] 链接 http://www.happybearsoftware....
- [分析whatsapp协议缺陷的一个文章] 链接 https://blog.thijsalkema.de/b...
- [卫星电话的私有gmr-1/gmr-2加密算法被逆向并破解] 链接 https://cryptanalysis.eu/blog...
- http://cryptofails.blogspot.c...
- http://cryptofails.blogspot.c...
网上有一些资料,有兴趣自己看吧:
- https://www.schneier.com/essa...
- https://www.schneier.com/essa...
- http://www.lauradhamilton.com...
- http://www.cryptofails.com/
- http://cryptofails.blogspot.ca/
密码学常见应用错误
http://security.stackexchange...
- 不要自己发明加密算法。Don’t roll your own crypto.
- 不要使用不带MAC的加密 Don’t use encryption without message authentication.
- 在拼接多个字符串做hash之前,要特别小心 Be careful when concatenating multiple strings, before hashing.
- 要特别小心使用的随机数生成器,确保有足够的熵 Make sure you seed random number generators with enough entropy.
- 不要重用 nonce 或者。IV Don’t reuse nonces or IVs.
- 加密和MAC不要使用同样的key,非对称加密和签名不要使用相同的key Don’t use the same key for both encryption and authentication. Don’t use the same key for both encryption and signing.
- 不要使用ECB模式做对称加密 Don’t use a block cipher with ECB for symmetric encryption
- Kerckhoffs定律,一个密码学系统的安全性必须建立在密码保密的基础上,其他都是公开的。Kerckhoffs’s principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge
- 不要把用户产生的密码作为加密的key。Try to avoid using passwords as encryption keys.
- 在密码学协议中,任何2条消息的密文都不应该一样。In a cryptographic protocol: Make every authenticated message recognisable: no two messages should look the same
- 不要把相同的key用在通信的2个方向上。Don’t use the same key in both directions.
- 不要使用不安全的key长度。Don’t use insecure key lengths.
- …
13. 下一代TLS: TLS 1.3
tls 1.3的草案在 http://tlswg.github.io/tls13-...
相比tls 1.2, 1.3改动巨大,这些改动对加密通信协议的一般设计也有重要启发。
TLS 1.3 的改动
值得关注的重大改进有:
- 0-RTT支持
- 1-RTT握手支持
- 改为使用HKDF做密钥拓展
- 彻底禁止RC4
- 彻底禁止压缩
- 彻底禁止aead以外的其他算法
- 去除aead的显式IV
- 去除了AEAD的AD中的长度字段
- 去除ChangeCipherSpec
- 去除重协商
- 去除静态RSA和DH密钥协商
移动互联网兴起之后,rtt延迟变得更重要,可以看到,tls 1.3 的各项改进,主要就是针对移动互联网场景的。
TLS 1.3 去掉了 ChangeCipherSpec ,这样record之上有3个协议:handshake,alert,application data
13.1. record层的密码学保护的改动
由于只保留了aead,所以不需要MAC key了。
aead的具体参数用法也有调整,前文有。
KDF 换成了标准的HKDF,有2种 tls_kdf_sha256, tls_kdf_sha384
13.2.handshake协议的改动
鉴于session ticket如此之好用,简直人见人爱,所以 TLS 1.3 直接把session ticket内置了,并改名叫 PSK
要注意的是,此 PSK 和 tls 1.2中一个很生僻的psk(见 [rfc4279] 链接 https://tools.ietf.org/html/r... )并不是一回事。
综合考虑了 session resuming ,session ticket后,
TLS 1.3 提出了3种handshake模式:
- Diffie-Hellman ( 包含 DH 和 ECDH 两种,下文说到 ECDH 的地方,请自行脑补成 “ECDH/DH”).
- A pre-shared symmetric key (PSK) ,预先共享的对称密钥,此处用统一的模型来处理session resuming 和 rfc4279的psk
- A combination of a symmetric key and Diffie-Hellman ,前两者合体
13.3. 1-RTT 握手
首先,TLS 1.2 的握手有2个rtt,第一个rtt是 ClientHello/ServerHello,第二个rtt是ClientKeyExchange/ServerKeyExchange,
之所以KeyExchange要放在第二个rtt,是由于tls1.2要支持多种密钥交换算法,和各种不同参数(比如 DH还是ECDH还是RSA,ECDHE用什么曲线,DH用什么群生成元,用什么模数,等等),这些算法和参数都依赖第一个rtt去协商出来,
TLS1.3大刀阔斧地砍掉了各种自定义DH群,砍掉了ECDH的自定义曲线,砍掉了RSA协商,密钥协商的算法只剩下不多几个,而且其实大家实际应用中基本都用 ECDH P-256,也没啥人用别的,所以干脆让客户端缓存服务器上一次用的是啥协商算法,把 KeyExchange直接和入第一个rtt,客户端在第一个rtt里直接就用缓存的这个算法发KeyExchange的公钥,如果服务器发现客户端发上来的算法不对,那么再告诉正确的,让客户端重试好了。
这样,就引入了 HelloRetryRequest 这个消息。
这样,基本没有副作用,就可以降到 1-RTT。
这是TLS 1.3 的完整握手。
显然,如果一个协议只有一种密钥协商算法,比如定死为 ECDH P-256,那一定可以做到 1-RTT
13.4. 有副作用的 0-RTT握手
0-RTT应该是受Google的QUIC协议的启发,
如果服务器把自己的 ECDH 公钥长期缓存在客户端,那么客户端就可以用缓存里的ECDHE公钥,构造一个电子信封,在第一个RTT里,直接就发送应用层数据了。
这个长期缓存在客户端的ECDH公钥,称为 半静态 ECDH 公钥( semi-static (EC)DH share )
ECDH公钥通过 ServerConfiguration 消息发送给客户端。
这个0-rtt优化是有副作用的:
- 0-RTT发送的应用数据没有前向安全性。
- 跨连接可以重放0-RTT里的应用数据(任何服务器端无共享状态的协议,都无法做到跨连接防重放)
- 如果服务器端 半静态 ECDH公钥对应的私钥泄露了,攻击者就可以伪装成客户端随意篡改数据了。
服务器在 ServerConfiguration 消息里把半静态 ECDH 公钥发送给客户端。
ServerConfiguration 值得关注一下:
struct {
opaque configuration_id<1..2^16-1>;
uint32 expiration_date;
NamedGroup group;
opaque server_key<1..2^16-1>;
EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration;
其中的 expiration_date 是本 ServerConfiguration 最后的有效期限。
这个值绝对不允许大于7天。
客户端绝对不允许存储 ServerConfiguration 大于7天,不管服务器怎么填这个值。
0-RTT 中的应用数据,放在 EarlyDataIndication 中发送,
TLS 1.3 还特意给 EarlyDataIndication 定义了一种 ContentType : early_handshake
(共四种 alert(21), handshake(22), application_data(23), early_handshake(25) )
13.5. Resumption 和 PSK
TLS 1.3 里面,把session resumption/session ticket 恢复出来的key,和 psk (rfc4279), 统一在一个 handshake PSK 模式下处理。
PSK CipherSuite可以 把PSK和ECDHE结合起来用,这样是有前向安全性的。
也可以仅仅使用PSK,这样就没有前向安全性。
13.6. Key Schedule 过程的改动
TLS 1.3 中,综合考虑的 session ticket的各种情况后,提出了 ES,SS 两个概念,统一处理密钥协商的各种情况。
在各种handshake模式下,ES和SS的取值来源不同。
Ephemeral Secret (ES)
: 每个连接新鲜的 ECDHE 协商得出的值。凡是从 ES 得出的值,都是前向安全的(当然,在 PSK only模式下,不是前向安全的)。
Static Secret (SS)
: 从静态,或者半静态key得出的值。例如psk,或者服务器的半静态 ECDH 公钥。
在各种 handshake 模式下:
Key Exchange | Static Secret (SS) | Ephemeral Secret (ES) |
---|---|---|
(EC)DHE (完整握手) | Client ephemeral w/ server ephemeral | Client ephemeral w/ server ephemeral |
(EC)DHE (w/ 0-RTT) | Client ephemeral w/ server static | Client ephemeral w/ server ephemeral |
PSK | Pre-Shared Key | Pre-shared key |
PSK + (EC)DHE | Pre-Shared Key | Client ephemeral w/ server ephemeral |
如上表所示:
- 完整的 1-RTT握手的时候, SS 和 ES 都是用的 ephemeral key ,这样是一定有前向安全性的。
- 使用 0-RTT 的握手的时候,使用客户端的 ephemeral key 和 服务器端的半静态 ECDH 公钥生成 SS,
- 纯 PSK,这种场景完全没有前向安全性,应该避免。
- PSK + ECDHE,这种场景比较有意思,SS是用的Pre-Shared Key,没有前向安全性,ES 用的 ephemeral key,有前向安全性。
可以看到,相比 TLS 1.2 的 session ticket,TLS 1.3 中 的 PSK + ECDHE,是结合了 ES 的,这样就有了前向安全性,相对更安全。
和 TLS 1.2 不同的是,TLS 1.3的 master_secret 是使用 ES和SS 两个得出的。
HKDF-Expand-Label(Secret, Label, HashValue, Length) =
HKDF-Expand(Secret, Label + '\0' + HashValue, Length)1. xSS = HKDF(0, SS, "extractedSS", L)2. xES = HKDF(0, ES, "extractedES", L)3. master_secret = HKDF(xSS, xES, "master secret", L)4. finished_secret = HKDF-Expand-Label(xSS, "finished secret",
handshake_hash, L)
Traffic Key Calculation
加密流量用的key,在 TLS 1.3 里面称为 Traffic Key,由于多引入了一种ContentType,在不同的ContentType下,Traffic Key 并不相同。
如下表:
Record Type | Secret | Label | Handshake Hash |
---|---|---|---|
Early data | xSS | “early data key expansion” | ClientHello |
Handshake | xES | “handshake key expansion” | ClientHello… ServerKeyShare |
Application | master secret | “application data key expansion” | All handshake messages but Finished |
要关注的是, Early Data 的 Traffic Key 是用 xSS 算出来的。也就是说,是用 Pre-Shared Key决定的。因此是没有前向安全性的。
在一个TLS 连接中,究竟是用哪种 handshake 模式,是由 CipherSuite 协商决定的。
本文转自微信后台团队,如有侵犯,请联系我们立即删除
OpenIMgithub开源地址:
https://github.com/OpenIMSDK/...
OpenIM官网 : https://www.rentsoft.cn
OpenIM官方论坛: https://forum.rentsoft.cn/
更多技术文章:
开源OpenIM:高性能、可伸缩、易扩展的即时通讯架构
https://forum.rentsoft.cn/thr...
【OpenIM原创】简单轻松入门 一文讲解WebRTC实现1对1音视频通信原理
https://forum.rentsoft.cn/thr...
【OpenIM原创】开源OpenIM:轻量、高效、实时、可靠、低成本的消息模型
https://forum.rentsoft.cn/thr...