0. 前言

• 最近参与一个基于 BitTorrent 协议的 Docker 镜像分发加速插件的开发，主要参与补充 https 协议
• 学习了 TLS 相关知识，下面对之前的学习做一下简单总结
• 参考文献：TLS完全指南系列文章

1. 基本原理

• TLS 依赖两种加密技术：
  • 对称加密（symmetric encryption）
  • 非对称加密（asymmetric encryption）

1.1 对称加密

• 加密方和解密方共享同一个秘钥 K：

加密：C = E(M, K)

解密：M = D(C, K)

• 攻击者且听到 K 后就可以作为一个中间人伪装成任意一个对象，实现中间人攻击

1.2 非对称加密

• 非对称加密利用成对的两个秘钥：K1 和 K2，加密者使用一个加密，解密者可以利用另一个解密：

加密：C = E(M, K1)

解密：M = D(C, K2)

• 解密者生成一对秘钥，私钥保存，公钥公开
• 但是中间人可以截获公钥，然后自己生成一对秘钥，把自己的公钥发送给加密者
• 用自己的私钥解密加密者的信息，然后用解密者的公钥加密发送给解密者
• 或者中间人收到解密者公钥加密的消息后，对消息破坏篡改，再发送给解密者
• 导致解密者无法正确解析密文

1.3 数字签名

• 光靠非对称加密很难确定信息发送方身份，因此发明了数字签名
  • 根据数字签名，接收方接收到信息之后，可以判断信息是否被破坏过，如果没有被破坏，就可以正确的解码。如果被破坏，就直接丢弃
  • 数字签名可以保证对信息的任何篡改都可以被发现，从而保证信息传输过程中的完整性
  • 数字签名是实现的关键技术就是哈希技术
• 加密者先对将要传输的信息进行哈希，得到一串独一无二的信息摘要
  • 哈希函数往往是不可逆的，无法根据哈希后的内容推断原文；同时，不同的原文，会造成不同的哈希结果，并且结果的差异是巨大甚至毫无规律的
  • 对原文进行再细微的修改，得到的哈希后的内容都会与未经修改的原文的哈希内容大相径庭，保证消息内容不被篡改
• 然后，加密者将信息摘要，用自己的私钥进行加密
  • 这样就保证只有加密者的公钥才能对信息摘要进行正确的解码，进而保证信息摘要一定是来自加密者
  • 加密后的信息摘要实际就是数字签名的内容
• 最后，加密者再将数字签名附加到原文信息的后面，使用解密者公钥加密后发送给解密者
• 解密者接收到信息之后，首先使用自己的私钥解密报文，分别获得原文和数字签名
  • 利用加密者公钥对数字签名进行解密，得到信息摘要，如果成功解码，就说明数字签名是来自加密者
• 然后，解密者将信息原文进行哈希得到自己的信息摘要，与解码数字签名得到的信息摘要进行对比，如果相同，就说明原文信息完整，没有被篡改，反之，则确认信息被破坏了
• 目前为止，利用公钥和私钥以及数字签名，可以保证信息传输过程中的私密性和完整性
• 但还存在一个问题：就是公钥分发的问题，上述中间人劫持公钥的问题并没有解决
• 这个问题就需要数字证书和 CA 来解决了

1.4 数字证书和 CA

• 每个加密者或者接受者都有自己的私钥和公钥，如何判断对方的公钥是真实代表对方的是一个问题
• 实际我们会引入一个第三方机构，每个人都找这个真实可信的独立的第三方，请求真伪鉴别服务
• 第三方机构就是 CA（Certification Authorith，证书颁发机构）会给解密者创建一个数字证书
• “用户首先产生自己的密钥对，并将公钥及部分个人身份信息传送给认证中心
• 认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来
• 然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息”
• 公钥和身份信息（域名或者IP）合起来就是 CSR（certificate signing request，身份证申请）
• 实际过程可以看做 CA 利用自己的私钥对 CSR 加密，作为数字签名
• 然后 CSR 连同 CA 的数字签名构成数字证书，也称为 CRT（CA signed certificate）
• 在之后的发送中加密者将数字证书附在数字签名后
• 接收者收到后用 CA 的公钥解密获得，加密者的身份和公钥
• 攻击者不能通过 CA 的验证，无法获取证书，解密者接受后判断数字证书包含的身份信息不是加密者，因此会拒绝
• 但是如果选择信任了错误的 CA，也会被攻击，通常浏览器中会内置靠谱 CA 的身份证（公钥）

1.4 信任链、根身份证和自签名

• CA 也分为不同级别，需要逐级验证
• 比如 CA1 不被大家信任，于是可以将身份信息和公钥发送给受信任的 CA2，获得自己的数字证书
• CA1 在给其他人签署数字证书时，会在后面附上自己的数字证书
• 这样接受者首先利用 CA2 的公钥验证 CA1，获得 CA1 的公钥后再验证发送者
• 这样逐级签署数字证书，形成了一条信任链
• 最终的根节点就是自签名证书，如 CA2 可以用自己的私钥把自己的公钥和域名加密，生成证书

1.5 应用场景：https 协议

• 首先，浏览器向服务器发送加密请求
• 服务器将网页加密，连同自身的数字证书发送给浏览器
• 浏览器收到返回验证服务器身份，同时服务器也可以验证浏览器身份
  • 浏览器验证服务器是通过 TLS 身份验证实现的，服务器验证浏览器是通过输入用户名密码实现的，通常服务器不会验证浏览器身份
  • 客户端（浏览器）的“证书管理器”，有“受信任的根证书颁发机构”列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内

• • 如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告

• • 如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告

• • 如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息

2. 小结

• 本文整理了一些数字签名、数字证书的知识，之前也有了解，但是一些概念细节理解不很清晰
• 现在做了整理，方便以后复习。也是对后面的铺垫
• 欢迎各位批评指正

3. 参考文献

• TLS完全指南（一）：TLS和安全通信
• 数字签名和数字证书
• 数字签名和数字证书究竟是什么？