[Linux#60][HTTPS] 加密 | 数字指纹 | 详解HTTPS工作方案

一.预备知识

1. 什么是HTTPS？

2. HTTP与HTTPS的区别

3. 什么是加密？

4. 常见的加密方式

4.1 对称加密

4.2 非对称加密

4.3 数据摘要与数据指纹

4.4 数字签名

二. HTTPS的工作方案

1 方案一：对称加密

2 方案二：非对称加密

3 方案三：双方使用非对称加密

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

5 中间人攻击

三. 非对称+对称+CA 认证

1. CA认证与证书

原理：

常见问题：

2. HTTPS 的完整工作流程

随着互联网的发展，信息安全越来越受到重视。传统的HTTP协议由于明文传输，极易受到中间人攻击和信息篡改。为了解决这一问题，HTTPS应运而生。本文将详细探讨HTTPS协议的工作原理、HTTP与HTTPS的区别、加密技术的应用以及如何通过证书认证保障安全通信。

一.预备知识

1. 什么是HTTPS？

HTTP协议无论是使用GET还是POST方法传输数据，都是以明文形式进行传输，这意味着传输过程中的数据很容易被拦截或篡改。例如：

HTTPS协议则通过在应用层和传输层之间增加一个加密层（SSL/TLS），为数据传输提供安全保障。

HTTPS的工作原理如下：

当用户通过HTTPS访问网站时，数据首先被加密层处理，进行加密后再交给传输层。
接收方在接收到数据后，同样通过加密层解密，解密后的数据再交给应用层使用。
在整个传输过程中，只有在用户层数据是明文的，而网络中的传输数据始终处于加密状态。

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

加密方式的定义？

web 组织定义的

站在一个黑客角度

攻破成本>攻破后的收益，就可以认为是相对安全的
ssl 有权威的官方的加密解密方案

2. HTTP与HTTPS的区别

HTTP与HTTPS在工作方式和应用场景上有显著区别：

端口不同：HTTP使用80端口，而HTTPS使用443端口。
安全性：HTTP是明文传输，不安全；HTTPS则通过加密保证数据的安全性。
效率：由于HTTPS需要进行加密解密操作，因此效率略低于HTTP。在内网等安全环境下，可以考虑使用HTTP提高效率。

3. 什么是加密？

加密是将明文数据通过一定的规则转换成密文的过程，从而保证数据在传输过程中不会被非法获取或篡改。

以下是加密相关的术语：

明文：未加密的原始数据。
密文：经过加密后的数据。
加密：将明文转换为密文的过程。
解密：将密文还原为明文的过程。
密钥：用于加密和解密过程的核心数据。

4. 常见的加密方式

4.1 对称加密

对称加密使用相同的密钥来进行加密和解密。
特点：算法公开、加密速度快、计算量小。
常见的对称加密算法：DES、AES、Blowfish等。

4.2 非对称加密

非对称加密需要两个密钥：公钥和私钥。
公钥：用于加密，私钥：用于解密，或反向操作。
常见的非对称加密算法：RSA、DSA等。
虽然非对称加密的安全性更高，但由于算法复杂，效率较低。

4.3 数据摘要与数据指纹

数据摘要通过Hash函数（如MD5、SHA256）将信息运算生成一个固定长度的字符串。
摘要的作用：快速判断数据是否被篡改，但不能反推出原始信息。
和加密算法的区别是，摘要严格意义上不是加密，因为没有解密

4.4 数字签名

数字签名是对摘要进行加密后的结果，用来确保数据的完整性和身份验证。

通过非对称加密技术，使用私钥对摘要加密，接收方用公钥解密，经过比对，可以验证数据是否被篡改。

预备知识整理如下：

二. HTTPS的工作方案

既然要保证数据安全, 就需要进行 “加密”.
网络传输中不再直接传输明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密

其实在网络通信，我们要解决的是如下问题：

数据被监听
数据被篡改

1 方案一：对称加密

如果通信双方都各自持有同一个密钥X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）

服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个⼈用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, ⿊客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情~

缺点：

上面还不是最重要的，最重要的是最开始的时候我们怎么保证客户端和服务器看到的是同一个密钥。

如果最开始客户端把密钥发给服务器，那这个密钥是明文传还是密文传？
明文传那黑客不就拿到了，
暗文加密传那就需要对密钥进行加密，就仍然需要先协商确定一个 “密钥的密钥”

这不就是鸡生蛋还是蛋生鸡的问题吗？所以纯纯使用对称加密是不行的！

2 方案二：非对称加密

通信之前先得交换密钥，鉴于非对称加密的机制，用公钥和私钥都可以加密，但用公钥加密就要使用私钥解密，使用私钥加密就要使用公钥解密，所以可以尝试如下图操作：

缺点：

现在只能保证从C->S的安全性(暂时的安全)，没有办法解决S->C的安全性。
没事我们在提第三种方案。

3 方案三：双方使用非对称加密

服务端拥有公钥S与对应的私钥S’，客户端拥有公钥C与对应的私钥C’
客户和服务端互相交换公钥
客户端给服务端发信息：先用S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S’
服务端给客户端发信息：先用C对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥C’

缺点：

慢
还是有安全问题，这是和方案二安全问题是一样的，下面在提它们的安全问题

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

这种方案通过非对称加密进行密钥交换，之后的数据传输使用对称加密，从而兼顾了安全性和效率。具体流程如下：

客户端发起HTTPS请求，获取服务器的公钥。
客户端生成一个对称密钥，并使用服务器的公钥加密后发送给服务器。
服务器通过私钥解密，获得对称密钥。
随后的通信使用对称加密进行数据传输。

前半部分采用非对称加密：交换密钥，后半部分采用对称加密：双方不存在了安全问题。既安全，又高效。

但真的没有问题了吗？

方案二、方案三、方案四都存在⼀个问题，如果最开始，中间⼈就已经开始攻击了呢？

5 中间人攻击

中间人攻击是指在客户端与服务器通信的过程中，攻击者通过劫持并篡改数据进行窃听或伪造。

在方案2/3/4中，客户端获取到公钥S之后，客户端形成的对称秘钥C，然后用服务端给客户端的公钥S对C进加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥C，因为只有服务器有私钥S’。

但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，如果 M 在请求公钥后就已经成功成为了中间人

客户端向服务器发起请求，服务器明文传送公钥S给客户端
中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端

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

问题本质出在哪里了呢？
服务器返回公钥的时候，被中间人窃取并替换了&&客户端没有辨别公钥是否合法的能力

下面要围绕 客户端能够具有辨别服务器发过来的公钥的合法性！来解决问题，避免公钥被替换

为了防止这种攻击，HTTPS引入了证书认证机制。

三. 非对称+对称+CA 认证

1. CA认证与证书

为了防止中间人篡改公钥，HTTPS采用了数字证书认证机制。CA（Certificate Authority）作为权威的第三方机构，为服务器颁发数字证书，保证公钥的真实性。证书的验证流程如下：

服务器向CA机构申请证书，CA机构对服务器的公钥进行签名并颁发证书。
客户端在建立HTTPS连接时，会首先获取服务器的证书，并验证证书是否由可信的CA签发、是否过期、是否被篡改。
只有在证书验证通过后，客户端才会信任服务器，并使用其公钥进行加密通信。

证书可以理解成是⼀个结构化的字符串，里面包含了以下信息：证书发布机构、证书有效期、公钥、证书所有者、签名等等

客户端能够具有辨别服务器发过来的公钥的合法性! 我们说是通过证书来进行甄别的，那证书如何做到的呢？

原理：

签名：

对一份文本(可以认为这里是CA证书内的明文信息)经过hash散列形成散列值，我们称之为数据摘要。然后用签名者的私钥(CA机构的私钥)对数据摘要加密形成了数据签名
更重要的把这个数据签名和这个明文信息合在一起，形成数字签名的数据。

验证：

把原始文本和签名分开，一个对原始文本使用相同的散列函数进行散列形成散列值，另一个对签名用签名者的公钥解密形成散列值
然后对比两个散列值，如果这两个散列值不一样，就注定有人要么改了原始文件，要么改了签名。
只要这两个散列值一样，那么原始文本和它曾经形成的签名是一样的，说明这个原始文本没有被篡改过！

通过验证可以确保：数据和签名的证书不被更改啦

首先说一下，CA为了签发证书，CA也有自己的CA公钥，CA私钥。

因为我们使用CA的私钥形成数据签名，所以只有CA能形成可信任的证书！(CA私钥只在CA)

实际验证场景：

将证书上的明文数据和数字签名分开，把明文数据经过相同的hash映射(这个hash是公开的)形成数据摘要。因为CA会在所有的浏览器中内置自己的公钥！
所以浏览器会拿着CA公钥对CA曾经的数字签名进行解密！得到曾经原始数据的摘要。然后对比两个摘要。两者相等说明证书内部没被串改，如果两者不相等说明证书被篡改过。

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

明文篡改：

- 中间人可以尝试篡改证书的明文部分。
- 但是，由于中间人不具备证书颁发机构（CA）的私钥，因此无法生成与篡改后的证书相匹配的有效数字签名。

验证失败：

- 如果证书被篡改，客户端会使用其存储的信任链中的CA公钥来验证证书签名。
- 客户端将计算证书明文的哈希值，并用CA的公钥解密签名。
- 如果哈希值不匹配，则表明证书已被篡改，客户端会认为证书不可信并中断连接。

私钥加密：

- 中间人不能使用自己的私钥来替换或重新加密证书，因为客户端会使用特定CA的公钥来验证签名。
- 客户端将无法正确解密签名，从而检测到篡改。

⭕中间人整个掉包证书？

证书掉包：

- 即使中间人试图用自己的合法证书来完全替换原始证书，这也会导致问题。
- 证书包含了诸如域名等标识信息，这些信息必须与客户端正在访问的服务匹配。

- 如果证书中的域名与实际服务不符，客户端同样会拒绝接受该证书。

结论：

中间人缺乏必要的CA私钥，无法对任何证书进行合法修改。
证书包含的信息以及数字签名机制确保了即使中间人尝试篡改或替换证书，客户端也能检测出异常并采取安全措施，如中断连接以防止潜在的信息泄露。

查看浏览器的受信任证书发布机构

Chrome 浏览器, 点击右上角的

选择 "设置", 搜索 "证书管理" , 即可看到以下界面. (如果没有，在隐私设置和安全性-> 安全里面找找)

，然后我们就可以查看到啦

常见问题：

为什么摘要内容在网络传输的时候一定要加密形成签名？

MD5 特性：

- 定长： 不论输入字符串的长度如何，生成的 MD5 值都是固定长度（16 字节或 32 字节）。
- 分散： 输入字符串的任何微小变化都会导致输出的 MD5 值显著不同。
- 不可逆： 从原始字符串生成 MD5 值容易，但从 MD5 值反推回原始字符串在理论上是不可能的。

由于这些特性，如果两个字符串具有相同的 MD5 值，则可以认为这两个字符串是相同的。这使得 MD5 可以用来验证数据完整性。

理解证书篡改的判定过程：

假设有一个简单的字符串 "hello" 作为证书内容，其 MD5 值为 BC4B2A76B9719D91。
如果 "hello" 被篡改为 "hella"，则新的 MD5 值将完全不同，例如 BDBD6F9CF51F2FD8。
当服务器发送 "hello" 和其对应的 MD5 值给客户端时，客户端可以通过重新计算 "hello" 的 MD5 来验证是否被篡改。

存在的问题：

如果攻击者篡改了 "hello" 并且同时更新了相应的 MD5 值，那么客户端就无法检测到这种篡改。

解决方案：

对证书明文进行哈希处理后，使用 CA 的私钥对哈希值进行加密形成签名。
将明文+加密后的签名一起组成完整的 CA 证书，并发送给服务端。
客户端接收证书后，利用操作系统中预存的 CA 公钥解密签名，还原出原始哈希值，并与自己计算的哈希值对比，以此来验证证书的合法性。

为什么签名不直接加密，而是要先hash形成摘要？

减少需要加密的数据量，从而加快数字签名的生成和验证速度。

如何成为中间人？

ARP 欺骗： 在局域网内，攻击者通过监听 ARP 请求广播包获取其他节点的 IP 和 MAC 地址信息，然后向受害者发送伪造的 ARP 应答，声称自己是另一台主机，从而使受害者的流量被重定向到攻击者处。
ICMP 重定向攻击： 利用 ICMP 协议中的重定向报文类型，攻击者可以伪造一个 ICMP 重定向消息，使目标设备误以为攻击者提供了一个更优的路由路径，进而所有流量都被导向攻击者指定的位置。
假 WiFi 和假网站：攻击者设置虚假的无线网络接入点或模仿合法网站的界面，诱使用户连接并泄露敏感信息。