跳到主要内容HTTPS 加密原理、数字指纹与 CA 认证详解 | 极客日志Shell / Bash算法
HTTPS 加密原理、数字指纹与 CA 认证详解
HTTPS 协议通过在应用层和传输层之间增加 SSL/TLS 加密层保障数据安全。文章对比了 HTTP 与 HTTPS 的区别，阐述了对称加密与非对称加密的原理及优缺点。针对密钥交换中的中间人攻击问题，提出了非对称加密结合对称加密的方案，并引入 CA 认证机制验证公钥合法性。最终详解了 HTTPS 完整工作流程，包括证书验证、密钥协商及数据传输加密过程，确保通信安全。
一。预备知识
1. 什么是 HTTPS？
HTTP 协议无论是使用 GET 还是 POST 方法传输数据，都是以明文形式进行传输，这意味着传输过程中的数据很容易被拦截或篡改。
HTTPS 协议则通过在应用层和传输层之间增加一个加密层（SSL/TLS），为数据传输提供安全保障。
- 当用户通过 HTTPS 访问网站时，数据首先被加密层处理，进行加密后再交给传输层。
- 接收方在接收到数据后，同样通过加密层解密，解密后的数据再交给应用层使用。
- 在整个传输过程中，只有在用户层数据是明文的，而网络中的传输数据始终处于加密状态。
HTTPS 也是一个应用层协议。只是在 HTTP 协议的基础上引入了一个加密层。
- 攻破成本>攻破后的收益，就可以认为是相对安全的
- 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，并将伪造报文发给客户端
问题本质出在哪里了呢？
服务器返回公钥的时候，被中间人窃取并替换了&&客户端没有辨别公钥是否合法的能力
下面要围绕**客户端能够具有辨别服务器发过来的公钥的合法性！**来解决问题，避免公钥被替换
为了防止这种攻击，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 私钥，无法对任何证书进行合法修改。
- 证书包含的信息以及数字签名机制确保了即使中间人尝试篡改或替换证书，客户端也能检测出异常并采取安全措施，如中断连接以防止潜在的信息泄露。
常见问题：
为什么摘要内容在网络传输的时候一定要加密形成签名？
- 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 和假网站：**攻击者设置虚假的无线网络接入点或模仿合法网站的界面，诱使用户连接并泄露敏感信息。
2. HTTPS 的完整工作流程
- 第一组密钥（非对称加密）：用于验证证书的合法性。客户端通过 CA 的公钥验证服务器证书是否被篡改。
- 第二组密钥（非对称加密）：用于加密传输对称密钥。客户端使用服务器的公钥加密对称密钥，服务器通过私钥解密。
- 第三组密钥（对称加密）：用于后续数据传输的加密解密操作。
这个流程确保了客户端与服务器之间的通信安全，避免数据在传输过程中被窃取或篡改。
其实一切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的。
- 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。
- （CA 认证中进行）第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥。
微信扫一扫，关注极客日志
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
相关免费在线工具
- 加密/解密文本
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
- Base64 字符串编码/解码
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
- Base64 文件转换器
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
- Markdown转HTML
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
- HTML转Markdown
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
- JSON 压缩
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
