HTTPS协议原理

1.HTTPS简单介绍

HTTPS也是一个应用层协议，是在HTTP协议基础上加了一个加密层，HTTP协议内容都是按照文本的方式明文传输的，安全就会出现问题。

2.加密概念

加密就是把明文进行一系列变化生成密文，解密就是把密文进行一系列转换还原成明文。在加密和解密过程中，需要一个或者多个中间数据来辅助这个过程，这样的数据就叫密钥。

3.加密原因

早些年就有一个运营商劫持，就是下载天天动听时，下载任务地址会自动修改为腾讯的qq浏览器，下完就会发现下的不是天天动听，这就是发送过去的请求被修改了，本来应该是到天天动听的服务器申请安装包的，运营商修改了请求去到了腾讯的服务器下载qq浏览器了。

 

我们通过网络传输的任何数据包都会经过运营商的网络设备(路由器，交换机等)，运营商的网络设备就可以解析出传输的数据内容，进行篡改。

点击下载按钮就是在给服务器发送了一个HTTP请求，获取到HTTP响应就包含了该APP的下载链接，运营商劫持后，请求就会被修改，从而导致下成了qq浏览器。 

因为HTTP的内容都是明文传输的，明文数据会经过路由器，wife热点，通信服务运营商，代理服务器等多个物理结点，如果信息在传输过程中被劫持，传输内容就完全暴露了，劫持者可以篡改传输信息且不被双方察觉，这就是中间人攻击，就需要对数据加密来保证安全。(运营商劫持根本要圈米)

用http不仅运营商可以劫持，黑客也可以用类似手段进行劫持，拿到用户隐私信息，或者篡改内容。在互联网上，明文传输是危险的。

4.常见加密方式

对称加密

采用单密钥系统的加密方式，同一个密钥可以同时作用信息的加密和解密，这种方法就是对称加密，也叫单密钥加密。

特点：算法公开，计算量小，加密速度快，加密效率高。

例子

a先在客服端进行加密(^b)，到服务端进行解密(a^b^b)，这样就可以得到a^0=a，拿到解密后的数据。

 

非对称加密

需要两个密钥来进行加密和解密，这两个密钥一个是公开密钥(public key,检查公钥)一个是私有密钥(private key，检查私钥)。

特点：算法强度复杂，安全依赖性于算法与密钥，但是因为算法复杂，使得加密解密速度没有对称加密解密速度快。

通过公钥对明文进行加密，变成密文，通过密钥对密文进行解密，变成明文(也可以放着使用)。

非对称加密的数学原理比较复杂 , 涉及到一些 数论 相关的知识 . 这里举一个简单的

生活上的例子 .

A 要给 B 一些重要的文件 , 但是 B 可能不在 . 于是 A 和 B 提前做出约定 :

B 说 : 我桌子上有个盒子 , 然后我给你一把锁 , 你把文件放盒子里用锁锁上 , 然后我回

头拿着钥匙来开锁取文件 .

在这个场景中 , 这把锁就相当于公钥 , 钥匙就是私钥 . 公钥给谁都行 ( 不怕泄露 ), 但是

私钥只有 B 自己持有 . 持有私钥的人才能解密 .

数据摘要&&数据指纹

数据摘要，基本原理就是用单向散列函数对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以判断数据有没有被修改，因为文本被修改，那么出现用单向散列函数的出来的固定长度数字摘要与原来差别很大，就能判断是否被修改了。

引入了对称加密后，发送的数据被获取了，也无法知道内容是什么，如果不知道密钥是什么就无法进行解密。

但这样操作不可行，服务器是同时给很多客服端提供服务的，这么多客服端，每个人用的密钥都得是不同的(相同的密钥太容易扩散了，黑客可以获取到)，服务器要维护每个客服端和每个密钥之间的关系，是不容易的事情。

 

另一个做法

在客服端和服务器建立连接时候，双方协商确定这次密钥是什么，但是也有问题，密钥不能明文发送，就需要加密，但是密钥解密的话，也还是要把密钥的密钥发送过去，就陷入了死循环了，所以对密钥进行加密就走不通。

方案二 只使用非对称加密

服务器先把公钥以明文方式传输给浏览器，之后浏览器先服务器传输级都用公钥进行加密，这样客服端发送到服务器就是安全的，因为私钥只有服务器有。

但是也有问题，服务器发送消息到客服端就不行了，浏览器用私钥加密数据传输给浏览器，浏览器可以用公钥解密，而公钥一开始通过明文传输给浏览器的，这个公钥要是被中间人劫持到了，那么中间人也可以使用公钥解开服务器传来的消息。

方案三 双方都是用非对称加密

服务端拥有公钥S与对应私钥S'，客服端拥有公钥C和C'，客服端和服务端交换公钥 ，客服端给服务端发送消息：先用S对数据加密，在发送，只能由服务端解密，因为服务端有私钥S'

服务端给客服端发送消息：先用C对数据进行加密，在发送，只能由客服端进行解密，因为只有客服端有私钥S'。

缺点：效率太低，也还是有安全问题，中间人可以修改服务端先客服端的公钥S，这样客服端用的都是中间人的密钥，中间人就会解析出数据内容。

方案四 非对称加密+对称加密

服务端具有非对称公钥S和私钥S'

客服端发起http请求，获取服务端公钥S

客服端在本地生成对称密钥C，通过公钥S加密，发送给服务器。

由于中间的网络设备密钥私钥，截获了数据也无法使用，后面就可以用生成的对称密钥进行通信，提高效率和安全。但是也会有中间人问题，依旧无法行通。

5.中间人攻击

如果中间人在最开始的握手协商就进行了，就会有问题了。

服务器具有非对称加密算法的公钥S，私钥S'

中间人具有非对称加密算法的公钥M，私钥M‘

客服端先服务器发送请求，服务器明文传输公钥给客服端

中间人劫持数据报文，提取公钥S保存，然后将被劫持的报文中的公钥S进行替换成为自己的公钥M，并将伪造的报文发送给客服端

客服端接收到报文，提取公钥M(中间人的密钥)，自己形成密钥X，用公钥进行加密X，形成报文发送给服务器

中间人劫持后，直接用自己的私钥M'进行解密，得到通信密钥X，在用之前保存的服务端公钥S加密后，发送报文到服务端

服务器拿到报文后，用自己的私钥S’进行解密，得到通信密钥X

客服端与服务端进行通信，但所有的信息都可以被中间人获取并解析，导致了数据安全问题。

6.证书

CA证书

服务端在使用HTTPS之前，需要先CA机构申领一份数字证书，数字证书含有申请者信息，公钥信息等，服务器把证书传输给浏览器，浏览器从证书中获取公钥就可以了。

CA（Certificate Authority，证书颁发机构）是负责签发、管理和撤销数字证书的机构，它在网络安全中扮演着至关重要的角色，确保网络通信的安全性和可靠性。以下是CA证书在客户端（client）和服务端（server）之间流程的详细解释：

首先，服务端向CA提交申请认证（证书），生成一对公钥和私钥（`pub_svr` 和 `pri_svr`），并确认申请信息，包括域名、申请者信息等。服务端生成请求文件（`.csr`），该文件不包含私钥信息。

接着，CA对服务端提交的申请信息进行审核信息，确保信息的真实性和合法性。

然后，CA通过审核后，使用其私钥对服务端的公钥和其他信息进行签名，生成数字证书。证书中包含明文信息（INFO）和签名信息：签发机构（CA_qq）、有效时间（例如：2022/1/1 - 2024/1/1）、扩展信息（例如：域名：cdn.qq.com）、申请者（例如：TEG/APD）和公钥（pub_server）。

之后，CA将签发的证书发送给服务端。

当客户端与服务端通信时，客户端首先验证服务端提供的证书：计算明文信息INFO的摘要（`D_cal = Hash(INFO)`）、用CA证书的公钥解密签名（`D_pem = Dec_by_pub_CA[Sig]`）、对比两个摘要（`D_cal == D_pem`）以及验证其他信息，如域名、有效时间是否已吊销等。

一旦证书验证通过，客户端和服务器可以进行密钥协商，确保后续通信的安全性。

通过上述流程，CA证书确保了服务端身份的真实性，防止了中间人攻击等安全威胁，从而保障了客户端和服务端之间的安全通信。

 

注意：申请证书时，要在特定平台生成，会同时生成一对密钥对儿，公钥和私钥，公钥会随着CSR文件，一起发送给CA进行权威认证，私钥服务端自己保留，用来后续通信(获取客服端的对称密钥)。

数据签名

首先是签名过程，数据首先被输入，然后通过散列函数比如SHA-256处理，生成一个固定长度的散列值，例如“101100110101”。接着使用签名者的私钥对散列值进行加密，生成数字签名，例如“111101101110”，这个加密后的散列值即签名与原始数据一起被认证以确保签名的有效性，随后签名被附加到原始数据上形成数字签名的数据包。接下来是验证过程，接收方收到包含原始数据和签名的数据包后，从数据包中提取出签名，然后使用与签名时相同的散列函数对原始数据进行处理生成一个新的散列值，比如“101100110101”，再使用签名者的公钥对签名进行解密得到原始的散列值，例如解密后的散列值也是“101100110101”，之后将解密得到的散列值与新生成的散列值进行比较，如果两者一致则说明签名有效数据未被篡改，如果两个散列值一致，则此数字签名为有效，表明数据的完整性和签名者的身份得到了验证，这个过程确保了数据的完整性和签名者身份的真实性，是数字签名在网络安全中应用的基础。 

 

服务端申请CA证书时，CA机构会对该服务端进行审核，并专门为该网站形成数字签名

CA机构拥有非对称加密的私钥A和A'

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

对数据摘要用CA的私钥A‘进行加密，得到数字签名S

服务端申请的证书明文和数字签名拼接在一起共同形成了数字证书，在服务端安装这一个数字证书。

法案五 非对称加密+对称加密+证书认证

客服端和服务器建立连接时，服务器给客服端返回了一个证书，证书包含了服务端的公钥，也包含了网站信息。

客服端进行认证

客服端接收到这个证书后，会对证书进行认证，防止是伪造的

判定证书的有效期是否过期

判断证书的发布机构是否信任(操作系统中内置了受信任机构)

验证证书是否被篡改：从系统中拿到该证书的密钥，对签名进行解密，得到一个数据摘要，为hash1，然后计算整个证书的hash值，为hash2，对比hash1和hash2是否相等，相等就说没有被篡改。

 

中间人可以篡改证书吗

中间人篡改的证书的明文，由于没有CA机构的私钥，所以无法hash之后用私钥加密形成签名(因为客服端会用CA公钥进行解密，没有CA私钥解密出来的东西不确定)，如果篡改，客服端接收到证书后会发现明文和签名解密后的值不一样，就说明证书被篡改，证书不可信，终止传输信息。