乐趣区

关于im:TLS协议分析-一-设计目标及历史

jiezi

最近发现密码学很有意思，刚好还和工作有点关系，就钻研了一下，本文是其中一部分笔记和一些思考。

密码学实践艰深，概念繁多，自己常识程度无限，谬误不免，如果您发现错误，请务必指出，非常感谢!

本文指标：

  1. 学习鉴赏 TLS 协定的设计，透彻了解原理和重点细节
  2. 跟进一下密码学应用领域的历史和停顿
  3. 整顿古代加密通信协议设计的个别思路

本文有门槛，读者须要对古代密码学有清晰而零碎的了解，本文最初的参考文献里有一些很不错的学习材料。

目录 :

TLS 协定剖析 与 古代加密通信协议设计
一 . TLS 协定的设计指标：1. 密码学的方法论
2. TLS 的设计指标
3. TLS 的历史
二. TLS 协定的原理
1. 自顶向下，分层形象
2. TLS CipherSuite
3. 协定分层
4. record 协定
4.1. SecurityParameters
4.2. record 层分段
4.3. record 层的密码学爱护
4.4. record 层的密码学爱护 --MAC
4.5. record 层的密码学爱护 --stream cipher
4.6. record 层的密码学爱护 -- CBC block cipher
4.7. record 层的密码学爱护 -- AEAD cipher
4.8. record 层的密码学爱护 -- Key 扩大
5. handshake 协定
5.1.handshake 的总体流程
5.2. handshake 协定外层构造
5.3. handshake -- ClientHello，ServerHello，HelloRequest
5.4. handshake -- Server Certificate
5.5. handshake -- Server Key Exchange
5.6. handshake -- Certificate Request
5.7. handshake -- Server Hello Done
5.8. handshake -- Client Certificate
5.9. handshake -- Client Key Exchange
5.9.1. RSA 加密的 Premaster Secret 音讯
5.9.2. 客户端 Diffie-Hellman 公钥
5.9.3 客户端 EC Diffie-Hellman 公钥
5.10. handshake -- Cerificate Verify
5.11. handshake -- Finished
5.12. handshake -- NewSessionTicket
6. ChangeCipherSpec 协定
7. Alert 协定
8. application data 协定
9. TLS 协定的平安剖析
9.1. 认证和密钥替换 的安全性
9.2. 版本回退攻打
9.3. 针对握手过程的攻打
9.4. 针对 Resuming Sessions 的攻打
9.5. 针对利用数据保护的攻打
9.6. 显式 IV 的安全性
9.7. 加密和 MAC 组合模式的安全性
9.8. DOS 攻打下的安全性
9.9.Session Ticket 的平安剖析
10. TLS 扩大:
11. TLS 的配套：PKI 体系
11.1. X.509 证书
11.2. 现有 PKI 体系暴露出的问题
11. TLS 协定历史上呈现过的破绽，密码学常见陷阱
11.1. TLS 的破绽
12.1. TLS 的破绽
12.2. 密码学常见陷阱
13. 下一代 TLS: TLS 1.3
三. TLS 协定的代码实现
四. TLS 协定的部署与优化
五. 更多的加密通信协议 case：QUIC，iMessage，TextSecure, otr, ios HomeKit，libsodium
1. QUIC
2. apple ios iMessage
3. apple ios HomeKit
4. TextSecure
5. otr 协定
6. libsodium/NaCL 等
六. TLS 协定给咱们的启发 -- 古代加密通信协议设计
七. 附录：密码学根底概念
八. 参考文献：1. TLS/SSL 相干 RFC 及规范
2. 协定剖析文章
3. 理论部署调优相干
4. 密码学相干
5. 相干开源我的项目

一 . TLS 协定的设计指标：

1. 密码学的方法论

密码学和软件开发不同，软件开发是工程，是手艺，造轮子是写代码的一大乐趣。软件开发中经常有各种衡量，个别难有明确的对错，个别还用修建来比较软件的构造，设计的优雅被高度重视。

密码学就不一样了。[密码学是迷信，不是工程] 见 http://www.daemonology.net/bl…，有严格的技术规范，严禁没有通过学术训练者随便发明。要求谨严的实践建模，紧密的数学证实。很少有须要衡量的中央，正确就是正确，谬误就是谬误。又因为密码学过来在军事上的重要价值，各国政府始终投入大量人力物力财力，不断深入强化己方的算法，破解对手的算法，所以密码学就是一种残暴的军备竞赛。

  • 密码学有很多的陷阱（下文会介绍几个），设计应用密码学的协定或者软件，是极其容易出错，高风险的业余流动，单纯的码农背景是做不了的。本着 不作死就不会死 的平凡理念，首先举荐读者尽可能应用 TLS 这种标准化，开源，宽泛应用，久经考验，高性能的协定。本文也只是整顿一点浅显的科普常识，读完这篇文章，并不能使读者具备设计足够平安的密码学协定的能力。
  • 密码学通过几十年的军备竞赛式倒退，曾经倒退出大量奇妙而刁滑的攻打办法，咱们应用的算法，都是在所有已知的攻打办法下都无奈攻破的，因为咱们大多数码农并没有精力去理解最前沿的攻打办法，所以咱们其实并没有能力去评估一个加密算法，更没有能力本人创造算法。所以最好跟着业界的支流技术走，必定不会有大错。
  • 古代密码学近 20 年停顿迅猛，当初搞古代密码学钻研的次要都是数学家，在这个畛域外面以一个码农的常识背景，曾经很难了解最前沿的货色，连正确应用加密算法都是要审慎审慎再审慎的。一个码农，能理解密码学基本概念，跟进密码学的最新利用趋势，并正确配置部署 TLS 这种协定，就很不错了。

  • 密码学算法很难被正确地应用，各种细节非常容易出错。

    例如：

    • 1. 大多数码农都据说过 aes，可是大多数都不理解细节，比方：aes 应该用哪种模式？应该用哪种 padding？IV/nonce 应该取多少 bit？IV/nonce 应该怎么生成？key size 应该选多大？key 应该怎么生成？应不应该加 MAC？MAC 算法的抉择？MAC 和加密应该怎么组合？
    • 2. 大多数晓得 RSA 的码农分不清 RSASSA-PKCS1-v1_5，RSAES-OAEP 和 RSASSA-PSS
    • 3. 更多谬误参见 [这个 stackoverflow 问答，强烈推荐仔细阅读] 见 http://security.stackexchange…
  • 密码学算法很难被正确地实现(代码实现过程中会引入很多破绽，比方 HeartBleed，比方各种随机数生成器的 bug，工夫侧通道攻打破绽)
  • 不能只知其一; 不知其二，相对不能在只知其一; 不知其二的状况下就入手设计密码学协定。犹如“盲人骑瞎马，日班临深池”。
  • 不能闭门造车，密码学相干协定和代码肯定要开源，采纳大集市式的开发，承受 peer review，被越多的人 review，出破绽的可能越小（所以应该尽可能应用开源组件）

2. TLS 的设计指标

TLS 的设计指标是构建一个平安传输层（Transport Layer Security），在基于连贯的传输层（如 tcp）之上提供：

  1. 密码学平安
    (1). 窃密，message privacy (窃密通过加密 encryption 实现，所有信息都加密传输，第三方无奈窃听)
    (2). 完整性，message integrity（通过 MAC 校验机制，一旦被篡改，通信单方会立即发现）
    (3). 认证，mutual authentication（单方认证, 单方都能够装备证书，避免身份被假冒）
  2. 互操作，通用性（依据公开的 rfc，任何合乎 rfc 的软件实现都能够互操作，不受限于任何专利技术）
  3. 可扩展性 (通过扩大机制 tls_ext 能够增加性能，有大量的新性能，都是通过扩大增加的)
  4. 高效率（通过 session cache，失当部署 cache 之后，tls 的效率很高）

请认准这几个指标，在后文中，会逐个实现。

3. TLS 的历史

  • 1995: SSL 2.0, 由 Netscape 提出，这个版本因为设计缺点，并不平安，很快被发现有重大破绽，曾经废除。
  • 1996: SSL 3.0. 写成 RFC，开始风行。目前 (2015 年) 曾经不平安，必须禁用。
  • 1999: TLS 1.0. 互联网标准化组织 ISOC 接替 NetScape 公司，公布了 SSL 的升级版 TLS 1.0 版.
  • 2006: TLS 1.1. 作为 RFC 4346 公布。次要 fix 了 CBC 模式相干的如 BEAST 攻打等破绽
  • 2008: TLS 1.2. 作为 RFC 5246 公布。增进安全性。目前 (2015 年) 应该次要部署的版本，请确保你应用的是这个版本
  • 2015 之后: TLS 1.3，还在制订中，反对 0 -rtt，大幅增进安全性，砍掉了 aead 之外的加密形式

因为 SSL 的 2 个版本都曾经退出历史舞台了，所以本文前面只用 TLS 这个名字。
读者应该明确，个别所说的 SSL 就是 TLS。

余下内容请见后续文章。

​ 本文转自微信后盾团队, 如有进犯, 请分割咱们立刻删除

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…

退出移动版