HTTPS安全原理深度解析：加密、解密与防护机制

一、HTTPS简介
HTTPS 是一种在应用层上运行的协议，它是在 HTTP 协议基础上加入了加密机制，用以确保数据传输的安全性。
与 HTTP 协议不同，HTTP 数据以明文形式传输，容易受到黑客攻击和数据篡改。而 HTTPS 通过加密技术解决了这一问题，使得数据在传输过程中不会被第三方窃取或修改。

二、加密与解密
加密： 是将明文数据（即传输的原始信息）通过一定的算法转化为密文，无法直接读取。

解密： 是将密文通过解密算法还原回明文，从而使接收方能够读取数据。

密钥： 加密和解密的过程通常需要一个或多个密钥，这些密钥在加密和解密过程中起着至关重要的作用。

对称加密： 这种方式使用相同的密钥进行加密和解密。发送方使用密钥将明文转化为密文，接收方也用相同的密钥将密文解密还原为明文。

非对称加密： 非对称加密使用一对密钥进行加密解密，其中一个是公钥（公开的）另一个是私钥（保密的）。公钥用于加密，私钥用于解密。两者通过数学算法相互关联。

三、HTTPS的⼯作过程

3.1 对称加密
对称加密简单图：

引⼊对称加密之后, 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密, 也就不知道请求的真实内容是啥了.

引入对称加密后，即使数据在传输途中被截获，只要黑客无法获得密钥，数据就无法解密，保障了信息的机密性。然而，问题在于，一台服务器通常要为多个客户端提供服务，每个客户端的密钥不能相同，以避免密钥泄漏。因此，如何有效管理这些密钥成为了一个挑战。

为了避免这个问题，客户端和服务器在建立连接时会通过协商确定一个新的密钥进行加密通信，这样就可以解决密钥管理的麻烦。

然而，这个密钥的交换过程本身也可能被黑客截获。如果密钥公开传输，黑客就能轻松获取密钥，进而解密数据。

在客⼾端和服务器建⽴连接的时候, 双⽅协商确定这次的密钥是啥，就可以避免上述问题。

但是，这将秘钥公开，黑客轻易拿到，不就相当于明文传输吗。

3.2 非对称加密
非对称加密使用：

通过公钥对明⽂加密, 变成密⽂
通过私钥对密⽂解密, 变成明⽂
也可以反着⽤

通过私钥对明⽂加密, 变成密⽂
通过公钥对密⽂解密, 变成明⽂

过程简述：

客户端首先生成一个对称加密密钥。
然后，客户端使用服务器的公钥对该对称密钥进行加密，并将加密后的密钥发送给服务器。
由于传输途中无法解密加密的密钥，即便被截获，黑客也无法获取密钥。
服务器接收到加密的对称密钥后，使用自己的私钥进行解密，还原出原始的对称密钥。
服务器使用该对称密钥加密后续的数据，并发送回客户端。
客户端再用同一个对称密钥解密服务器的响应。

从此之后，客户端与服务器之间的通信都使用对称加密进行，保证了通信的安全性。而且，由于对称密钥只在客户端和服务器之间共享，其他第三方无法访问，即使数据被截获也无法解密。

3.3 中间人攻击

中间人攻击是指攻击者通过伪装成双方通信的中间环节，截获并篡改通信内容的攻击方式。具体流程如下：
客户端请求连接服务器，服务器将公钥S发送给客户端。

中间人截获该数据，将服务器的公钥S替换为自己的公钥M，并将篡改后的数据发送给客户端。

客户端收到后，以为接收到的公钥是正确的，于是使用公钥M加密对称密钥并发送给中间人。

中间人利用自己的私钥M’解密得到对称密钥X，然后将加密后的消息发送给服务器。

服务器使用自己的私钥S’解密得到对称密钥X，开始与中间人建立对称加密的通信。

这种攻击方式使得通信数据全程被中间人控制，能够窃听、篡改甚至替换数据。

3.4 引⼊证书解决

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性

证书：

证书中包含：证书发布机构，证书有效期，公钥，证书所有者，数据签名等信息

3.4.1 数据签名
签名的形成是基于⾮对称加密算法的，

数据签名本质是一个校验和：

将证书中包含的内容，通过CA机构的算法得到一个值（就像hash函数一样），这个值是唯一的。
每个服务器在建成的时候，都会申请证书，而CA机构也会验证服务器提供的内容是不是正确的，是就会给一个证书。

3.4.2 引入证书后的工作过程：

客户端收到证书后，根据操作系统中内置的解析证书的方式，将数据签名解析，拿到服务器的公钥，ip等信息
客户端验证ip是否正确（URL中包含的ip），正确就发送请求，包含公钥加密的对称密钥，
服务器解析得到对称密钥，使用对称密钥解析得到请求报文。
服务器使用对称密钥加密响应，返回响应。客户端拿到响应，通过对称密钥解析得到请求。

这个过程中，密钥都是没有暴露出来的。

中间⼈有没有可能篡改该证书？

中间⼈篡改了证书的明⽂
由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

中间⼈会不会整个掉包证书？

因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的。