关于im:TLS协议分析-七-安全性分析

平安剖析，重中之重，也是大家最关怀的。

平安剖析的第一步是建设攻打模型，TLS 的攻打模式是：

攻击者有短缺的计算资源
攻击者无奈失去私钥，无奈失去客户端和服务器内存外面的密钥等窃密信息
攻击者能够抓包，批改包，删除包，重放包，篡改包。

这个模型其实就是密码学外面个别假设的攻打模型。

好了，在这个模型下，TLS 的安全性剖析如下：

TLS 有三种认证模式：单方认证，服务器认证，无认证。
只有蕴含了有服务器端认证，就能够免疫 man-in-the-middle 攻打。然而齐全匿名的会话是能够被 MITM 攻打的。匿名的服务器不能认证客户端。

密钥替换的目标，是产生一个只有通信单方晓得的共享密钥 pre_master_secret。pre_master_secret 用来生成 master_secret。master_secret 用来生成 Finished 音讯，加密 key，和 MAC key。通过发送正确的 Finished 音讯，单方能够证实本人晓得正确的 pre_master_key。

匿名密钥替换是一种历史遗留的不平安形式。匿名密钥替换缺失认证(Authentication)，所以绝大多数场景下，咱们应该禁用这种形式。

当应用 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 确保签名和以后握手流程绑定(即不能重放)。

当应用 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 群已知的话，客户端做简略比对就行了，因而服务器能够应用一个已知的群，来不便客户端的查看。

因为 TLS 历史上呈现过多个版本，服务器端实现可能会兼容多个版本的协定，而像 SSL 2.0 这样的版本是有重大平安问题的，因而攻击者可能会尝试诱骗客户端和服务器，来使 TLS 连贯回退到 SSL 2.0 这种老版本。

TLS 对此的解决办法，就是 PreMasterSecret 外面蕴含版本号。

攻击者可能会尝试影响握手过程，来使单方抉择不平安的加密算法。

对这种攻打的解决办法是，如果握手音讯被篡改了，那么在 Finished 音讯里，客户端和服务器都会计算握手音讯的 hash，如果攻击者篡改了握手音讯，那么单方得出的 hash 就不一样，这样 Finished 音讯就会验证不过。就会发现攻打。

当应用 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 写入长久存储。

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 就简略了。

如前文所述，TLS 1.0 是把前一条音讯的最初一个 block，当作下一条音讯的第一个 IV 的，这促成了 2004 年公开的 BEAST 攻打，起初就改成这种显式 IV 的更平安的形式了。

前文介绍 CBC 和 AEAD 时已有剖析，此处略过。

TLS 容易蒙受某些 DoS 攻打。例如，攻击者创立很多 TCP 连贯，就能够让服务器忙于做 RSA 解密计算。然而，因为 TLS 运行在 TCP 之上，只有操作系统 TCP 栈的 SYN-ACK 里 seqnum 是随机的，攻击者就无奈暗藏本人的 ip，这样就能够和个别的 TCP 连贯一样做 DOS 进攻。

因为 TLS 运行在 TCP 上，每个独立的连贯都可能蒙受一系列 DOS 攻打。尤其是，攻击者能够伪造 RST 包，来中断一条 TCP+TLS 连贯。或者伪造局部 TLS 记录，导致连贯阻塞挂起。不过这些攻打都是任何 TCP 协定都有问题，不是 TLS 特有的。

Ticket 必须: 1. 有 MAC（即 authenticated，不可篡改），2. 加密（即窃密）。

上面剖析在各种攻打办法下的安全性。

TLS 协定要求当发现错误的时候，把 TLS session 变为有效。

这不会影响到 ticket 的安全性。

攻击者或者中间人，可能会窃取到 ticket，并且尝试用来和 server 建设会话。
然而，因为 ticket 是加密过的，并且攻击者不晓得密钥，窃取到的 ticket 无奈使攻击者复原会话。
TLS 服务器必须应用强加密和 MAC 算法，来爱护 ticket。

一个歹意用户可能会伪造，或者篡改一个 ticket，来复原一个会话，来缩短 ticket 的生命周期，或者伪装成另一个用户。

然而，因为服务器应用了强的校验爱护算法，比方带明码的 HMAC-SHA1，因而无奈未遂。

举荐 ticket 格局中的 key_name 字段帮忙服务器无效地回绝不是本人签发的票据。
因而，一个攻击者可能发送大量的 ticket，让服务器忙于验证 ticket。
然而，只有服务器应用了高效的加密和 MAC 算法，就不会有问题。（事实中，加密和 MAC 算法效率都极高，这基本不是问题）

加密 ticket 的 key 的治理，举荐的做法：

key 应该用密码学平安的随机数生成器生成，依照 RFC4086。
key 和加密算法起码应该是 128 比特平安水平的。
key 除了加密和解密 ticket 以外，不应该有其余用处。
key 应该定期更换
当 ticket 格局更换，或者算法更换时，应该更换 key

TLS 服务器管制 ticket 的生命周期。服务器依据配置来决定能够承受的 ticket 生命周期。
ticket 的生命周期可能会长于 24 小时。TLS 客户端可能会承受到一个 ticket 生命周期的提醒，当然，客户端本地的策略最终决定 ticket 保留多久。

如果没应用举荐的 ticket 格局，那必须小心地剖析计划的安全性。尤其是，如果窃密数据比方窃密密钥传输给了客户端，那必须用加密形式传输，来避免泄露或篡改。

ticket 的加密和加 MAC，就保障了敏感信息不会泄露。

因为在 ticket 解密之前的 TLS 握手，无奈暗藏客户端的特色，因而中间人可能依据雷同的 ticket 被复用，发现雷同的 ticket 属于雷同的用户。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)的网络调用，而提出的。

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…

http://googleonlinesecurity.b…

https://blog.mozilla.org/secu…

https://www.dfn-cert.de/dokum…

https://www.cs.utexas.edu/~sh…

解决方案：

https://developer.mozilla.org…

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

https://www.certificate-trans…

破绽剖析很耗时间，这里总结一些材料，有趣味的本人看吧。

尽管 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…

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

[人人网应用 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.
…

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

因为只保留了 aead，所以不须要 MAC key 了。

aead 的具体参数用法也有调整，前文有。

KDF 换成了规范的 HKDF，有 2 种 tls_kdf_sha256, tls_kdf_sha384

鉴于 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，前两者合体

首先，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

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)）

TLS 1.3 外面，把 session resumption/session ticket 复原进去的 key，和 psk (rfc4279)，对立在一个 handshake PSK 模式下解决。

PSK CipherSuite 能够把 PSK 和 ECDHE 联合起来用，这样是有前向安全性的。
也能够仅仅应用 PSK，这样就没有前向安全性。

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…

关于im:TLS协议分析-七-安全性分析

9. TLS 协定的平安剖析

9.1. 认证和密钥替换的安全性

9.1.1 匿名密钥替换

9.1.2. RSA 密钥替换和认证

9.1.3. Diffie-Hellman 密钥替换和认证

9.2. 版本回退攻打

9.3. 针对握手过程的攻打

9.4. 针对 Resuming Sessions 的攻打

9.5. 针对利用数据保护的攻打

9.6. 显式 IV 的安全性

9.7. 加密和 MAC 组合模式的安全性

9.8. DOS 攻打下的安全性

9.9.Session Ticket 的平安剖析

9.9.1. 有效的 Session

9.9.1. 窃取 Tickets

9.9.2. 伪造 Tickets

9.9.3. DoS 攻打

9.9.4. 加密 Ticket 的 key 的治理

9.9.5. Ticket 的有效期

9.9.6. 其余的 Ticket 格局和散发办法

9.9.7. Identity Privacy, Anonymity, and Unlinkability

10. TLS 扩大:

11. TLS 的配套：PKI 体系

11.1. X.509 证书

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

(1). public key pin

(2). HSTS

(3). Certificate Transparency

12. TLS 协定历史上呈现过的破绽，密码学常见陷阱

12.1. TLS 的破绽

12.2. 密码学常见陷阱

13. 下一代 TLS: TLS 1.3

13.1. record 层的密码学爱护的改变

13.2.handshake 协定的改变

13.3. 1-RTT 握手

13.4. 有副作用的 0-RTT 握手

13.5. Resumption 和 PSK

13.6. Key Schedule 过程的改变

Just My Socks（注册教程内含优惠码）

关于im:TLS协议分析-七-安全性分析

9. TLS 协定的平安剖析

9.1. 认证和密钥替换 的安全性

9.1.1 匿名密钥替换

9.1.2. RSA 密钥替换和认证

9.1.3. Diffie-Hellman 密钥替换和认证

9.2. 版本回退攻打

9.3. 针对握手过程的攻打

9.4. 针对 Resuming Sessions 的攻打

9.5. 针对利用数据保护的攻打

9.6. 显式 IV 的安全性

9.7. 加密和 MAC 组合模式的安全性

9.8. DOS 攻打下的安全性

9.9.Session Ticket 的平安剖析

9.9.1. 有效的 Session

9.9.1. 窃取 Tickets

9.9.2. 伪造 Tickets

9.9.3. DoS 攻打

9.9.4. 加密 Ticket 的 key 的治理

9.9.5. Ticket 的有效期

9.9.6. 其余的 Ticket 格局和散发办法

9.9.7. Identity Privacy, Anonymity, and Unlinkability

10. TLS 扩大:

11. TLS 的配套：PKI 体系

11.1. X.509 证书

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

(1). public key pin

(2). HSTS

(3). Certificate Transparency

12. TLS 协定历史上呈现过的破绽，密码学常见陷阱

12.1. TLS 的破绽

12.2. 密码学常见陷阱

13. 下一代 TLS: TLS 1.3

13.1. record 层的密码学爱护的改变

13.2.handshake 协定的改变

13.3. 1-RTT 握手

13.4. 有副作用的 0-RTT 握手

13.5. Resumption 和 PSK

13.6. Key Schedule 过程的改变

Just My Socks（注册教程 内含优惠码）

9.1. 认证和密钥替换的安全性

Just My Socks（注册教程内含优惠码）