HTTPS-CSDN博客

同样的，我们将加密的过程看做数学中计算 y = f(x) 的过程

而对于非对称加密，其使用用户公钥进行加密，私钥进行解密，即

计算密文：y = f(x)

计算明文：x = m(y)

其中 x 为明文，y 为密文，f( )表示加密算法（也可看做公钥），通过 f(x) 计算密文y；m( )表示解密算法（也可看做私钥），通过m(y)计算明文

摘要算法

摘要算法：摘要算法也称为哈希函数，是一种将任意长度的输入消息转换为固定长度的输出值（哈希值）的算法

同样的，我们将加密的过程看做数学中计算 y = f(x) 的过程，其中 x 为明文，y 为密文，f( )表示加密算法

对于摘要算法，可以通过y = f(x)计算密文，而无法通过密文计算明文

摘要算法具有以下特性：

固定长度输出：摘要算法生成的哈希值长度是固定的，不受输入消息长度的影响。

唯一性：对于不同的输入消息，摘要算法应该生成不同的哈希值。理想情况下，不同的输入应该产生唯一的哈希值，但由于输出空间有限，可能存在碰撞（多个不同的输入生成相同的哈希值）。

不可逆性：从哈希值推导原始输入消息应该是困难的，即使在已知哈希值的情况下，也应该难以确定原始输入消息。

抗碰撞性：摘要算法应该具有良好的抗碰撞性，即在计算上难以找到两个不同的输入消息产生相同的哈希值。

HTTPS的工作过程

要保证数据的安全，就需要进行加密，此时网络中就不再直接传输明文了，而是加密后的密文

引入对称加密

对称加密就是通过同一个密钥，将明文加密成密文，也能把密文解密成明文

先通过对称加密，针对 HTTP中的 header 和 body 进行加密

引入对称加密后，即使数据被截获，由于黑客不知道密钥，因此也就无法解密

但此时出现了一个问题：

由于服务器同一时刻是给很多客户端提供服务的，这么多的客户端，每个人使用的密钥都必须是不同的（若是相同的则密钥容易扩散，那么黑客也就很容易拿到密钥），因此，服务器就需要维护和每个密钥之间的关联关系

此时服务器要维护的内容就会很多，因此，更好的方法，是客户端和服务器在建立连接时，双方协商确定本次的密钥是什么

但此时若直接将密钥明文传输，那么黑客也就能获取到密钥，那之后的加密就没有意义了，若再对密钥进行对称加密，就仍需要协商一个 "密钥的密钥"，此时又会涉及到明文传输问题

此时的密钥传输使用对称加密就行不通了，就需要引入 非对称加密

引入非对称加密

非对称加密需要使用两个密钥，一个是 "公钥"，一个是 "私钥"

公钥和私钥是配对的，但其缺点是运算速度较慢，比对称加密慢得多

通过公钥对明文进行加密，变成密文

通过私钥对密文进行解密，变成明文

也可以反着用：

通过私钥对明文进行加密，变成密文

通过公钥对密文进行解密，变成明文

此时：

服务器生成一对非对称密钥（公钥为pub，私钥为 pri），客户端生成对称密钥 key

客户端向服务器发送请求，获取到公钥pub

客户端使用 pub 对 key 进行非对称加密，并传输

此时黑客截取到的密钥是 pub 加密后的结果，黑客要是想要解密，就需要知道 pri，然而 pri 私钥只有服务器自己知道，黑客拿不到

客户端获取公钥、双方协商对称密钥的过程都是在 SSL 内部完成的工作，使用 HTTPS 的时候，底层也是 TCP。客户端和服务器进行通信时，先进行 TCP 三次握手，TCP 连接打通之后，就进行 SSL 的握手（交互密钥的过程），之后才是业务数据的传输

引入非对称加密，主要是针对 对称密钥 的传输进行加密，那为什么不直接使用非对称加密对数据进行加密？

非对称加密系统的开销远远大于对称加密，因此，也就不太适合使用非对称加密针对大规模的数据进行加密

此时能够保证密钥的安全传输，但此时黑客仍然有办法获取到对称密钥 key，也就是通过 中间人攻击

中间人攻击

服务器可以创建出一对公钥和私钥，那么黑客也可以按照同样的方式（生成公钥和私钥的算法是开放的）创建出一对公钥和私钥，此时，黑客就可以冒充自己是服务器

黑客劫持客户端发送的数据报文，将自己生成的公钥（pub1）返回给客户端，同时将数据报文发送给服务器，黑客保存好服务器公钥 pub

客户端收到报文后，就会采用 pub1 对 key 进行加密，此时黑客使用自己的私钥 pri1 进行解密，就能够获取到密钥key，黑客再用服务器的公钥pub 对 key 进行加密，发送给服务器

服务器接收到报文后，使用自己的私钥 pub 进行解密。得到通信密钥key

之后，客户端和服务器使用 key 进行对称加密，进行通信，但此时一切都在黑客（中间人）的掌握中，劫持数据，进行监听或是修改

其中关键的一点就在于客户端无法验证返回的报文是由服务器发送的还是由黑客（中间人）发送的

要想解决这个问题，就需要使用数字证书

引入证书

服务器在使用 HTTPS 之前，需要向 CA机构（证书的签发机构，负责签发证书、认证证书、管理已颁发证书的机关）申请一份数字证书，数字证书中包含了证书申请者信息、公钥信息等，服务器将证书传给浏览器，浏览器就可以从证书中获取公钥了，证书就像是身份证，证明服务器公钥的权威性

CA本身有自己的证书，用来证明CA（证书颁发机构）的身份，本质是一份普通的数字证书，而浏览器中通常会内置大多数主流权威CA的证书

数字证书可以理解为一个结构化的字符串，其中包含的信息有：

证书发布机构

证书有效期

证书持有者的公钥

证书所有者

证书签名时用到的hash算法

签名

......

服务器首先生成一对公钥和私钥，在申请证书时，该证书内就会包含服务器的公钥信息

客户端拿到了服务器的证书后，对证书进行验证，在校验过程中，需要使用数字签名

那么，什么是数字签名？

数字签名

数字签名：是一种用于确保数字信息完整性和认证发送者身份的技术手段，签名的形成是基于非对称加密算法的

当服务器申请CA证书时，CA机构会对该服务器进行审核，并为该网址生成 数字签名

1. CA机构持有用于非对称加密的私钥A和公钥A'

2. CA机构对服务器申请的证书明文数据进行 hash，形成数据摘要

3. 然后对数据摘要使用 私钥A 进行加密（签名），得到数字签名s

服务端申请的 证书明文 和 数字签名s 共同构成数字证书