【TLS】TLS/SSL笔记

目录

• 前言
• 概念
  • 对称加密
  • 非对称加密
  • 公钥
  • 单向加密
  • 数字签名
• 基础
  • 作用
  • SSL/TLS 模型
  • 运作
    • 问题&解答
    • 基本过程
  • 握手阶段
    • 客户端发出请求（ClientHello）
    • 服务器回应（SeverHello）
    • 客户端回应
    • 服务器的最后回应
• HTTPS 流程图参考

---

前言

主要是自己学习SSL流程时的辅助理解笔记。
包括数字证书前面为什么值得信任。

• 注意：多级CA还没有时间去记录，可能后期遇到再补。

参考：

• https://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
• 数字证书原理

李柱明博客：https://www.cnblogs.com/lizhuming/p/15487016.html

概念

理解为主，非官方描述。

对称加密

对称加密：

• 明文 P，加上密码 W 一混淆之后，变成密文 M。

• 如果不知道 W，则无法从 M 反推回 P。

• 例子：

  • 异或。密钥与明文异或得到密文。异或的特点使得，密文与密钥进行异或，可以还原密文。
  • 

非对称加密

非对称加密：

• 非对称加密使用的密码有一对：

  • 一个称为公钥 Pub
  • 一个称为私钥 Priv

• 明文 P，经过公钥 Pub 加密后，变成密文 M。

• 密文 M 只有私钥 Priv 能解开。

• 若是结果私钥 priv 加密，就只由公钥 pub 能解开。

公钥

公钥：公钥，就是可以公开出去可以供所有人使用的密钥。
私钥：私钥，需要保护好。
密码：密码，需要保护好。

单向加密

单向加密：

• 无法反推的加密。
• 如 hash。常用于比较明文是否被篡改。

数字签名

知道公钥和私钥后。

基础

作用

SSL/TLS 协议是为了解决这三大风险而设计：

• 所有信息都是加密传播，第三方无法窃听。
• 具有校验机制，一旦被篡改，通信双方会立刻发现。
• 配备身份证书，防止身份被冒充。

SSL/TLS 模型

运作

SSL/TLS 协议的基本思路是采用 公钥加密法。
公钥加密法：即是客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

问题&解答

1. 如何保证公钥不被篡改？

   • 解决：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

2. 公钥加密计算量太大，如何减少耗用的时间？

   • 解决：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

3. 数字证书验证原理：

   • 在握手阶段，服务端会把服务端的公钥放到 CA 颁发的数字证书中。
   • CA 颁发数字证书，会给数字证书签名。
   • 签名就是把数字证书经过 hash 算法得出 hash 值，然后用 CA 机构的私钥给该 hash 值加密，这个加密值就是签名。
   • 服务端把数字证书、 CA 机构的签名和哪一个 CA 机构发送到客户端。
   • 客户端在自己信任的 CA 列表中找到和服务端发过来的 CA 机构，说明客户端信任该机构。
   • 然后客户端把数字证书结果相同的 hash 算法得出 hash 值，且使用该 CA 机构的公钥对服务端发来的签名进行解密，若两值相等，则说明证书可靠。
   • 数字证书签名和验证如下图：
   • 

4. SSL 过程中数字证书内容：

   1. 内容本端公钥。
   2. 证书所有者。
   3. 证书的发布机构。
   4. 证书的有效期。
   5. 等等。

基本过程

1. 客户端向服务器端索要并验证公钥。
2. 双方协商生成"对话密钥"。
3. 双方采用"对话密钥"进行加密通信。

前两步称为 握手阶段 （handshake）。

握手阶段

握手阶段涉及四次通信。

• 客户端发出请求（ClientHello）
• 服务器回应（SeverHello）
• 客户端回应
• 服务器的最后回应

握手阶段都是明文通信。

客户端发出请求（ClientHello）

客户端先向服务器发出加密通信的请求，主要向服务器提供以下信息：

1. 支持的协议版本。
2. 一个客户端生成的随机数，稍后用于生成"对话密钥"。
3. 支持的加密方法，比如 RSA 公钥加密。
4. 支持的压缩方法。

服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，服务器的回应包含以下内容：

1. 确认使用的加密通信协议版本。
2. 一个服务器生成的随机数，稍后用于生成"对话密钥"。
3. 确认使用的加密方法，比如 RSA 公钥加密。
4. 服务器证书。
5. 要求客户端提供客户端证书。（这个取决于服务器是否需要确认客户端的身份）

客户端回应

客户端收到服务器回应以后，首先验证服务器证书：

• 证书是否可信机构颁布；
• 证书中的域名与实际域名是否一致；
• 证书是否已经过期。

若证书有问题，可以停止握手操作。

若证书没问题，客户端就会从证书中取出服务器的公钥。

然后，向服务器发送下面三项信息：

1. 一个随机数（pre-master key）。该随机数用服务器公钥加密，防止被窃听。
2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供服务器校验。
4. 如果服务器要求客户端提供证书，客户端发送证书及相关信息。

小笔记：

• 握手阶段产生三个随机数。保证生成的密钥不会每次都一样。
• 三个随机数通过一个密钥导出器最终导出一个对称密钥。
• 三个随机数是因为双方都不能保证对方的随机数是真的随机，所以自己也产生一个随机数，这样就不能被猜出来。

服务器的最后回应

服务器收到客户端的第三个随机数 pre-master key 之后，计算生成本次会话所用的"会话密钥"。然后向客户端发送以下信息：

1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

2. 服务器握手结束通知，表示服务器的握手阶段已经结束。

   • 这一项同时也是前面发送的所有内容的 hash 值，用来供客户端校验。

握手结束后就可以继续 http 协议继续通信了。只不过是加密会话而已。

• ssl 作用在应用层与传输层之间，它并不晓得应用层的东西。不必理会 url、header、body，应用层传传下来的数据到达传输层前，只需要把整个数据包都加密就完事了。

HTTPS 流程图参考

• 简版
  

• 目前主流的 TLS 的握手过程