江苏龙网

  1. 首页 > 资讯 > 科技 > >

互联网|万字长文拿下HTTPS，面试不再慌！( 九 )


不过 TLS1.2 已经是 10 年前（2008 年）的老协议了 ， 虽然历经考验但毕竟 岁月不饶人 ， 在安全、性能等方面已经跟不上如今的互联网 。
经过四年近 30 个草案的反复打磨 ， TLS1.3 在 2018 年推出 ， 再次确立了信息安全领域的新标准 。
最大化兼容性
由于 1.1、1.2 等协议已经出现了很多年 ， 很多应用软件、中间代理（官方称为MiddleBox）只认老的记录协议格式 ， 更新改造很困难 ， 甚至是不可行（设备僵化） 。
在早期的试验中发现 ， 一旦变更了记录头字段里的版本号 ， 也就是由 0x303（TLS1.2）改为 0x304（TLS1.3）的话 ， 大量的代理服务器、网关都无法正确处理 ， 最终导致 TLS 握手失败 。

为了保证这些被广泛部署的老设备能够继续使用 ， 避免新协议带来的冲击 ， TLS1.3 不得不做出妥协 ， 保持现有的记录格式不变 ， 通过伪装来实现兼容 ， 使得 TLS1.3 看上去像是 TLS1.2 。
那么 ， 该怎么区分 1.2 和 1.3 呢？
这要用到一个新的扩展协议（Extension Protocol） ， 它有点 补充条款 的意思 ， 通过在记录末尾添加一系列的扩展字段来增加新的功能 ， 老版本的 TLS 不认识它可以直接忽略 ， 这就实现了后向兼容 。
在记录头的 Version 字段被兼容性固定的情况下 ， 只要是 TLS1.3 协议 ， 握手的 Hello 消息后面就必须有 supported_versions 扩展 ， 它标记了 TLS 的版本号 ， 使用它就能区分新旧协议 。
你可以看一下 Client Hello 消息后面的扩展 ， 只是因为服务器不支持 1.3 ， 所以就后向兼容降级成了 1.2 。
互联网|万字长文拿下HTTPS，面试不再慌！
本文插图
TLS1.3 利用扩展实现了许多重要的功能 ， 比如supported_groups、key_share、signature_algorithms、server_name等 ， 这些等后面用到的时候再说 。

强化安全
TLS1.2 在十来年的应用中获得了许多宝贵的经验 ， 陆续发现了很多的漏洞和加密算法的弱点 ， 所以 TLS1.3 就在协议里修补了这些不安全因素 。
比如：
伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function） 。

明确禁止在记录协议里使用压缩 。
废除了 RC4、DES 对称加密算法 。
废除了 ECB、CBC 等传统分组模式 。
废除了 MD5、SHA1、SHA-224 摘要算法 。
废除了 RSA、DH 密钥交换算法和许多命名曲线 。
经过这一番减肥瘦身之后 ， TLS1.3 里只保留了 AES、ChaCha20 对称加密算法 ， 分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305 。
摘要算法只能用 SHA256、SHA384 ， 密钥交换算法只有 ECDHE 和 DHE ， 椭圆曲线也被砍到只剩 P-256 和 x25519 等 5 种 。
算法精简后带来了一个意料之中的好处：原来众多的算法、参数组合导致密码套件非常复杂 ， 难以选择 ， 而现在的 TLS1.3 里只有 5 个套件 ， 无论是客户端还是服务器都不会再犯选择困难症了 。
互联网|万字长文拿下HTTPS，面试不再慌！
本文插图
这里还要特别说一下废除 RSA 和 DH 密钥交换算法的原因 。 在 RSA 密钥交换中 ， 共享密钥由客户端生成 ， 然后客户端利用服务器的公钥（从证书中提取）将共享密钥加密并将其发送到服务器 。

DH 算法由 Diffie 和 Hellman 于 1976 年发明 ， 即所谓的 Diffie-Hellman 密钥交换 。
在 Diffie-Hellman 中 ， 客户端和服务器都从创建 DH 参数对开始 。 然后 ， 他们将其 DH 参数的公共部分发送给另一方 。

当双方都收到对方方的公共参数时 ， 它们将它与自己的私钥组合在一起 ， 最终计算出同一个值：前主密钥 。 然后 ， 服务器使用数字签名来确保交换未被篡改 。


推荐阅读


上一篇：互联网|第四期携手立思辰——“工控安全风险解析”圆满举办

下一篇：启示录|“触手”死亡启示录：投奔腾讯成游戏直播的终局？