Linux网络的HTTPS
目录
1、HTTPS加密的相关概念
1.1 加密的概念
1.2 加密的原因
1.3 加密的常见方式
1.3.1 对称加密
1.3.2 非对称加密
1.4 数据摘要 && 数据指纹
1.5 数字签名
2、HTTPS的加密过程的探究
2.1 一个对称加密
2.2 一个非对称加密
2.3 两个非对称加密
2.4 一个非对称加密+一个对称加密
2.5 中间人攻击
2.5.1 破解两个非对称密钥
2.5.2 破解一个非对称密钥+一个对称密钥
2.6 一个证书认证+一个非对称加密+一个对称加密
2.6.1 CA证书
2.6.2 具体流程
2.7 HTTPS的握手流程
1、HTTPS加密的相关概念
1.1 加密的概念
- 明文：指未经过加密处理的原始数据。
- 密文：指明文经过加密算法处理后得到的不可直接读取的乱码数据。
- 密钥：指用于加密或解密的 “钥匙”，是一串特定的字符串或数字。
- HTTPS 也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层：
1.2 加密的原因
- 因为HTTP的内容是明文传输的，明文数据会经过路由器、WIFI热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了，这就是中间人攻击，所以我们需要对信息进行加密。
1.3 加密的常见方式
1.3.1 对称加密
- 对称加密（Symmetric Encryption）
- 核心特点：加密和解密使用同一把密钥（称为 “对称密钥”），就像用同一把钥匙锁门和开门。
- 优点：
- 加密解密速度极快，适合处理大量数据（如文件、视频）。
- 缺点：
- 密钥需要在通信双方之间提前传递，一旦密钥泄露，加密就会失效（密钥分发是难题）。
1.3.2 非对称加密
- 非对称加密（Asymmetric Encryption）
- 公钥：可以公开给任何人，用于加密数据或验证签名。
- 私钥：必须严格保密，用于解密公钥加密的数据，或生成签名。
- （规则：公钥加密的数据只能用对应的唯一私钥解密，私钥加密的数据只能用对应的公钥解密）
- 优点：
- 无需传递私钥，只需公开公钥，解决了对称加密的密钥分发问题。
- 缺点：
- 加密解密速度慢，不适合处理大量数据。
1.4 数据摘要 && 数据指纹
- 数据摘要（Data Digest）：是一个更宽泛的概念，指通过哈希算法（如 MD5、SHA-1、SHA-256）对原始数据进行计算后，得到的一段固定长度的唯一字符串。
- 它的核心作用是验证数据的完整性，即判断数据是否被篡改。只要原始数据有任何微小变化，其生成的摘要都会完全不同。
- 数据指纹（Data Fingerprint）：是数据摘要的一种实际应用场景，特指将数据摘要用于标识数据唯一性的情况。
- 以下用的是数据摘要，判断数据是否被篡改。
1.5 数字签名
- 数据摘要经过加密就是数字签名。
2、HTTPS的加密过程的探究
2.1 一个对称加密
- Client直接发送对称密钥X，中间人就知道对称密钥X了，对称密钥X就泄露了。
- 首次无法同步对称密钥X。整体不安全。
2.2 一个非对称加密
- Client把公钥X给Server，私钥X'自己留着。
- Server->Client：
- Server用公钥X加密，只有Client持有的对应唯一私钥X'能解密，所以Server->Client看起来安全。
- Client->Server：
- Client用私钥X'加密，持有对应公钥X的中间人能解密，所以不安全。
- 整体不安全。
- 注意：Client自己也应该有公钥X，不过
- 这个公钥加密，只有私钥能解密，但是只有自己有私钥，自己加密，最后自己解密？
- 这个公钥解密，那么私钥就是加密，但是只有自己有私钥，自己先加密，最后自己解密？
- 所以，非对称加密的密钥使用逻辑是 “单向配对”：一般是给别人公钥，别人来进行加密，自己私钥解密。
2.3 两个非对称加密
-
双方都有公钥和私钥。
-
把公钥给对方，对方用公钥加密，只有另一方的唯一的私钥能够解密。
-
整体看起来安全，但是慢。
2.4 一个非对称加密+一个对称加密
- Server把公钥Z给Client，Client用公钥Z把对称密钥X加密为YYY(密文数据)，发送给Server，Server用对应的唯一的私钥Z'将YYY，解密为对称密钥X。
- 此后，双方用对称密钥X，进行加密解密。
- 整体看起来安全，且效率不错。
2.5 中间人攻击
- 讨论了这么多，目前只有第三种(两个非对称加密)，第四种(一个非对称加密+一个对称加密)，整体看起来安全。其实不安全，中间人搞一套自己的公钥和私钥就能破解。
2.5.1 破解两个非对称密钥
- 对于两个非对称加密：
-
- Client发送自己的公钥X，中间人将公钥X换成自己的公钥M，将公钥M发给Server，Server用中间人的公钥M加密，发送加密的数据，中间人使用对应的唯一的私钥M'解密，知道了明文信息，再将明文信息用公钥X加密，发送给Client，Client用私钥X'解密。
- 另一方向类似。
- 这样，在双方都不知道的情况下，中间人就破解了信息。
2.5.2 破解一个非对称密钥+一个对称密钥
- 对于一个非对称加密+一个对称加密：
-
- Server发送自己的公钥Z，中间人将公钥Z换成自己的公钥M，将公钥M发给Client，Client用中间人的公钥M对对称密钥X加密，发送加密的数据AAA，中间人使用对应的唯一的私钥M'解密，知道了对称密钥X，再将对称密钥X用公钥Z加密为BBB，发送给Server，Server用私钥Z'解密为对称密钥X。
- 此后，并且是在双方都不知道的情况下，中间人知道了对称密钥，双方使用对称密钥进行加密解密就无效了。
2.6 一个证书认证+一个非对称加密+一个对称加密
- 上面的方法四(一个非对称加密+一个对称加密)，效率不错，关键是对方无法知道，传过来的公钥是否被中间人篡改，但是只要公钥给出去，就只有对应的唯一的私钥能够解密了，后续使用对称密钥加密就安全了。
2.6.1 CA证书
- 数字签名：CA机构，将这些信息形成数据摘要，再用自己的私钥对这数据摘要进行加密，形成数字签名。
- 客户端内置了全球公认的 CA 根证书（包含 CA 的公钥、数据摘要的hash算法）。
2.6.2 具体流程
- Client第一次发起请求时，Server返回一个CA证书。
- 场景1：中间人只篡改CA公钥：
中间人将CA机构的公钥篡改为自己的公钥，那么Client用CA机构的公钥将证书中的数字签名解密，将得到数据摘要和重新形成的数据摘要，相比，对不上，Client发现公钥被篡改。 - 场景2：中间人想同时篡改公钥和数字签名：
中间人将CA机构的公钥篡改为自己的公钥+将证书中的数字签名用CA机构的公钥解密，形成新的数据摘要再加密，等等？中间人没有CA机构的私钥，只能用自己的私钥机密，但是Client会只认CA机构的公钥，发现用CA机构的公钥解密，解不了。
- 场景1：中间人只篡改CA公钥：
- 当Server将自己的公钥Z 成功 发给Client后，Client用公钥Z把对称密钥X加密为AAA(密文数据)，发送给Server，Server用对应的唯一的私钥Z'将AAA，解密为对称密钥X。
- 此后，双方用对称密钥X，进行加密解密。
- 整体安全，且效率不错。
- 注意：
- 为什么数据摘要用CA机构的私钥加密为数字签名？因为，中间人没有CA机构的私钥，不能使用CA机构的密钥再加密，而Client会只认CA机构的公钥。
- 为什么要用数据摘要？因为数据摘要短，加密解密快；方便验证信息是否被修改。
- 那么中间人能不能自己也搞一套CA证书？客户端根本不会信任“服务器发过来的 CA 公钥”，它只认自己操作系统/浏览器里预装的那一批根 CA 公钥。
2.7 HTTPS的握手流程
