https加密协议全过程（结合全站文章，最简单直观的小白文）

HTTPS协议

HTTP天生"明文"的特点，整个传输过程中完全透明，任何人都能够在链路中截取、修改或者伪造请求/响应报文，数据不具有可信性，因此就诞生了HTTPS协议。使用HTTPS协议时所有HTTP请求和响应在发送到网络之前，都需要进行加密。

HTTPS协议等于HTTP协议加上SSL/TLS协议

SSL/TLS协议

SSL(Secure Socket Layer，安全套接字层)：1994年为Netscape所研发，SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS(Transport Layer Security，传输层安全)：其前身是SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从3.1开始被IETF标准化并改名，发展至今已经有TLS 1.0、TLS 1.1、TLS 1.2三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

摘要算法

摘要算法能够把任意长度的数据"压缩"成固定长度、而且独一无二的"摘要"字符串，就好像是给这段数据生成了一个数字"指纹"。任意微小的数据差异，都可以生成完全不同的摘要。所以可以通过把明文信息的摘要和明文一起加密进行传输，数据传输到对方之后再进行解密，重新对数据进行摘要，再比对就能发现数据有没有被篡改。这样就保证了数据的完整性

加密算法

对称加密

编、解码使用相同密钥的算法

客户端提前发送约定好的密钥给服务器，但是为了让服务器知道密钥内容，就必须明文传输，此时如果被黑客劫持，之后发送的密文都可以被黑客劫持的密钥破解

因此我们就需要非对称密钥

非对称加密

非对称加密就是生成一个公钥和一个密钥，通过他们得到对称密钥，因此来进行后面的密文传输

公钥

可以明文传输约定，公钥只能对密文进行加密，但是无法破解密文，因此无论谁拿到公钥都无法破解密文

密钥

密钥由分服务器自己保存，不被其他人知道，客户端使用公钥来对对称密钥进行加密，传输给服务器，服务器通过私钥进行解密，获得对称密钥。此时客户端就可以使用这个对称密钥进行后续的传输工作。

但是由于非对称加密比较慢，对称加密比较快。因此一般使用非对称加密来进行对称密钥的加密传输。而用对称加密来进行后续的传输工作。

但是同样也会有风险

中间人攻击

如果黑客自己也生成一套公钥和密钥来欺骗客户端和服务器

伪装成客户端：获取服务器的公钥A，黑客获取到客户端发送的对称密钥，通过服务器提供的公钥A加密给服务器发送内容，服务器接受后得到对称密钥，之后的发送密文内容就会以这个对称密钥来进行加密。

伪装成服务器：发送自己生成公钥B给客户端，客户端就会以公钥B加密发送对称密钥给黑客，因为与公钥B配套的密钥B也是由黑客自己生成的，所以就可以破解客户端发送的对称密钥

这样，黑客就能得到客户端和服务器之间通信的对称密钥，并且服务器从而破解接下来的传输内容。

证书

服务器（网站）在成立的时候，需要去一些专门的认证机构（第三方机构）申请证书。服务器需要提供一些资质。当申请通过之后，机构就会给你颁发证书。其中，证书中也就包含了公钥。

服务器会把自己的公钥注册到CA(第三方证书机构)，然后CA拿自己的私钥对服务器的公钥进行处理并颁发数字证书。

通过这个方法来防止有人伪装成服务器给客户端发送消息

此时客户端申请公钥的时候，此时就不应该只是请求要一个公钥了，而是请求要一个证书。

当客户端拿到证书之后，就可以进行校验。验证证书是不是假的或者被篡改的。如果客户端发现证书是无效的，浏览器就会直接弹框警告

hash2:浏览器利用数字证书的原始信息计算出信息摘要

hash1:用CA的公钥解密数字证书的数字签名，解密的数据就是信息摘要

怎么获取CA的公钥

部署https服务器的时候，除了要部署当前域名的数字证书，还需要部署CA机构的数字证书，CA机构的数字证书包含了CA公钥以及机构的一些信息。

在建立https连接时，服务器会将当前域名的数字证书、给当前域名签名的CA机构的数字证书一同发送给浏览器，因此浏览器就获取到CA公钥。

客户端（浏览器）拿到证书时，就会对证书的内容验证：

• 判定证书的有效期是否过期；
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构）；
• 验证证书是否被篡改：

系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要/签名), 设为 hash2； 然后计算整个证书的 hash 值, 设为 hash1

虽然公钥是可以获取的，但因为黑客无法获取证书的密钥（保存在CA机构中），因此无法伪装成服务器且无法对签名篡改后重新加密（防止中间人攻击，黑客就无法伪装成服务器，浏览器不会信任黑客提供的假密钥，因此黑客拿到证书信息和公钥，也无法破解后续浏览器发送的密文的内容）

浏览器对比 hash1 和 hash2 是否相等，如果相等, 则说明证书是没有被篡改过的

本地数字证书是浏览器保存的一种缓存，用于加速对已知证书的验证。当用户再次访问同一网站时，浏览器可以通过本地存储的证书快速验证其有效性，而无需重新从CA获取证书。

知道上面的加密相关的细节之后，我们来数理一遍HTTPS连接的全过程

HTTPS连接全过程

1、首先呢，客户端先向服务端发送加密通信(https)请求，这次请求中包括：

• SSL/TSL版本号
• 加密套件，也就是客户端支持的加密算法列表
• 产生一个随机数，我们叫他为第1随机数
• 有一个Client Hello字符串

2、服务器收到请求后，向客户端发出响应：

• 确认SSL/TSL版本号，如果客户端不支持，那么就关闭通信
• 确认的加密算法列表
• 生成一个随机数，我们叫第2随机数

3、服务器再向客户端发送数字证书。（上文中有写数字证书的验证）服务器会把自己的公钥注册到CA(第三方证书机构)，然后CA拿自己的私钥对服务器的公钥进行处理并颁发数字证书。

4、服务器将公钥发送给客户端

5、服务器发送Hello Done，表示发送完毕

6、客户端收到服务端一系列响应后，确认数字证书和公钥，没有问题后向服务端发送：

• 生成一个随机数，我们叫第3随机数或者预主密钥，此预主密钥会通过公钥进行加密
• 客户端握手结束通知，表示客户端的握手结束

7、服务端收到客户端数据后，使用私钥对加密后的预主密钥进行解密，没有其他人知道预主密钥，因为它加密了，除非服务器私钥泄漏。然后服务端通过第一、二、预主密钥计算出会话密钥。客户端也计算出了会话密钥。

8、服务端向客户端发送：

• 加密通信算法改变通知，以后通过会话密钥通信
• 服务端握手结束

到此为止，SSL/TSL握手结束，在此之后都会通过会话密钥来进行加密和解密，也就是对称加密。

本文结合了csdn上的相关文章汇总出来的HTTPS传输教程，部分图片直接搬运上来了，希望对读者有帮助！

（仅做技术交流分享）