TLS 协议分析 (七) 安全性分析

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 或者 ECTLS 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 TicketSession 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 协商决定的。

​ 本文转自微信后台团队,如有侵犯,请联系我们立即删除

OpenIMgithub 开源地址：

https://github.com/OpenIMSDK/Open-IM-Server

OpenIM 官网 ： https://www.rentsoft.cn

**OpenIM 官方论坛： ** https://forum.rentsoft.cn/

更多技术文章：

开源 OpenIM：高性能、可伸缩、易扩展的即时通讯架构https://forum.rentsoft.cn/thread/3

【OpenIM 原创】简单轻松入门 一文讲解 WebRTC 实现 1 对 1 音视频通信原理https://forum.rentsoft.cn/thread/4

【OpenIM 原创】开源 OpenIM：轻量、高效、实时、可靠、低成本的消息模型https://forum.rentsoft.cn/thread/1