tls

TLS 1.3 引入了 0-RTT（Zero Round Trip Time，零往返时间）模式，旨在减少连接延迟，提升用户体验。本文深入解析 0-RTT 的工作原理、安全风险以及如何正确配置。 什么是 0-RTT？ 0-RTT 是 TLS 1.3 引入的新特性，允许客户端在首次握手时就开始发送加密数据，无需等待服务器完成握手。相比传统的 1-RTT 或 2-RTT 模式，这可以显著减少建立连接所需的时间。 各版本 TLS 的往返次数 TLS 版本 模式 往返次数（RTT） TLS 1.2 RSA 完整握手 2-RTT TLS 1.2 ECDHE 完整握手 1-RTT TLS 1.3 完整握手 1-RTT TLS 1.3 0-RTT 0-RTT 工作原理 首次连接（建立会话） 1 2 3 4 客户端 ───── ClientHello ────> 服务器 客户端 <─── ServerHello ───── 服务器 客户端 <─── 加密完成 ───────── 服务器 (+Session Ticket) 客户端发送 ClientHello，请求建立 TLS 1....

完美前向保密（Perfect Forward Secrecy, PFS）是现代 TLS 连接的核心安全特性。它确保即使服务器的长期私钥在未来被泄露，攻击者也无法解密过去捕获的加密通信。 本文将深入理解 PFS 的工作原理、密钥交换机制差异，以及如何在实战中验证和配置 PFS。 什么是完美前向保密 要理解 PFS，先看一个没有 PFS 的场景： 1 2 3 4 5 6 7 8 Client Server | | | --- ClientHello ------->| | <--- ServerHello --------| (包含服务器 RSA 公钥) | | | -- PreMasterSecret ---->| (用服务器 RSA 公钥加密) | | | <-- Encrypted Data ---->| (双方用派生的会话密钥加密) 在传统的 RSA 密钥交换中，客户端生成一个 PreMasterSecret，用服务器的 RSA 公钥加密后发送。服务器用自己的 RSA 私钥解密。这里的致命问题是：任何人如果记录了这段加密通信，并且在未来获得了服务器的 RSA 私钥，就能解密 PreMasterSecret，进而解密所有历史通信数据。 引入 PFS 后，情况完全不同： 1 2 3 4 5 6 7 8 9 10 Client Server | | | --- ClientHello ------->| | <--- ServerHello --------| (包含服务器临时 ECDHE 公钥) | | | -- Client ECDHE Pub --->| (客户端临时公钥) | | | (双方各自独立计算共享密钥，不通过网络传输) | | | <-- Encrypted Data ---->| (通信结束后临时密钥立即销毁) 使用 ECDHE 或 DHE 等临时密钥交换时，每次连接都会生成一对新的临时密钥。双方通过 Diffie-Hellman 计算得到一个共享密钥，这个密钥从未在网络上传输过，并且在连接结束后就被销毁。...

什么是 ALPN ALPN（Application-Layer Protocol Negotiation，应用层协议协商）是 TLS 协议的一个扩展，定义于 RFC 7301。它允许客户端和服务器在 TLS 握手阶段就协商好使用哪个应用层协议，而无需额外的往返通信。 如果没有 ALPN，客户端只能先建立 TLS 连接，再通过 NPN（Next Protocol Negotiation，已废弃）或在 TLS 握手完成后通过额外协商来确定使用 HTTP/1.1 还是 HTTP/2。ALPN 将这个过程整合到 TLS 握手中，减少了延迟。 ALPN 的工作原理 在 TLS ClientHello 消息中，客户端通过 application_layer_protocol_negotiation 扩展发送自己支持的协议列表，按优先级排序。服务器从中选择一个双方都支持的协议，并在 ServerHello 中回显该选择。 整个协商过程在 TLS 握手内部完成，对应用层透明： 1 2 3 4 5 6 7 8 9 10 11 12 Client Server | | |-------- ClientHello ---------->| | + ALPN: [h2, http/1.1] | | | |<------- ServerHello -----------| | + ALPN: h2 | | | |-------- 后续 TLS 握手 -------->| | | |<===== TLS 加密通道建立 ========>| | 使用 HTTP/2 通信 | 常见的 ALPN 协议标识符 协议标识符 说明 h2 HTTP/2 over TLS http/1....

什么是 OCSP Stapling OCSP Stapling（正式名称为 TLS Certificate Status Request）是一种 TLS 扩展机制，允许服务端在 TLS 握手过程中主动向客户端提供证书的状态信息，而无需客户端自行向 CA 的 OCSP 响应服务器发起查询。 它的核心价值在于：将证书状态验证的责任从客户端转移到服务端，同时保护用户隐私、提升连接速度。 为什么需要 OCSP Stapling 要理解 OCSP Stapling 的价值，先看没有它时证书撤销检查的三种方式。 方式一：CRL（证书吊销列表） CA 定期发布一个包含所有已吊销证书序列号的列表（CRL），客户端下载后自行检查。 1 2 # 查看 CRL 分布点（CRL Distribution Points） openssl x509 -in cert.pem -noout -text | grep -A2 "CRL Distribution" 问题很明显：CRL 文件会随着时间不断增长，下载和解析开销越来越大。即使使用增量 CRL（Delta CRL），也难以应对大规模部署。 方式二：OCSP（在线证书状态协议） 客户端直接向 CA 的 OCSP 响应服务器发送查询，获取单张证书的实时状态。 1 2 3 # 提取证书的 OCSP 响应器 URL openssl x509 -in cert.pem -noout -ocsp_uri # 示例输出: http://ocsp....

在配置 TLS/SSL 时，我们经常看到类似 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这样的密码套件名称。对于初学者来说，这串字符可能令人困惑。本文将详细解析 TLS 密码套件的命名规范，帮助你理解每个部分的含义。 什么是密码套件 密码套件（Cipher Suite）是 TLS 协议的核心组件，它定义了一整套加密算法组合，包括： 密钥交换算法 身份认证算法 加密算法 哈希算法 一个密码套件决定了 TLS 握手期间如何协商安全参数，以及如何加密传输的数据。 TLS 1.2 密码套件命名格式 TLS 1.2 采用以下命名格式： 1 TLS_密钥交换算法_认证算法_加密算法_哈希算法 以 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 为例： 组成部分 含义 TLS 协议名称 ECDHE 密钥交换算法（Elliptic Curve Diffie-Hellman Ephemeral） RSA 身份认证算法 AES_256_GCM 加密算法（AES，256位，GCM模式） SHA384 哈希算法 各组件详解 密钥交换算法（Key Exchange） ECDHE：椭圆曲线临时 Diffie-Hellman（推荐，前向安全） DHE：临时 Diffie-Hellman（传统但性能较低） RSA：基于 RSA 的密钥交换（已被废弃，不提供前向安全） ECDH：椭圆曲线 Diffie-Hellman（静态） 认证算法（Authentication） RSA：RSA 公钥证书 ECDSA：椭圆曲线数字签名算法 DSS：数字签名标准（较老） 加密算法（Cipher） AES_256_GCM：AES 加密，256位密钥，GCM 模式（推荐） CHACHA20-POLY1305：Google 开发的流密码（移动设备友好） AES_128_CCM：AES 加密，128位密钥，CCM 模式 ARIA256-GCM：韩国标准加密算法 哈希算法（MAC/Hash）...

什么是 HSTS？ HSTS（HTTP Strict Transport Security）是一种网络安全策略机制，允许网站声明浏览器必须仅通过 HTTPS 连接访问。一旦服务器发送 Strict-Transport-Security 响应头，浏览器就会记住这个指令，在指定时间内（max-age）自动将所有 HTTP 请求转换为 HTTPS。 HSTS 响应头格式 1 Strict-Transport-Security: max-age=<过期时间>; includeSubDomains; preload 参数说明 参数 说明 max-age 浏览器记住该规则的时长，单位为秒。例如 31536000 代表一年 includeSubDomains 可选指令，作用范围包含所有子域名 preload 可选指令，表示该域名申请加入 HSTS 预加载列表 实际案例 查看主流网站的 HSTS 头配置： 1 2 # 使用 curl 查看 HSTS 响应头 curl -sI https://cloudflare.com | grep -i strict-transport-security 输出示例： 1 Strict-Transport-Security: max-age=15552000; includeSubDomains 验证多个网站 1 2 3 4 5 # 检查不同网站的 HSTS 配置 for domain in cloudflare....

TLS（Transport Layer Security）协议是 HTTPS 的核心安全保障。从 TLS 1.2 到 TLS 1.3，协议经历了重大改进。本文详细对比两者的主要区别，帮助你理解为什么应该优先使用 TLS 1.3。 握手过程：从 2-RTT 到 1-RTT TLS 1.2 的完整握手需要两次往返（2-RTT）： 1 2 3 4 ClientHello + ServerHello + 证书 + 密钥交换 → ← ServerKeyExchange + 证书请求 + ServerHelloDone ClientKeyExchange + 证书验证 + Finished → ← Finished → 应用数据 TLS 1.3 将握手优化为一次往返（1-RTT）： 1 2 3 ClientHello + 密钥交换材料 → ← ServerHello + 密钥交换材料 + 证书 + Finished Finished → 应用数据 TLS 1.3 还支持 0-RTT 模式，允许在首次连接时就开始发送加密数据，但需要预先共享密钥。...

OCSP（Online Certificate Status Protocol）是用于实时检查证书是否被吊销的协议。相比 CRL，OCSP 无需下载完整吊销列表，查询效率更高。本文介绍 OCSP 原理及 OpenSSL 命令行操作。 什么是 OCSP？ 当浏览器验证 TLS 证书时，除了检查证书链和有效期，还需确认证书未被吊销。传统方式是下载 CRL（Certificate Revocation List），但列表会随时间增长。OCSP 允许客户端直接查询证书颁发机构，获取特定证书的实时状态。 OCSP 响应类型 状态 含义 good 证书有效，未被吊销 revoked 证书已被吊销 unknown 响应者不知道该证书 从证书提取 OCSP 信息 获取证书的 OCSP 响应者地址 1 openssl x509 -in certificate.crt -noout -ocsp_uri 输出示例： 1 http://ocsp.digicert.com 获取颁发者信息 OCSP 查询需要知道证书的颁发者（CA）： 1 2 3 4 5 # 获取证书颁发者 openssl x509 -in certificate.crt -noout -issuer # 获取颁发者证书 openssl x509 -in certificate.crt -noout -issuer_hash 实际 OCSP 查询示例 使用 OpenSSL 进行 OCSP 查询 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 获取目标证书和颁发者证书 openssl s_client -connect google....

Diffie-Hellman（DH）密钥交换协议是现代密码学的基石之一，它解决了在不安全信道上协商共享密钥的难题。本文将讲解 DH 的原理，并通过 OpenSSL 演示实际操作。 问题背景 假设 Alice 和 Bob 想要通过公开信道协商一个共享密钥，用于后续的加密通信。如果信道被窃听者监听，如何安全地交换密钥？ 传统方案需要一个安全的密钥传输渠道，但这往往不现实。Diffie-Hellman 协议巧妙地解决了这个问题：双方可以在公开信道上协商出共享密钥，而窃听者无法得知最终密钥。 数学原理 离散对数难题 DH 的安全性基于离散对数难题： 对于素数 p 和生成元 g，已知 g^a mod p 很容易计算，但从结果反推 a 却极其困难（当 p 足够大时）。 密钥交换流程 假设参数 p（大素数）和 g（生成元）已公开： 1 2 3 4 5 6 7 8 9 10 11 12 13 Alice Bob ---------------------------------------------- 1. 选择私钥 a（随机数） 1. 选择私钥 b（随机数） 2. 计算公钥 A = g^a mod p 2. 计算公钥 B = g^b mod p 3. 发送 A 给 Bob --------> 3....

什么是双向 TLS 认证 普通 HTTPS 连接中，客户端验证服务器证书，确保连接的是真实的服务器。双向 TLS（Mutual TLS，简称 mTLS） 在此基础上增加了服务器对客户端的验证——客户端必须提供有效的证书才能建立连接。 这种认证方式比用户名密码更安全，广泛用于： API 服务间的身份认证 零信任网络架构 企业内部系统访问控制 高安全要求的金融、医疗系统 工作原理 mTLS 握手过程： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 客户端 服务器 | | |---------- ClientHello --------------->| |<--------- ServerHello ----------------| |<--------- Certificate ----------------| (服务器证书) |<--------- CertificateRequest ---------| (请求客户端证书) |<--------- ServerHelloDone ------------| | | |---------- Certificate ---------------->| (客户端证书) |---------- ClientKeyExchange --------->| |---------- CertificateVerify --------->| (证明拥有私钥) |---------- Finished ------------------>| |<--------- Finished -------------------| | | |====== 加密通信通道 ====================| 关键区别：服务器发送 CertificateRequest，客户端响应自己的证书并用私钥签名证明身份。...