【Linux网络】HTTPS如何保证数据安全？从对称加密、非对称加密到 CA 证书认证

目录

• [1 ~> 为什么要有 HTTPS ？](#1 ~> 为什么要有 HTTPS ？)
• [2 ~> 概念准备](#2 ~> 概念准备)
• • [2.1 加密与解密](#2.1 加密与解密)
  • [2.2 常见的加密方式](#2.2 常见的加密方式)
  • [2.2 数据摘要（数据指纹）](#2.2 数据摘要（数据指纹）)
• [3 ~> HTTPS 工作过程探究](#3 ~> HTTPS 工作过程探究)
• • [3.1 对称加密](#3.1 对称加密)
  • [3.2 非对称加密](#3.2 非对称加密)
  • [3.3 非对称加密 + 非对称加密](#3.3 非对称加密 + 非对称加密)
  • [3.4 非对称加密 + 对称加密](#3.4 非对称加密 + 对称加密)
  • • [3.4.1 中间人攻击 MITM](#3.4.1 中间人攻击 MITM)
    • [3.4.2 数据签名](#3.4.2 数据签名)
    • [3.4.3 CA 认证](#3.4.3 CA 认证)
    • • [**CA 机构**](#CA 机构)
      • [CA 证书](#CA 证书)
  • [3.5 非对称加密 + 对称加密 + 证书认证](#3.5 非对称加密 + 对称加密 + 证书认证)
• [4 ~> 总结](#4 ~> 总结)

---

1 ~> 为什么要有 HTTPS ？

HTTPS （HyperText Transfer Protocol Secure，超文本传输安全协议）是一种基于HTTP 协议 + TLS/SSL 加密协议 的安全通信协议，主要用于在客户端（浏览器）和服务器之间建立加密 、可靠 、身份可信的数据传输通道。

简单来讲：

HTTPS = HTTP + TLS / SSL

即 HTTPS 在 HTTP 的基础上又添加了一层协议，HTTP 负责数据传输规则，TLS 负责数据加密和身份认证。

HTTPS 主要由两部分组成：

（1）HTTP协议

负责：

• 请求网页资源
• 发送数据
• 接收服务器响应

例如：

客户端：

GET /hello.html HTTP/1.1

服务器：

HTTP/1.1 200 OK

Hello World

（2）TLS协议

TLS（Transport Layer Security，传输层安全协议）负责：

• 加密数据
• 验证服务器身份
• 防止数据被修改

TLS位于：

应用层
   |
 HTTP
   |
 TLS
   |
 TCP
   |
 IP

HTTPS通信过程：

HTTP数据
   ↓
TLS加密
   ↓
TCP发送
   ↓
网络传输

为什么要使用HTTPS，就是因为光有HTTP 数据传输不安全。HTTP 只能进行明文数据传输，即只要被攻击者抓包后，就能够看到报文内容。此时，就可能会导致数据被窃听、篡改。

例如：

HTTP 请求：

GET /index.html HTTP/1.1
Host: example.com

攻击者抓包后就能够直接看到请求的内容。

HTTPS 中：

8F 3A 9C 27 A1 B5 ...

数据经过加密，即使抓包也无法直接读取。

---

2 ~> 概念准备

2.1 加密与解密

加密 就是把明文数据进行一定的处理变成密文。

解密 就是把密文经过一定的处理变成明文。

在加密和解密过程中，需要一个中间数据，辅助这个过程的进行，即密钥。

例如：我们以按位异或的方式加密解密

明文：123
密钥：111
加密：123 ^ 111 = 20；// 密文即20
解密：20 ^ 111 = 123; // 得到明文

下面通过一个运营商劫持的例子 -> 为什么要加密？

通过前面对 IP 协议的学习，我们知道，我们的主机一半都处于内网，当我们进行跨网络通信时，需要让运营商通过出入口路由器将我们的数据包转发到目标主机所在的子网。所以，运营商一定能够拿到我们的数据包。

下载一个 天天动听：

未被劫持的效果，点击下载按钮，就会弹出天天动听的下载链接。

已被劫持的效果，点击下载按钮，就会弹出 QQ 浏览器的下载链接。

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

点击 "下载按钮"，其实就是在给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应其实就包含了该APP 的下载链接。

运营商劫持之后，就发现这个请求是要下载天天动听，那么就自动的把交给用户的响应给篡改成 "QQ浏览器" 的下载地址了。

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

2.2 常见的加密方式

（1）对称加密

对称加密 即加密和解密使用同一把密钥。

• 常见算法：AES、ChaCha20、DES / 3DES。

• 特点：速度快，适合大数据量传输。

按位异或就是一个简单的对称加密。

（2）非对称加密

非对称加密 即加密解密需要两把密钥参与，这两个密钥是公开密钥 （public key，简称公钥）和私有密钥（private key，简称私钥）。

• 常见非对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

公钥和私钥是配对的，如果用公钥加密，就需要用私钥解密；如果用公钥解密，就需要用私钥加密。

2.2 数据摘要（数据指纹）

数据摘要 即利用单向哈希函数将任意长度发的数据计算出一串固定长度的特征字符串。

核心特性：

• 唯一性：即使原始数据改动一个字符，计算出的数据指纹也会发生非常大的变化。
• 单向不可逆性：只能从原始数据计算出摘要，不能通过摘要反推出原始数据。
• 抗碰撞性：不同的数据产生的数据摘要相同的概率极低，可以忽略不计。

所以，通过数据指纹就可以判断原始数据是否被篡改过。

---

3 ~> HTTPS 工作过程探究

我们对所有的加密方式的组合进行讨论，确定出 HTTPS 最终选择的安全通信方式。

3.1 对称加密

如果，客户端和服务端事先都持有同一个密钥，此时，运营商或者中间人因为不知道密钥，即使拿到数据包也不知道真正的内容，那么双方通信就是安全的。

但根本的漏洞在于：密钥分发和密钥管理

• 密钥分发：通信双方首先需要协商密钥，比如服务端需要将密钥通知给客户端。

  • 明文传输：中间人抓包就能够获取密钥，后续加密通信形同虚设。
  • 加密传输：要加密密钥本身，又需要另一把密钥，陷入无限递归。

• 密钥管理：

  • 如果所有用户与服务器都使用同一把对称密钥，只要有一个用户的设备泄露，全网安全即刻崩溃。

  • 如果服务器为每个用户单独分配不同的对称密钥，面对千万级用户，服务器需要维护巨大的密钥库，且初次分发问题依旧无法解决。

3.2 非对称加密

服务端有一把公钥和一把私钥，先通过明文传输将公钥交给客户端。

此时，客户端通过公钥加密，将密文发送给服务端，由于只有服务端持有私钥，所以只有服务端才能解密，中间人即使拿到了公钥也没有关系。

客户端向服务端发送消息安全，但服务端向客户端发送消息不是安全的，因为运营商/中间人拿到了公钥，可以对服务端私钥加密的密文进行解密。

即此时具有单向数据传输的安全保证！

3.3 非对称加密 + 非对称加密

服务端拥有公钥S与对应的私钥S'，客户端拥有公钥C与对应的私钥C'。

（1）客户和服务端交换公钥

（2）客户端给服务端发信息：先用S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S'

（3）服务端给客户端发信息：先用C对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥C'

这样貌似也行啊。但是，效率太低！！！

3.4 非对称加密 + 对称加密

服务端持有 公钥S 和私钥S'了。

（1）服务端先将公钥发送给客户端。

（2）客户端生成对称密钥，通过公钥S 加密，然后发送给服务端，此时，只要服务端有私钥，中间人即使抓包也没关系。

（3）服务端用私钥解密拿到对称密钥。

（4）对称密钥只有通信双方知道，就可以正常加密通信了。

这种方式已经接近正确答案了，但仍然存在安全问题：中间人攻击！

3.4.1 中间人攻击 MITM

中间人也持有非对称密钥，公钥 = A，私钥 = A'。

（1）中间人劫持到服务端发送给客户端的含有公钥 S 的报文后，自己也保存公钥 S。

（2）将报文中的公钥 S 修改为自己的公钥 A，然后发送给客户端。

（3）客户端拿到公钥A，并不知道报文被篡改，依旧拿着公钥A 对对称密钥C 进行加密，然后发送给服务端。

（4）中间人再次劫持报文，先用自己的私钥A' 进行解密，拿到对称密钥C ，然后再用服务端公钥S 进行加密，并将新的报文发送给服务端。

（5）服务端拿到报文，并不知道被篡改，拿着私钥S' 进行解密拿到对称密钥C，然后双方开始加密通信。

此时，由于中间人已经拿到了对称密钥，数据就泄漏了。

而对于方案2和方案3，已存在这样的安全问题。

问题本质出在哪里了呢？客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的！

3.4.2 数据签名

数据签名是利用非对称加密和数据摘要技术生成的电子凭证，相当于数据在网络世界中的"手写签名"和"防伪印章"。

通过哈希散列函数对原始数据形成数据摘要，然后签名者用自身持有的私钥对数据摘要进行加密，形成的密文就是数据签名。

（1）什么是签名者？

任何持有私钥的独立主体都可以作为签名者。签名的本质是利用私钥对数据摘要进行加密，因此"签名者"的身份取决于私钥由谁持有并管理。

常见主体：

• 证书颁发结构（CA机构）
• 服务端与网络节点
• 软件开发者与发布商
• 个人用户与终端

（2）签名的过程：

• 生成数据摘要
• 私钥加密
• 将原始数据与签名进行组装

（3）验证的过程：

• 接收方收到带有签名的数据后，先将原始数据与签名分开；
• 利用相同的哈希散列函数生成数据摘要；
• 接收方用签名者公钥对签名进行解密，得到一个数据摘要；
• 将两个数据摘要进行对比，相同证明数据没有被篡改；反之。

中间人攻击主要利用了客户端和服务端并不知道报文是否被修改，而数据签名就能够解决这个问题。

因为，如果中间人拦截了带有签名的数据，即使他有签名者的公钥，能够对签名进行解密，同时修改原始数据，并用相同的哈希散列函数生成数据摘要。但中间人不知道签名者私钥，就不能将修改后的数据的数据摘要加密形成数据签名。

一旦中间人修改了原始数据，接收方收到后通过对两个数据摘要进行对比，就能够判断出数据被篡改过了。

3.4.3 CA 认证

CA 机构

CA 结构是负责签发和管理数字证书的可信机构。

它主要做三件事：

• 验证申请者的身份
• 签发数字证书'
• 管理证书（更新，吊销等）

当一个网站想要使用HTTPS，必须先向 CA 结构申请 SSL/ TLS 证书。CA 机构验证网站的域名等信息后，为网站签发证书。

网站
  │
  │ 申请证书
  ↓
CA机构
  │
  │ 验证网站身份
  ↓
签发数字证书
  │
  ↓
网站使用证书建立 HTTPS

CA 证书

网站想要使用HTTPS 就要申请证书，CA 证书的作用就是将服务器的公钥与其真实域名/身份绑定在一块，防止公钥在传输中被中间人替换。

网站申请证书时，将域名，公钥等信息提交给CA 机构，审核后签发证书，证书就是签名 + 原始数据。

先对网站提供的数据生成数据摘要，然后用CA 机构自己的私钥对数据摘要进行加密形成签名，最后将签名与原始数据拼接，即CA 证书。

那么网站 / 浏览器怎么知道CA 机构的公钥呢？

CA 公钥公开嵌入在各大操作系统和浏览器的"受信任根证书库"中，供客户端在验证证书时解密签名。

---

3.5 非对称加密 + 对称加密 + 证书认证

HTTPS 通信最终的全过程为：

（1） 双方建立TCP 连接。

（2）服务器发送CA 证书给客户端，由于中间人不能对CA 证书进行修改（只要修改就会被客户端发现），客户端收到证书，拿着内置的CA 机构的公钥对签名进行解密，并重新生成的数据摘要与解密到的数据摘要做对比，相同说明对方是可信任的。

（3）客户端生成对称密钥，并用拿到的服务端的公钥加密，将密文发送给服务端。

（4）服务端用自己的私钥解密，拿到对称密钥。

（5）双方开始对称加密通信。

4 ~> 总结

（1）在真正HTTPS 通信的过程中有三组密钥。

第一组（非对称加密）：属于 CA 机构，私钥CA 机构自己持有，公钥内嵌在操作系统或浏览器。私钥用于在签发证书时形成签名（对 CA 证书申请者的数据的摘要进行加密），公钥用于客户端检查证书内容是否被篡改。

第二组（非对称加密）：公钥与私钥都属于服务端，公钥作为 CA 证书的明文数据部分发送给客户端，用于对客户端生成的对称密钥进行加密；私钥服务端唯一持有，用于解密得到对称密钥。

第三组（对称加密）：通信双方用于对称加密通信过程中对数据进行加密解密。

（2）中间人能不能自己申请一个CA 证书，然后对服务端发送给客户端的证书进行整体替换？

有了 CA 证书，中间人不能修改数据了，那么如果中间人也申请一个证书，替换服务端证书，是不是就能骗过客户端。

答案是不能，因为证书中还有域名的字段，客户端检查到中间人证书的域名与服务端不相同时，也会报错。