Linux网络HTTPS协议原理

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

加解密

加密就是把明文 (要传输的信息)进行一系列变换，生成密文 。 解密就是把密文再进行一系列变换， 还原成明文。 在这个加密和解密的过程中, 往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为密钥。

常见的加密方式

对称加密

对称加密使用相同的密钥进行加密和解密。加密速度快，适合大量数据加密，但密钥管理复杂，需要安全渠道共享密钥。

常见的对称加密算法：

• AES（高级加密标准）：广泛使用，支持128、192、256位密钥。
• DES（数据加密标准）：较旧，密钥长度56位，安全性不足，已被AES取代。
• 3DES：DES的增强版，应用三重加密提高安全性。

非对称加密

非对称加密使用公钥和私钥配对。公钥可公开分发，私钥必须保密。安全性高但速度慢，适合密钥交换和数字签名。（比如通过公钥加密，私钥解密）

常见的非对称加密算法：

• RSA：基于大整数分解难题，广泛用于数字签名和密钥交换。
• ECC（椭圆曲线加密）：相同安全强度下密钥更短，适合资源受限环境。
• Diffie-Hellman：用于密钥交换，不直接加密数据。

哈希函数

哈希函数将任意长度数据映射为固定长度哈希值。不可逆，常用于验证数据完整性或密码存储。

常见的哈希算法：

• SHA-256：SHA-2家族成员，输出256位哈希值，广泛用于区块链。
• MD5：输出128位哈希值，已不推荐用于安全场景。
• bcrypt：专为密码哈希设计，内置盐值并支持慢哈希，抵抗暴力破解。

混合加密

混合加密结合对称和非对称加密的优势。先用非对称加密交换对称密钥，再用对称密钥加密数据。TLS/SSL协议即采用此方式。

密码学应用场景

• TLS/SSL：保障网络通信安全，使用RSA/ECC交换密钥，AES加密数据。
• PGP/GPG：加密文件或邮件，结合对称和非对称加密。
• 区块链：SHA-256确保数据不可篡改，ECC用于数字签名

数据摘要 && 数据指纹

数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash 函数)对信息进行运算, 生成一串固定⻓度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。

摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成 有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不 过从摘要很难反推原信息，通常用来进行数据对比

HTTPS的工作过程探究

方案一：只使用对称加密

通信双方使用同一个秘钥，但是接收方需要得知秘钥，而秘钥传输又需要加密，因此接收方根本得不到秘钥原文，因此不可行，而且就算双方都知道了，也容易被黑客攻击从而泄露。

方案二：只使用非对称加密

服务器持有公钥S和私钥P，将S发送给客户端进行通信：

很显然，从右往左不安全，只能保证单向安全，不仅如此，运算速度比较慢。

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

假设双方各持有一堆公钥和私钥：

安全问题任然存在，只是没有上边那么严重，但是运算速度还是慢。

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

这样就保证了速度，也有方案三的安全保障。

中间人攻击

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

但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，假设 hacker 已经成功成为中间人：

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

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

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

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

5. 客户端收到报文，提取公钥 M(自己当然不知道公钥被更换过了)，自己形成对称秘钥 C，用公钥 M 加密 C，形成报文发送给服务器

6. 中间人劫持后，直接用自己的私钥 M'进行解密，得到通信秘钥 C，再用曾经保存 的服务端公钥 S 加密后，将报文推送给服务器

7. 服务器拿到报文，用自己的私钥 S'解密，得到通信秘钥 C

8. 双方开始采用 C 进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

中间人得到了秘钥C可以随意篡改传输的数据，这样方案四有问题，那么方案三也有问题。

实际上主要矛盾是客户端能否区分自己收到的公钥是否合法。

CA证书与签名

数据签名

签名：

验证：

私钥只有本人持有，因此只能本人有对数据签名的能力，只能用公钥解密。

CA证书

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

服务器返回时不仅有公钥，还有附带公钥和签名的证书。所有的浏览器都要内置可信的CA机构或者子机构的公钥。CA机构就有签名的权利，所有浏览器只认CA机构的签名。

第五种方案：非对称加密+对称加密+证书认证

如果中间人改了公钥，那么散列值不一样则无法通过客户端的识别，而中间人有没有CA机构的私钥，因此无法重新签名。所以中间人改不了证书，就算中间人申请一份真的证书发过去，域名之类信息又对不上，还是无法通过客户端的识别。

总共设计三组秘钥：

第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件 与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同 时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。

第⼆组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥 (是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解 密获取到对称加密密钥.

第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

补充

在线生成CSR和秘钥：https://myssl.com/csr_create.html

形成 CSR 之后，后续就是向 CA 进行申请认证，不过一般认证过程很繁琐，网络各种提供证书申请的服务商，一般真的需要，直接找平台解决就行。

在浏览器设置里面搜就能看到：

如何成为中间人：

• ARP 欺骗：在局域网中，hacker 经过收到 ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC)地址。例， 黑客收到两个主机 A, B 的地址，告诉 B (受害者) ，自己是 A，使得 B 在发送给 A 的数据包都被黑客截取

• ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个 ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致⽬标所有的上网流量都会发送到我们指定的接⼝上，达到和 ARP 欺骗同样的效果

• 假 wifi && 假网站等