TLS协议分析 (七) 安全性分析_数据包分析密码学漏洞

转自：http://chuansong.me/n/1281554752937

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 密钥交换的时候，服务器:

1. 或者发送包含固定 DH参数的证书

2. 或者发送一组临时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/rfc6066

几个比较重要的TLS扩展：

1. Server Name Indication (SNI)
   由于在SNI提出之前，tls握手过程中没有字段标明客户端希望连接服务器端的哪个域名，这样如果一个服务器端口上有多个域名，服务器就无法给出正确的证书。随着ipv4地址空间紧张，这个问题越发突出。因此提出了SNI。

2. TLSEXT_ALPN
   上层协议协商，就是在握手过程中，标明TLS里面是什么协议，例如 http2就是 h2

3. Maximum Fragment Length Negotiation
   主要用于嵌入式环境，需要客户端发送。

4. Session Ticket
   Session Ticket，就是把session cache加密后存入客户端，这样服务器端就不需要任何存储了。

5. TLSEXT_SAFE_RENEGOTIATION
   重协商

6. 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/about/governance/policies/security-group/certs/

https://www.apple.com/certificateauthority/ca_program.html
苹果对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/SealFile?seal=1567&file;=pdf

2011年 荷兰CA公司DigiNotar颁发假google，Facebook，微软证书被发现，后发现被入侵，导致该公司破产。
http://www.cnbeta.com/articles/154375.htm

11.2.现有PKI体系暴露出的问题

http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html

https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/

https://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf

https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

解决方案：

(1). public key pin

https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

(2). HSTS

http://www.chromium.org/hsts
收录进chrome的默认HSTS列表：    https://hstspreload.appspot.com/

(3).  Certificate Transparency

https://www.certificate-transparency.org/

12. TLS协议历史上出现过的漏洞，密码学常见陷阱

12.1. TLS的漏洞

漏洞分析很耗时间，这里总结一些资料，有兴趣的自己看吧。

虽然TLS的设计已经尽可能的严密，但是随着技术进步的滚滚车轮，历史上还是出现过很多漏洞，
可以参看这个rfc，做了总结：

[Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)] 链接 https://tools.ietf.org/html/rfc7457

还有这个文档：
[The Sorry State Of SSL] 链接 https://hynek.me/talks/tls/

http://hyperelliptic.org/internetcrypto/OpenSSLPresentation.pdf

TLS 协议最近一些年被爆出过的设计缺陷，尤其是在用的最多的 AES-CBC 和 RC4 上。

AES-CBC 发现了:

1. padding oracle 攻击

2. BEAST 攻击

3. Lucky 13 攻击

4. TIME 攻击

5. 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/~dabo/pubs/abstracts/ssl-client-bugs.html

https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

[Why Eve and Mallory Love Android An Analysis of Android SSL (In)Security] 链接 https://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf

12.2. 密码学常见陷阱

先举几个加密协议被破解的例子，给大家助兴：

• [人人网使用256比特RSA加密登录密码，3分钟可破] 链接 https://www.91ri.org/8928.html

• [Flickr length extension attack 漏洞] 链接 http://www.happybearsoftware.com/you-are-dangerously-bad-at-cryptography.html

• [分析whatsapp协议缺陷的一个文章] 链接 https://blog.thijsalkema.de/blog/2013/10/08/piercing-through-whatsapp-s-encryption/

• [卫星电话的私有gmr-1/gmr-2加密算法被逆向并破解] 链接 https://cryptanalysis.eu/blog/2012/02/02/dont-trust-satellite-phones-the-gmr-1-and-gmr-2-ciphers-have-been-broken/

• http://cryptofails.blogspot.ca/2013/07/cakephp-using-iv-as-key.html

• http://cryptofails.blogspot.ca/2013/07/saltstack-rsa-e-d-1.html

网上有一些资料，有兴趣自己看吧:

• https://www.schneier.com/essays/archives/1998/01/security_pitfalls_in.html

• https://www.schneier.com/essays/archives/1999/03/cryptography_the_imp.html

• http://www.lauradhamilton.com/10-cryptography-mistakes-amateurs-make

• http://www.cryptofails.com/

• http://cryptofails.blogspot.ca/

密码学常见应用错误
http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology

• 不要自己发明加密算法。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-spec/
相比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/rfc4279 )并不是一回事。

综合考虑了 session resuming ，session ticket后，
TLS 1.3 提出了3种handshake模式：

1. Diffie-Hellman （ 包含 DH 和 ECDH 两种，下文说到 ECDH 的地方，请自行脑补成 “ECDH/DH”）.

2. A pre-shared symmetric key (PSK) ，预先共享的对称密钥，此处用统一的模型来处理session resuming 和 rfc4279的psk

3. 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优化是有副作用的：

1. 0-RTT发送的应用数据没有前向安全性。

2. 跨连接可以重放0-RTT里的应用数据（任何服务器端无共享状态的协议，都无法做到跨连接防重放）

3. 如果服务器端 半静态 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 模式下：

如上表所示：

1. 完整的 1-RTT握手的时候， SS 和 ES 都是用的 ephemeral key ，这样是一定有前向安全性的。

2. 使用 0-RTT 的握手的时候，使用客户端的 ephemeral key 和 服务器端的半静态 ECDH 公钥生成 SS，

3. 纯 PSK，这种场景完全没有前向安全性，应该避免。

4. 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 并不相同。
如下表：

要关注的是， Early Data 的 Traffic Key 是用 xSS 算出来的。也就是说，是用 Pre-Shared Key决定的。因此是没有前向安全性的。

在一个TLS 连接中，究竟是用哪种 handshake 模式，是由 CipherSuite 协商决定的。