【Linux网络篇】：从HTTP到HTTPS协议---加密原理升级与安全机制的全面解析

✨感谢您阅读本篇文章，文章内容是个人学习笔记的整理，如果哪里有误的话还请您指正噢✨
✨ 个人主页：余辉zmh–CSDN博客
✨ 文章所属专栏：Linux篇–CSDN博客

HTTPS协议原理

HTTPS也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层。

因为HTTP协议内容都是按照文本的方式明文传输的，这就导致在传输过程中可能出现一些被篡改的情况。

一.预备知识

1.什么是“加密”

加密就是把明文（要传输的信息）进行一系列变换，生成密文。

解密就是把密文再进行一系列变换，还原成明文。

在加密和解密的过程中，往往需要一个或者多个中间的数据辅助完成这个过程，这样的数据就成为密钥。

2.为什么要“加密”

因为HTTP的内容是明文传输的，明文数据会经过路由器，wifi热点，通信服务运营商，代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就会完全暴露。劫持者还可以篡改传输的信息并且不会被双方发现，这就是中间人攻击（后面详细讲），所以我们需要对信息进行加密。

在互联网上，明文传输是非常危险的事情！！！

HTTPS就是在HTTP的基础上进行了加密，进一步的来保证用户的信息安全。

加密是为了保证基本的安全需求：

• 保密性：
  • 防止敏感信息被未授权的人获取
  • 保活用户隐私数据
  • 确保商业机密安全
• 完整性：
  • 确保数据在传输过程中不被篡改
  • 防止信息被恶意修改
• 真实性：
  • 确保通信双方的身份
  • 防止身份冒充

3.常见的加密方式

对称加密

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，相当于加密和解密使用的密钥是相同的，这种加密方法就是对称加密，也成为单密钥加密。
• 常见对称加密算法（了解）：DES，3DES，AES，TDEA，Blowfish，RC2等。
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼

一个简单的对称加密，按位异或

假设明文a=1234，密钥key=8888

则加密a^key得到的密文b为9834

然后针对密文9834再次进行运算b^key，得到的就是原来的明文1234

（对于字符串的对称加密也是同理，每一个字符都可以表示成一个数字）

当然，按位异或只是最简单的对称加密，HTTPS中并不是按位异或

非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥，一个是公开密钥（简称公钥）；一个是私有密钥（简称私钥）。
• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA。
• 特点：算法强度复杂，安全性依赖于算法与密钥但是由于其算法复杂，使得加密和解密速度没有对称加密解密速度快。
• 通过公钥对明文加密变成密文，通过私钥对密文解密变成明文。
• 通过私钥对明文加密变成密文，通过公钥对密文解密变成明文。
• 用公钥加密只能用私钥解密；用密钥加密只能用公钥解密。

非对称加密的数学原理比较复杂，涉及到一些数论相关的知识，这里举一个简单的生活上的例子

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

B说：我桌子上有个盒子，然后我给你一把锁，你把文件放在盒子里用锁锁上，然后我回头拿着钥匙来开锁取文件。

在这个场景中，这把锁就相当于公钥，要是就是私钥，公钥给谁都想（不怕泄露），但是私钥只有B自己持有，持有私钥的人才能解密。

4.数据摘要/数据指纹

• 数据摘要/数据指纹（都一样），其基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的，非常低概率发生冲突的，具有唯一性的字符串。
• 摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）。
• 摘要特征：严格来说不算是一种加密机制，因为没有解密，主要是用来进行数据对比，从而判断数据有没有被篡改。

5.数字签名

数据摘要/数据指纹经过加密后就是数字签名。

（先了解即可，后面会具体讲解）

二.HTTPS的工作过程探究

1.四种加密方案

既然要保证数据安全，就需要进行“加密”。

网络传输中不在直接传输明文，而是加密后的“密文”

加密的方式有很多，但是整体上可以分为两大类：对称加密和非对称加密。

方案1-只使用对称加密

通信双发都各自持有同一个密钥X，并且没有其他人知道，这样双方的通信就是安全的了（除非密钥X被破解）。

即使通信过程中密文被截获，由于中间设备不知道密钥是啥，因此也就无法进行解密，也就无法获取到密文内容了。

但是啊，这里就有一个弊端了，服务器同一时刻并不是只给一个客户端提供服务的，而是存在非常多的客户端。而每个客户端用到的密钥必须是不同的（如果是相同的，那密钥就会很容易扩散，中间设备也就可能获取到）。因此服务器需要维护每个客户端和每个密钥之间的关联（明确哪个客户端使用的是哪个密钥），而这样做的话就会变得非常麻烦。

那如果直接在客户端和服务器建立连接的时候，双方就协商这次的密钥是啥，这样不就不用维护两者之间的关联了吗？

但是事实上，这种只是理想情况下的，如果协商时直接使用明文传输密钥，那么中间设备就能直接在协商时就获取到密钥，那后续客户端和服务器再继续使用密钥通信不就成摆设了吗？

所以密钥的传输也必须加密传输！

但是这里又有问题了，如果想对密钥进行对称加密，就需要先有一个“密钥的密钥”，这不就成了“先有鸡还是先有蛋的问题吗”，所以密钥的传输再用对称加密就行不通了。

方案2-只使用非对称加密

对于非对称加密的机制，假如服务器同时含有两个密钥：一个公钥，一个私钥。

服务器先把公钥使用明文传输的方式发送给客户端，客户端收到公钥后开始进行通信，客户端把要传输的数据通过公钥加密成密文，然后把加密后的密文发送给服务器，服务器收到密文后，就可以使用私钥进行解密从而获取到数据。即使密文中途被中间设备截获，因为用公钥加密的密文只能用私钥解密，而中间设备并没有获取到私钥，所以也就无法进行解密。因此从客户端到服务器的传输就是安全的了。

但是服务器到客户端的传输如何保障安全呢？

因为刚开始是服务器是直接以明文的方式将公钥发送个客户端的，所以中间设备在这个过程中也是可以获取到公钥的。如果服务器使用公钥加密，那形成的密文客户端就无法解密了，因为客户端没有私钥，所以只能使用私钥加密。但是如果使用私钥加密形成密文发送给客户端，中间设备就可以在中途使用获取到的公钥进行解密了。因此从服务器到客户端的传输并不安全。

方案3-双方都使用非对称加密

1. 服务器拥有公钥S和私钥S’，客户端拥有公钥C和私钥C’

2. 客户端和服务器相互交换各自的公钥

3. 客户端给服务器发送数据：先用公钥S’对数据进行加密，再发送密文，密文只能由拥有私钥S’的服务器进行解密获取到

4. 服务器给客户端发送数据：先用公钥C’对数据进行加密，再发送密文，密文只能由拥有私钥C’的客户端进行解密获取到

这样的话是不是感觉貌似可以啊，但是同样也存在问题：

• 效率太低（因为非对称加密本来就相对于对称加密速度缓慢，而且这里还是使用了两个非对称加密）
• 安全问题—中间人攻击（后面会讲）

方案4-非对称加密+对称加密

1. 服务器具有非对称公钥S和私钥S’
2. 客户端先发起HTTP请求，获取服务器的公钥S
3. 客户端在本地生成对称密钥C，通过公钥S加密后发送给服务器
4. 由于中间设备没有私钥，即使中途截获了密文，也无法进行解密获取到对称密钥C（存疑？）
5. 服务器通过私钥S’解密，获取到对称密钥C
6. 这样客户端和服务器都具有对称密钥C了，后续通信时都使用这个对称密钥C进行加密，因为中间设备不知道对称密钥C是啥，即使中途截取到密文也无法解密。

注意点：非对称加密只是在刚开始时负责保证对称密钥的安全传输，后续通信都是采用对称加密的方式，所以效率上还算可以。

虽然上面的这种方案已经比较接近答案了，但是依然存在安全问题，并且这个安全问题还是方案2，3，4的通病：如果一开始中间人就已经开始攻击了呢？

2.中间人攻击（针对上面四种方案）

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

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

3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端

4. 中间人在此期间截获数据报文，获取到公钥S保存好，然后将数据报文中的公钥S替换成自己的公钥M，并将伪造好的数据报文重新发送给客户端

5. 客户端收到报文后，提取公钥M（此时客户端并不知道服务器的公钥S已经被替换成中间人的公钥M），然后形成对称密钥C，用公钥M加密后发送给服务器

6. 中间人继续截获数据报文，直接用自己的私钥M’进行解密，得到对称密钥C，再用曾经保存的服务器的公钥S加密后，将报文重新发送给服务器

7. 服务器拿到报文后，用自己的私钥S’解密，得到对称密钥C

8. 后续服务器和客户端双方开始使用对称密钥C进行通信；但是因为中间人已经获取到了对称密钥C，所以后续通信的数据报文都可以截获，然后解密成功

上面的攻击方案，同样适用于方案2和方案3；

上面这种中间人攻击情况，出问题的本质主要还是：客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的以及这个公钥是否是合法的！

为了保证公钥的合法性，就需要用到证书了！

3.CA证书

服务端在使用HTTPS之前，需要先向CA机构申领一份数字证书，数字证书里含有证书申请者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

这个证书可以理解成是一个结构化的字符串，里面包含了一些信息。

需要注意的是：服务端申请证书时，需要先在特定平台生成CSR文件（请求文件），同时还会为服务端生成一对密钥：公钥S和私钥S’。这对密钥就是用来在网络通信中进行明文加密以及数字签名的。

公钥和CSR文件会一起发送给CA机构进行权威认证，私钥服务器自己保留，用来后续进行通信（其实还是用来交换对称密钥）。

4.理解数字签名

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

1. CA机构拥有非对称加密的公钥A和私钥A’
2. CA机构对服务端申请的证书明文数据使用HASH算法，形成数据摘要
3. 然后对数据摘要使用私钥A’进行加密，得到数字签名
4. 服务端申请的证书明文和数据签名S共同组成了数据证书，这样一份数字证书就可以颁发给服务端了

5.方案5-非对称加密+对称加密+证书认证

1. 服务器具有一份证书，以及私钥S’
2. 客户端和服务器刚一建立连接的时候，服务器就会给客户端发送一份证书，证书包含了之前服务器的公钥S，也包含了该网站的身份信息。
3. 客户端收到证书后会进行认证（防止证书是伪造的）
   • 判定证书的有效期是否过期
   • 判定证书的发布机构是否受信任（操作系统中已经内置了受信任的证书发布机构）
   • 验证证书是否被篡改：客户端的系统中一般会内置很多权威CA机构的公钥A，只需要用这些机构的公钥A一一尝试对证书的数字签名进行解密，就能得被加密的hash值（称为数字摘要），设数字摘要为hash1；然后再重新计算整个证书的hash值，设置hash2，对比hash1和hash2是否相等。如果相等，就说明证书没有被篡改过！
4. 如果客户端验证证书是合法的，就可以生成对称密钥C，然后使用证书中包含的公钥S进行加密，然后将数据报文发送给服务器
5. 服务器收到数据报文后，使用私钥S’进行解密得到对称密钥C
6. 后续客户端和服务器双方就是用对称密钥C进行通信

为什么这种方案就是安全的呢？

接下来就对可能的几种攻击场景进行分析，看看这种方案是否是安全可靠的。

1.证书伪造：

• 中间人在一开始的时候就截取到服务器发送的证书，注意证书由两部分组成，一部分是数字签名，另一部分就是明文数据（包含服务器的公钥S和服务器域名等信息）
• 如果中间人使用权威机构的公钥A对数据签名进行解密（因为权威机构的公钥都是公开的，所以中间人也能获取到），一旦解密后，中间人就无法再从新进行加密，因为只有拥有私钥A’的权威CA机构能进行加密，不能加密，也就不能再发送给客户端，从而暴露自己的身份
• 如果中间人不解密，而是直接修改明文数据的公钥S，一旦更改明文数据，客户端验证时生成的hash值就无法和数据签名中的hash值对比上，如果两个hash值对比不上，客户端就会识别到该证书不合法

2.证书劫持：

• 中间人如果想替换整个证书，就需要先向CA机构申请证书，然后用自己的证书进行替换
• 但是申请证书时，需要提交对应的域名以及服务器认证信息，如果整个替换，客户端依然能够识别出来
• 因为中间人没有CA私钥，所以对于任何证书都无法进行合法修改，包括自己的

3.密钥窃取：

• 中间人无法获取对称密钥，因为密钥传输使用了非对称加密
• 即使获取了加密后的对称密钥，没有服务器的私钥也无法进行解密

4.数据窃听：

• 即使中间人截获了加密后的数据报文，没有对称密钥也无法解密
• 对称密钥只在客户端和服务器之间安全传输

这种组合方案的安全性主要依赖于：

1. 证书体系的信任机制
2. 非对称加密的数学难题
3. 对称加密的密钥安全传输
4. 完整的协议实现和配置

通过这种多层次的安全机制，HTTPS能够有效防止中间人攻击，保证通信安全。

以上就是关于应用层HTTPS加密协议的讲解，如果哪里有错的话，可以在评论区指正，也欢迎大家一起讨论学习，如果对你的学习有帮助的话，点点赞关注支持一下吧！！！