当前位置： 首页 > article >正文

SSL/TLS加密

article 2025/4/1 22:39:58

一、SSL/TLS加密是什么

SSL（Secure Sockets Layer）是一种用于在互联网上保护数据传输安全的加密协议。它通过在客户端和服务器之间建立加密连接，确保数据在传输过程中不被窃取或篡改。SSL的后续版本称为TLS（Transport Layer Security），但人们通常仍习惯性地称之为SSL。
在HTTPS（HyperText Transfer Protocol Secure）中，SSL/TLS用于加密HTTP请求和响应，从而保护用户与网站之间的通信。当你访问一个使用HTTPS的网站时，浏览器会与服务器进行SSL/TLS握手，建立加密连接，确保数据的安全传输。

1.1 SSL/TLS的工作原理：

  1. 客户端请求连接：当你在浏览器中输入一个HTTPS网址时，浏览器会向服务器发送一个连接请求。
  2. 服务器响应并发送证书：服务器会响应请求，并发送其SSL证书（包含公钥）给客户端。
  3. 客户端验证证书：浏览器会验证证书的有效性（例如，证书是否由受信任的证书颁发机构签发，证书是否过期等）。
  4. 密钥交换：如果证书有效，客户端会生成一个随机的对称密钥，并使用服务器的公钥加密后发送给服务器。
  5. 建立加密连接：服务器使用其私钥解密客户端发送的对称密钥，之后双方使用这个对称密钥进行加密通信。

1.2 前端代码示例：

虽然SSL/TLS的配置通常在服务器端完成，但前端可以通过一些方式确保与服务器的安全通信。以下是一个简单的示例，展示如何使用JavaScript检查当前页面是否使用了HTTPS：

// 检查当前页面是否使用了HTTPS
if (window.location.protocol === 'https:') {
    console.log('当前页面使用了HTTPS，通信是安全的。');
} else {
    console.warn('当前页面未使用HTTPS，通信可能不安全。');
}

1.3 总结：

SSL/TLS是确保网络通信安全的关键技术，尤其是在处理敏感信息（如登录凭证、支付信息等）时，使用HTTPS是必不可少的。作为前端开发者，虽然不需要直接配置SSL/TLS，但了解其工作原理有助于更好地理解网络安全。

二、SSL证书的组成部分

SSL证书是一种数字文件，用于验证服务器的身份并加密客户端与服务器之间的通信。它通常包含以下信息：

  1. 域名：证书是为哪个域名签发的。
  2. 颁发机构：签发证书的证书颁发机构（CA）。
  3. 有效期：证书的有效期，包括开始日期和结束日期。
  4. 公钥：用于加密数据的公钥。
  5. 签名：证书颁发机构对证书内容的数字签名，用于验证证书的真实性。

2.1 SSL证书的常见格式

SSL证书通常以以下几种格式存储：

  • PEM（Privacy Enhanced Mail）：一种基于文本的格式，通常以.pem、.crt、.cer或.key为扩展名。PEM格式的证书内容以-----BEGIN CERTIFICATE-----开头，以-----END CERTIFICATE-----结尾。
  • DER（Distinguished Encoding Rules）：一种二进制格式，通常以.der或.cer为扩展名。
  • PFX/P12（Personal Information Exchange）：一种包含私钥和证书的二进制格式，通常以.pfx或.p12为扩展名。

三、SSL/TLS连接是否复用

在用户点击页面的数据请求接口时，如果请求的是同一台服务器的资源（例如 https://example.com/api/data），通常不需要重新进行SSL/TLS握手。以下是详细解释：

3.1. 连接复用机制

  • 浏览器与服务器之间建立的SSL/TLS连接通常会被复用，尤其是在短时间内（例如用户点击页面上的按钮时）。
  • 这种复用机制依赖于HTTP持久连接（HTTP Keep-Alive）和TLS会话恢复（TLS Session Resumption）。
  • HTTP持久连接：允许在同一个TCP连接上发送多个HTTP请求和接收多个响应，而不需要为每个请求重新建立连接。
  • TLS会话恢复：允许浏览器和服务器在后续请求中复用之前协商的加密参数，从而避免重新进行完整的SSL/TLS握手。

3.2. TLS会话恢复的方式

  • Session ID：在首次SSL/TLS握手时，服务器会生成一个唯一的Session ID并发送给浏览器。浏览器在后续请求中可以通过发送这个Session ID来恢复之前的会话，从而避免重新握手。
  • Session Tickets：服务器可以将加密的会话信息（Session Ticket）发送给浏览器。浏览器在后续请求中发送这个Ticket，服务器解密后即可恢复会话。
  • 这两种方式都可以显著减少SSL/TLS握手的开销。

3.3. 是否需要重新握手？

  • 如果连接仍然保持打开状态：浏览器会直接复用已建立的连接，发送HTTP请求，不需要重新进行SSL/TLS握手。
  • 如果连接已关闭：浏览器需要重新建立连接，但可以通过TLS会话恢复机制（Session ID或Session Tickets）快速恢复之前的会话，不需要进行完整的SSL/TLS握手。
  • 如果会话恢复失败：浏览器和服务器会重新进行完整的SSL/TLS握手。

3.4. 实际场景

  • 用户访问 https://example.com，浏览器与服务器建立SSL/TLS连接，并加载页面资源（HTML、CSS、JS等）。
  • 用户点击页面上的按钮，触发一个AJAX请求到 https://example.com/api/data。
  • 如果连接仍然保持打开状态，浏览器会直接复用已建立的连接，发送请求。
  • 如果连接已关闭，浏览器会尝试通过TLS会话恢复机制快速恢复会话，避免完整的握手。

3.5. 如何验证连接复用？

可以通过浏览器的开发者工具（如Chrome DevTools）查看网络请求的详细信息：

  • 在Network选项卡中，检查请求的Connection ID或SSL/TLS Handshake信息。
  • 如果多个请求的Connection ID相同，说明它们复用了同一个连接。

3.6. 总结

在用户点击页面的数据请求接口时，如果请求的是同一台服务器的资源，通常不需要重新进行完整的SSL/TLS握手。浏览器会通过连接复用和TLS会话恢复机制，快速建立或恢复加密连接，从而提高性能。

四、会话恢复机制是如何快速恢复的

会话恢复机制（Session ID 或 Session Tickets）是 SSL/TLS 协议中用于快速恢复之前会话的技术，目的是避免重新进行完整的 SSL/TLS 握手，从而减少延迟和计算开销。以下是它们的详细工作原理：

4.1. Session ID 机制

  • 首次握手：
    1. 在首次 SSL/TLS 握手时，服务器会生成一个唯一的 Session ID，并将其发送给客户端（浏览器）。
    2. 服务器会将这个 Session ID 与相关的会话信息（如加密参数、对称密钥等）存储在本地缓存中。
    3. 客户端也会保存这个 Session ID。
  • 会话恢复：
    1. 当客户端再次连接到同一服务器时，它会在 ClientHello 消息中发送之前保存的 Session ID。
    2. 服务器检查收到的 Session ID，如果找到匹配的会话信息，则直接恢复之前的会话，跳过完整的握手过程。
    3. 服务器发送 ServerHello 消息，确认会话恢复，并使用之前协商的加密参数继续通信。
  • 优点：
    • 简单易实现。
  • 缺点：
    • 服务器需要维护一个会话缓存，可能会占用大量内存。
    • 如果服务器重启或缓存丢失，会话恢复会失败。

4.2. Session Tickets 机制

  • 首次握手：
    1. 在首次 SSL/TLS 握手时，服务器会生成一个 Session Ticket，其中包含加密的会话信息（如加密参数、对称密钥等）。
    2. 服务器使用一个只有自己知道的密钥对 Session Ticket 进行加密，并将其发送给客户端。
    3. 客户端保存这个 Session Ticket。
  • 会话恢复：
    1. 当客户端再次连接到同一服务器时，它会在 ClientHello 消息中发送之前保存的 Session Ticket。
    2. 服务器使用自己的密钥解密 Session Ticket，提取会话信息。
    3. 如果解密成功，服务器直接恢复之前的会话，跳过完整的握手过程。
    4. 服务器发送 ServerHello 消息，确认会话恢复，并使用之前协商的加密参数继续通信。
  • 优点：
    • 服务器不需要维护会话缓存，所有会话信息都存储在客户端。
    • 即使服务器重启，只要密钥不变，会话恢复仍然可以成功。
  • 缺点：
    • 需要额外的加密和解密操作。

4.3. 会话恢复的流程

以下是会话恢复的简化流程（以 Session Tickets 为例）：

  1. 客户端发送 ClientHello：
    • 包含 Session Ticket（或 Session ID）。
  2. 服务器验证 Session Ticket：
    • 如果验证成功，服务器直接恢复会话。
  3. 服务器发送 ServerHello：
    • 确认会话恢复，并使用之前的加密参数。
  4. 完成握手：
    • 客户端和服务器使用之前的对称密钥进行加密通信。

4.4. 会话恢复的性能优势

  • 减少延迟：
    • 完整的 SSL/TLS 握手通常需要 2 个往返时间（RTT），而会话恢复只需要 1 个 RTT。
  • 减少计算开销：
    • 完整的握手需要大量的计算（如密钥交换、证书验证等），而会话恢复避免了这些操作。

4.5. 会话恢复的适用场景

  • 短时间内的重复连接：
    • 例如用户在页面中点击按钮，触发多个 AJAX 请求。
  • 移动设备：
    • 移动网络延迟较高，会话恢复可以显著提高性能。
  • 高并发场景：
    • 减少服务器的计算负担，提高吞吐量。

4.6. 如何验证会话恢复？

可以通过以下方式验证会话恢复是否生效：

  • 使用浏览器开发者工具：
    • 在 Chrome DevTools 的 Network 选项卡中，检查请求的 SSL/TLS Handshake 信息。
    • 如果显示 “Session Resumed”，说明会话恢复成功。
  • 使用命令行工具：
    • 使用 openssl s_client 命令测试 SSL/TLS 连接，查看会话恢复的详细信息。

4.7. 总结

会话恢复机制（Session ID 或 Session Tickets）通过保存和复用之前的会话信息，避免了完整的 SSL/TLS 握手，从而显著减少了延迟和计算开销。Session ID 依赖于服务器的缓存，而 Session Tickets 将会话信息存储在客户端，两者各有优缺点，但都能有效提高 HTTPS 的性能。

五、浏览器如何处理HTTPS请求

5.1. HTTPS 持久连接与 TCP 连接的关系

  • HTTPS 是基于 HTTP 协议的加密版本，而 HTTP 协议又依赖于 TCP 协议进行数据传输。
  • HTTP 持久连接（HTTP Keep-Alive）：允许在同一个 TCP 连接上发送多个 HTTP 请求和接收多个响应，而不需要为每个请求重新建立 TCP 连接。
  • HTTPS 持久连接：在 HTTP 持久连接的基础上，增加了 SSL/TLS 加密层。因此，HTTPS 的持久连接同样依赖于底层的 TCP 连接。

5.2. TCP 连接断开的影响

  • 如果 TCP 连接断开，HTTPS 连接也会随之结束，因为 HTTPS 的加密通信依赖于 TCP 连接。
  • 以下情况会导致 TCP 连接断开：
    1. 超时：如果客户端和服务器在指定的时间内没有数据传输，TCP 连接可能会因超时而断开。
    2. 主动关闭：客户端或服务器主动关闭连接（例如，服务器发送 <font style="color:rgb(36, 41, 47);">FIN</font> 包）。
    3. 网络中断：网络故障或客户端/服务器崩溃可能导致 TCP 连接断开。
  • 一旦 TCP 连接断开，HTTPS 连接也会失效，后续请求需要重新建立 TCP 连接和 SSL/TLS 会话。

5.3. HTTPS 持久连接的生命周期

  • 建立连接：
    1. 客户端与服务器建立 TCP 连接。
    2. 客户端与服务器进行 SSL/TLS 握手，建立加密通道。
    3. 客户端和服务器通过加密通道发送和接收 HTTP 请求和响应。
  • 复用连接：
    • 在 TCP 连接保持打开的情况下，客户端可以复用该连接发送多个 HTTPS 请求。
    • 每个请求都通过同一个 SSL/TLS 会话进行加密。
  • 连接关闭：
    • 如果 TCP 连接断开（例如，由于超时或主动关闭），HTTPS 连接也会结束。
    • 后续请求需要重新建立 TCP 连接和 SSL/TLS 会话。

5.4. 如何延长 HTTPS 持久连接的生命周期？

  • 配置服务器超时时间：
    • 服务器可以配置 TCP 连接的超时时间（例如，Apache 的 <font style="color:rgb(36, 41, 47);">KeepAliveTimeout</font> 或 Nginx 的 <font style="color:rgb(36, 41, 47);">keepalive_timeout</font>）。
    • 较长的超时时间可以减少 TCP 连接的断开频率，从而提高持久连接的复用率。
  • 客户端优化：
    • 客户端（例如浏览器）会尽量复用已建立的 TCP 连接，减少重新连接的次数。
  • 使用 HTTP/2：
    • HTTP/2 协议支持多路复用（Multiplexing），允许在同一个 TCP 连接上并行发送多个请求和响应。
    • 这进一步提高了连接的复用率，减少了 TCP 连接断开的影响。

5.5. 实际场景示例

假设用户访问 <font style="color:rgb(36, 41, 47);">https://example.com</font>，然后点击页面上的按钮触发 AJAX 请求到 <font style="color:rgb(36, 41, 47);">https://example.com/api/data</font>：

  • 场景 1：TCP 连接仍然保持打开状态：
    • 浏览器复用已建立的 TCP 连接，直接发送 HTTPS 请求。
    • 无需重新建立 TCP 连接或 SSL/TLS 会话。
  • 场景 2：TCP 连接已断开：
    • 浏览器需要重新建立 TCP 连接，并进行 SSL/TLS 握手。
    • 如果之前保存了 Session ID 或 Session Ticket，浏览器可以尝试恢复 SSL/TLS 会话。
    • 需要重新建立 TCP 连接，但可能不需要完整的 SSL/TLS 握手。

5.6. 总结

  • HTTPS 持久连接依赖于底层的 TCP 连接。
  • 如果 TCP 连接断开，HTTPS 连接也会结束，后续请求需要重新建立 TCP 连接和 SSL/TLS 会话。
  • 通过优化服务器配置（如延长超时时间）和使用 HTTP/2 协议，可以提高持久连接的复用率，减少 TCP 连接断开的影响。
  • 理解这一机制有助于优化 HTTPS 性能，减少延迟和资源开销。

六、HTTPS 连接的建立过程的两个阶段（两次握手）

HTTPS 连接的建立过程分为两个阶段：TCP 握手和 SSL/TLS 握手。如果 TCP 连接断开，客户端需要重新进行 TCP 握手，然后再尝试进行 SSL/TLS 会话恢复。以下是详细解释：

6.1. HTTPS 连接的建立过程

阶段 1：TCP 握手

  • 目的：在客户端和服务器之间建立 TCP 连接。
  • 步骤：
    1. 客户端发送 SYN 包到服务器，请求建立连接。
    2. 服务器回复 SYN-ACK 包，确认连接请求。
    3. 客户端发送 ACK 包，确认连接建立。
  • 结果：TCP 连接建立成功，客户端和服务器可以开始传输数据。
  • 耗时：通常需要 1 个往返时间（RTT）。

阶段 2：SSL/TLS 握手

  • 目的：在 TCP 连接的基础上，建立加密的 SSL/TLS 通道。
  • 步骤：
    1. 客户端发送 ClientHello 消息，包含支持的 SSL/TLS 版本、加密套件等信息。
    2. 服务器回复 ServerHello 消息，选择 SSL/TLS 版本和加密套件，并发送其 SSL 证书。
    3. 客户端验证服务器证书，生成对称密钥，并使用服务器的公钥加密后发送。
    4. 服务器使用私钥解密，获取对称密钥。
    5. 双方使用对称密钥进行加密通信。
  • 结果：SSL/TLS 会话建立成功，客户端和服务器可以开始加密通信。
  • 耗时：通常需要 2 个往返时间（RTT）。

总结：

  • HTTPS 连接的建立需要先进行 TCP 握手（1 RTT），再进行 SSL/TLS 握手（2 RTT）。
  • 总耗时通常为 3 个 RTT。

6.2. TCP 连接断开后的处理

如果 TCP 连接断开，客户端需要重新建立 HTTPS 连接，具体步骤如下：

步骤 1：重新进行 TCP 握手

  • 客户端和服务器重新进行 TCP 握手（1 RTT）。
  • 目的：重新建立 TCP 连接。

步骤 2：尝试 SSL/TLS 会话恢复

  • 如果客户端之前保存了 Session ID 或 Session Ticket，它会尝试恢复之前的 SSL/TLS 会话。
  • 过程：
    1. 客户端在 ClientHello 消息中发送 Session ID 或 Session Ticket。
    2. 服务器验证 Session ID 或解密 Session Ticket。
    3. 如果验证成功，服务器直接恢复会话，跳过完整的 SSL/TLS 握手。
  • 耗时：通常需要 1 个 RTT。

步骤 3：如果会话恢复失败，进行完整的 SSL/TLS 握手

  • 如果会话恢复失败（例如 Session ID 或 Session Ticket 无效），客户端和服务器需要进行完整的 SSL/TLS 握手（2 RTT）。
  • 耗时：通常需要 2 个 RTT。

总结：

  • 如果 TCP 连接断开，客户端需要重新进行 TCP 握手（1 RTT）。
  • 如果会话恢复成功，总耗时为 2 个 RTT（TCP 握手 + 会话恢复）。
  • 如果会话恢复失败，总耗时为 3 个 RTT（TCP 握手 + 完整 SSL/TLS 握手）。

6.3. 实际场景示例

假设用户访问 <font style="color:rgb(36, 41, 47);">https://example.com</font>，然后点击页面上的按钮触发 AJAX 请求到 <font style="color:rgb(36, 41, 47);">https://example.com/api/data</font>：

  • 场景 1：TCP 连接仍然保持打开状态：
    • 浏览器复用已建立的 TCP 连接，直接发送 HTTPS 请求。
    • 无需重新进行 TCP 握手或 SSL/TLS 握手。
  • 场景 2：TCP 连接已断开，但会话恢复成功：
    • 浏览器重新进行 TCP 握手（1 RTT），然后通过 Session ID 或 Session Ticket 恢复 SSL/TLS 会话（1 RTT）。
    • 总耗时为 2 个 RTT。
  • 场景 3：TCP 连接已断开，且会话恢复失败：
    • 浏览器重新进行 TCP 握手（1 RTT），然后进行完整的 SSL/TLS 握手（2 RTT）。
    • 总耗时为 3 个 RTT。

6.4. 如何优化 HTTPS 连接建立的开销？

  • 使用 HTTP/2：
    • HTTP/2 支持多路复用（Multiplexing），允许在同一个 TCP 连接上并行发送多个请求和响应。
    • 这减少了 TCP 连接断开的影响，提高了连接的复用率。
  • 配置较长的 TCP 超时时间：
    • 服务器可以配置较长的 TCP 超时时间（例如，Apache 的 <font style="color:rgb(36, 41, 47);">KeepAliveTimeout</font> 或 Nginx 的 <font style="color:rgb(36, 41, 47);">keepalive_timeout</font>），减少 TCP 连接断开的频率。
  • 使用 Session Tickets：
    • Session Tickets 将会话信息存储在客户端，即使服务器重启，会话恢复仍然可以成功。
  • 启用 TLS 1.3：
    • TLS 1.3 优化了握手过程，减少了握手所需的 RTT 数量（通常为 1 RTT）。

6.5. 总结

  • HTTPS 连接的建立需要先进行 TCP 握手（1 RTT），再进行 SSL/TLS 握手（2 RTT）。
  • 如果 TCP 连接断开，客户端需要重新进行 TCP 握手，然后再尝试进行 SSL/TLS 会话恢复。
  • 通过优化协议（如 HTTP/2 和 TLS 1.3）和配置（如延长 TCP 超时时间），可以减少 HTTPS 连接建立的开销，提高性能。

http://www.kler.cn/a/610960.html

相关文章：

  • jsBridge在vue中使用
  • 前端数据模拟利器 Mock.js 深度解析
  • Flutter使用自签证书打包ipa
  • 【身份证证件OCR识别】批量OCR识别身份证照片复印件图片里的文字信息保存表格或改名字，基于QT和腾讯云api_ocr的实现方式
  • 破局AI落地困局 亚信科技“四位一体手术刀“切开产业智能三重枷锁
  • Android Kotlin 实用扩展函数（持续更新）
  • 分布式锁实战：Redis与Redisson的深度解析
  • python之size，count的区别
  • 加载dll插件自动提示文字信息——cad c#二次开发
  • PyTorch DDP快速上手附代码
  • 【大模型开发】将vocab解码
  • webpackVSVite热更新本质区别
  • 测试 SpatialLM 空间语义识别
  • AI之山，鸿蒙之水，画一幅未来之家
  • Python正则表达式（一）
  • 鸿蒙系统起飞！Flutter 完全适配指南CSDN2021-01-23 02:47
  • 深度解析：4G路由器CPE性能测试的五大关键指标
  • 影刀魔法指令3.0：开启自动化新篇章
  • 编写简单的小程序
  • SpringCloud入门、搭建、调试、源代码