对称加密_非对称加密_数字签名_证书_HTTPS

HTTPS

前置知识拓展：单向散列函数（one-way-hash-function)

• 单向散列函数的特点：

1. 根据消息内容计算出固定长度的散列值
2. 消息不同，散列值也不同
3. 也被成为消息摘要函数（也叫哈希函数、指纹）

常见的散列函数：

- md5
- SHA

单向散列函数的应用：防止数据被篡改（内容不一样，散列值一定会不一样）

一. HTTP协议的安全问题：

1. 对称加密

1.1 对称加密的秘钥配送问题：

• 密钥配送容易被窃取，不安全

2. 非对称加密

2.1 公钥私钥

2.2 如何解决秘钥配送问题

在对称加密中， A B需要交换彼此的公钥。

1. 加密：A发消息使用B的公钥加密， B发消息是使用A的公钥加密

2. 解密都是使用自己的私钥

2.3 解决非对称密钥配送问题：

1. 由消息的接收者，产生一对公钥、私钥
2. 将公钥发给消息的发送者
3. 消息的发送者使用公钥（具体来说是使用消息接收者的公钥）加密消息
4. 非对称加密的加密速度比对称加密要慢

2.4 混合密码系统（结合两者的优点，这也是TLS所使用的方法）

2.4.1 混合密码——加密、解密

这里涉及到会话秘钥：（A和B通信一定使用对称加密，因为快， 会话秘钥专门用来加密A和B会话的消息）

1. 会话密钥是本次通信`随机生成`的一个`临时秘钥`
2. 会话密钥会作为`对称加密`的密码， 用于加密消息，提高速度（对称加密的速度快）

生成会话密钥的步骤：(站在消息发送者的角度)

1. 伪随机数生成器生成一个临时的会话密钥（用于对消息进行对称加密）——> 
2. 利用会话密钥对明文进行对称加密，得到`密文1`

虚线左半部分解决对称加密的缺陷：（密钥容易被窃听的问题）

1. 消息发送者得拥有消息接收者的公钥（公钥谁都可以有，不觉得奇怪）

2. 使用消息接收者的公钥对随机生成的会话密钥进行（非对称）加密，也得到一个密文，假如为密文2。

3. 将密文1和密文2进行组合，组合的内容实际上就是：

   ​ 用接收者的公钥加密的会话密钥 + 用对称密码（会话密码）加密的消息

   ​ || ||

   ​ 可以使用接收者的私钥解密得到会话密钥 使用前面解密的会话密钥解密 加密的消息得到明文

关键点： 使用对称加密加密消息是因为对称加密加密速度很快（明文很多，加密效率高）

​ 结合非对称加密（接受者的公钥加密会话密钥），保证加密消息的密钥不被窃听

3. 数字签名

3.1 如何保证消息的完整性：——引出数字签名

3.2 数字签名的2种行为：生成签名和验证签名

• A在发消息的同时会带上签名，B接收到消息后会 “验证密钥”
• 如何保证签名是消息发送者自己签的呢？—— 用消息发送者的私钥进行签名

3.3 数字签名的过程

假如 Alice 给 Bob 发送的消息就是明文 ：'我爱你 Bob'

1. Alice 会用自己的私钥对 '我爱你 Bob' 这段消息进行加密，生成签名，同时发送给Bob

2. Bob 收到签名后会用Alice的公钥对这个签名进行解密（这个签名使用Alice的私钥加密的）

3. 对比 签名解密后的消息 和 我爱你Bob, 如果一直就说明Alice发的消息确实是完整的，没有被篡改和劫持。

4. 假如 Alice 发的消息被篡改成了 我讨厌死你啦 ，Bob, 此时用 Alice 的私钥加密的签名不一样，解密后自然和我爱你 Bob 不一致，很显然是被篡改过。

总结： 通过使用消息发送者的私钥对消息进行加密，产生签名，消息接收者可以使用消息发送者的私钥进行解密来对比看消息是否是完整没有篡改过的。

问题： 直接使用私钥对消息进行加密生成签名，这样实际上是不好的，因为消息很长，涉及到非对称加密，相对比较慢。因此需要改进。

改进措施：我们可以使用单向散列函数让消息产生一个散列值（hash 一般长度固定，比较短），然后对散列值进行加密生成签名，最后比对散列值就行了，性能就更好啦。具体过程如下：

3.4 数字签名——过程改进

主要是看右边的过程，注意这里的区别，这里Alice自己生成一对密钥对，这是为了Alice自己发的消息，不容易被别人篡改。别人可以识别一下这个消息是不是Alice发的。

1. Alice把自己的消息生成一个散列值，然后用自己的私钥对这个散列值进行加密，这样就生成了签名。

2. Alice 把消息和签名发送给Bob，Bob用Alice的公钥可以对签名进行解密，可以解密出散列值，发送给BOb的消息也可以使用单向散列函数计算出散列值，然后对比散列值就可以看消息是否是完成没有篡改过。

从上面可以看出数字签名的作用：

1. 数字签名并不能保证机密性，仅仅是为了能够识别内容有没有被篡改过（签名验证失败，就是篡改过的）
2. 确认消息的完整性，防止发送人否认消息的发送

3.5 非对称加密——公钥私钥再总结：

1. 在非对称加密中，任何人都可以使用公钥进行加密

2. 在数字签名中，任何人都可以使用公钥验证签名

   

   	公钥	私钥
   非对称加密	发送者加密时使用	接收者解密时使用
   数字签名	验证者验证签名时使用	签时使用名者生成签名
   谁持有密钥？	只要有需要，任何人都可以持有	个人持有

   • 既然是加密，那肯定是不希望别人看到我的消息，所以只有我才能解密

   • 公钥负责加密，私钥负责解密

   • 既然是签名，那肯定时不希望有人冒充我发消息，所以只有我才能签名

   • 私钥负责签名，公钥负责验签

4. 证书——公钥的合法性问题

4.1 公钥的合法性

如果遭遇了中间人攻击，那么公钥将可能是伪造的，看下图：

​

消息发送者Alice在拿消息接收者Bob的公钥的时候如果被中间人Mallory截取，中间人把自己的公钥发给了Alice，那么Alice会误以为自己拿到的是Bob的公钥，实际上Alice发消息的时候是使用的Mallory的公钥进行加密的，这样Alice发的消息在被Mallory截取的时候，Mallory就可以使用自己的私钥进行解密。同时，Mallory因为有Bob的公钥，他还可以使用Bob的公钥给Bob发消息。这样就问题比较多了。

• 其实看到这里，我们发现比较突出的问题就是，Alice如何确认自己拿到的就是Bob的公钥。
• 所以上面涉及到的所有加密，不管是对称、非对称、还是混合密码系统，包括数字签名的生成，都需要公钥的传递过程，这个过程就很容易被中间人攻击，是不安全的。

4.2 证书

证书是由权威机构认证的，密码学中证书全程叫公钥证书

• 证书里面有姓名、邮箱、以及此人的公钥

• 并由认证机构施（CA）加数字签名

• CA是能够认定公钥确实属于此人，并能够生成数字签名的个人或组织

可以简单理解为：

​ 公钥证书 = 个人信息 + 个人公钥 + CA数字签名

4.3 证书使用

使用步骤：

1. Bob 生成密钥对

2. Bob 在认证机构注册自己的公钥

3. 认真机构用自己的私钥对Bob的公钥施加数字签名并生成证书

4. Alice可以拿到认证机构的数字签名和Bob的公钥（证书）

5. Alice使用认证机构的公钥验证数字签名（因为数字签名是使用认证机构的私钥加密的），如果验证后确实和Bob的公钥一致，那么可以保证Bob公钥的合法性

6. Alice 用 Bob的公钥加密消息并发送给 Bob

7. 消息接收者Bob可以用自己的私钥对消息进行解密得到Alice发的消息

   • 使用过程可以参考下图理解：

   

• 这里有一个疑问：Alice需要使用认证机构的公钥来验证签名，那如何保证认证机构公钥的合法性问题呢？万一Alice拿到的公钥是假的呢？实际上，如果公钥是假的，验签会失败。

  答：一般我们的操作系统和浏览器会内置一些权威机构的证书

4.4 证书注册和下载

​

一句话：证书的作用是保证Alice确实可以拿到Bob本人的公钥。

总结

1. 一开头我们引出了单向散列函数，可以对内容加密使之变成固定长度的hash值，但缺点是不可逆
2. 可逆的加密方式我们提到了两种——对称加密（DES，AES）和非对称加密（RSA）
3. 对称加密的特点是加密解密速度快，加密解密用的是同一个密钥，存在的问题是在传输密钥的过程中容易被窃取，存在安全问题
4. 非对称加密，相对更安全，但加密解密相对慢一些。作为消息接收者的公钥谁都可以拥有，被窃听到公钥也没关系，用这个公钥进行加密消息给我，我用自己的私钥解密，没问题，但是如果发消息一直使用非对称加密，相对会慢很多。不太推荐直接使用。因此引出混合密码系统
5. 混合密码系统：用对称加密去加密消息，用非对称加密来加密会话密钥。两者相结合，速度又快又安全。混合密码系统还是得拥有接收者的公钥，一旦涉及到传输公钥，就有可能会被中间人攻击，可以伪造公钥。
6. 因此引出了数字签名来生成证书，来保证传递过来的公钥信息确实是完整并没有被篡改过的。
7. 数字签名是怎么一回事呢？数字签名是消息发送方用自己的私钥签名，消息接受方用消息发送者的公钥验签，防止别人伪造
8. CA机构用自己的权威身份来作为背书，消息接收者把自己的公钥和个人信息交给权威机构，CA机构使用自己的私钥对消息接收方的公钥施加数字签名并生成证书。证书里面有消息接收方的公钥和数字签名。消息发送者会使用消息接收的公钥对数字签名进行验签，从而确定公钥的合法性。

二. HTTPS

• HTTPS：超文本传输安全协议 （HTTP over TLS）

• 默认端口： 443

• 我们输入 http://www.baidu.com ,服务器会返回307响应码，然后通过 Location 重定向到 https://www.baidu.com

• HTTPS 是在 HTTP 的基础上使用 SSL / TLS 来加密报文，对窃听和中间人攻击提供合理的防护

1. TLS

• TLS： 传输层安全性协议

• 前身是 SSL（安全套接层）

• 位于哪一层： 传输层和应用层之间

• TLS 设计的目的：

  1. 身份验证：与我通信的是不是那个人（主要通过证书）
  2. 保密性：第三方拿不到明文，只能看到密文
  3. 完整性

2. HTTPS 的成本

• 证书的费用
• 加解密计算
• 降低了访问速度

3. HTTPS 的通信过程

总体分为3个阶段：

1. TCP 3 次握手
2. TLS 的连接
3. HTTP 请求和响应

4. TLS1.2 的连接

• handshake 握手协议

  • 验证通讯双方的身份（使用证书）
  • 交换加解密的安全套件
  • 协商加密参数

• record 协议

  • 对称加密

步骤：

1. Client Hello（客户端发往服务端）====》

   • TLS 版本号
   • 支持的加密套件列表
   • 一个随机数（Client Random）

2. Server Hello 《====

   • TLS 版本
   • 选择的加密套件
   • 一个随机数（Server Random）

3. Certificate 《====

   • 服务器的公钥证书（被 CA 签名过）

4. Server Key Exchange 《====

   • 用以实现 ECDHE 算法（一种密钥交换算法）的其中一个参数（Server Params）

5. Server Hello Done （第 2 步 到 第 5 步都是服务端发往客户端，表明协商结束） 《====

   • 告知客户端，协商暂时告一段落

-----------目前为止，客户端和服务端之间通过明文共享了 Client Random，Server Random，Server Params-------

------------而且，客户端也拿到了服务器的公钥证书，接下来，客户端会验证证书的有效性----------------------------------

6. Client Key Exchange ====》
   • 用以实现 ECDHE 算法的另一个参数 （Client Params）

---------目前为止，客户端和服务器都拥有了ECDHE算法的2个参数： Server Params 和 Client Params ---------------

客户端和服务端都可以使用 ECDHE 算法，根据上面的两个参数计算出一个新的随机密钥串：Pre-master secret

然后结合 Server Params、Client Params、 Pre-master secret 生成用以加密会话的会话密钥

7. Change Cipher Spec ====》

   • 告知服务器：之后的通信都是用刚刚生成的会话密钥进行加密

8. Finished ====》

   • 包含连接至今全部报文的整体校验值（摘要，就是一个hash值，使用刚刚的会话密钥加密），加密之后发送给服务器
   • 这次握手协商是否成功，就要看服务器能否正确解密该报文

9. Change Cipher Spec 《====

10. Finished 《====

到此为止，客户端和服务器端都验证加密解密没问题，握手正式结束

后面开始传输加密的HTTP请求和响应

大致流程如下图所示：

总结： 利用 3 个随机数生成一个会话密钥，会话密钥用来对通信进行加密

大致流程：

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成"对话密钥"。

（3） 双方采用"对话密钥"进行加密通信。

参考资料：

1.阮一峰的博客

2.掘金博客