https://secdoc.jazor.net/tags/https/ Recent content in https on SecDoc Hugo -- gohugo.io zh-cn © 2026 黑豆子 Sun, 17 May 2026 00:09:53 +0800 https://secdoc.jazor.net/posts/nginx-gmssl-tls-configuration/ Sun, 17 May 2026 00:09:53 +0800 https://secdoc.jazor.net/posts/nginx-gmssl-tls-configuration/ 介绍国密 SSL/TLS 算法（SM2/SM3/SM4），讲解在 OpenSSL 和 Nginx 中配置国密加密的实战方法。 https://secdoc.jazor.net/posts/tls13-hello-retry-request/ Mon, 11 May 2026 00:05:42 +0800 https://secdoc.jazor.net/posts/tls13-hello-retry-request/ 在 TLS 1.3 的握手过程中，客户端首先发送 ClientHello 消息，其中包含支持的密码套件、扩展和密钥共享参数。有时候服务端发现客户端提供的参数需要调整，就会发送一个特殊的响应——Hello Retry Request（简称 HRR）。本文详解 HRR 的触发条件、工作原理和实际观察方法。 什么是 Hello Retry Request Hello Retry Request 是 TLS 1.3 引入的一种握手优化机制。当服务端收到的 ClientHello 消息中的参数不符合要求时（比如缺少必要的密钥共享、密码套件不匹配等），服务端不会直接拒绝连接，而是发送一个 HelloRetryRequest 消息，要求客户端重新发送带有正确参数的 ClientHello。 这与 TLS 1.2 的行为形成对比——TLS 1.2 中如果密码套件不兼容，服务端会直接发送 Handshake Failure 警报并终止连接。 HRR 的触发条件 HRR 主要在以下几种情况被触发： 1. Key Share 不符合要求 客户端发送的 key_share 扩展中提供的密钥共享参数不被服务端接受。常见原因包括： 使用了服务端不支持的椭圆曲线 密钥共享参数格式不正确 2. 缺少必要的 Cookie 服务端要求验证客户端身份时，会在 HRR 中包含 cookie 扩展，客户端下一次 ClientHello 必须原样返回这个 Cookie。 3. 密码套件协商 虽然现代 TLS 1.3 实现通常支持所有标准密码套件，但在某些特殊配置下，服务端可能要求客户端使用特定的套件。 HRR 工作流程 完整的 HRR 流程如下： https://secdoc.jazor.net/posts/certificate-pinning-guide/ Wed, 06 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/certificate-pinning-guide/ 证书固定（Certificate Pinning）是一种安全加固技术，通过将网站的身份与特定的证书或公钥绑定，防止攻击者使用伪造证书进行中间人攻击（MITM）。本文详细介绍证书固定的工作原理、实现方式和实战配置。 什么是证书固定 传统 HTTPS 验证依赖证书链信任机制：由浏览器内置的根证书库验证网站证书是否由可信 CA 签发。然而，如果攻击者能控制用户的根证书（如通过恶意软件或某些网络审查工具），就可以使用任意 CA 签发的伪造证书实施中间人攻击。 证书固定的核心思想是：不仅验证证书是否可信，还验证证书是否是我们预期的那一个。通过预先在客户端保存服务器的公钥指纹或证书指纹，客户端只会接受固定的那个证书，其他任何证书（包括合法 CA 签发的）都会被拒绝。 固定方式 1. 公钥指纹固定 直接固定服务器的公钥指纹，这是最推荐的方式。公钥是证书中最稳定的部分，即使证书续期，只要不更换密钥，指纹就保持不变。 1 2 3 4 5 6 # 提取证书公钥并计算 SHA-256 指纹 openssl s_client -connect example.com:443 2>/dev/null | \ openssl x509 -pubkey -noout | \ openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | \ base64 输出示例： 1 aqQ4L+Pac7Qy3Or7l6f9IypN8w1H64i48B4weiXJ2v4= 2. 证书指纹固定 直接固定整个证书的 SHA-256 指纹： 1 2 3 # 提取证书 SHA-256 指纹 openssl s_client -connect example. https://secdoc.jazor.net/posts/sni-server-name-indication-guide/ Tue, 05 May 2026 00:05:57 +0800 https://secdoc.jazor.net/posts/sni-server-name-indication-guide/ 什么是 SNI？ SNI（Server Name Indication，服务名称指示） 是 TLS 协议的一个扩展，允许客户端在 TLS 握手开始时提前声明要访问的服务器域名。这一看似简单的机制，彻底解决了 HTTPS 早期的核心痛点——单 IP 多域名 问题。 为什么需要 SNI？ 在 SNI 出现之前，TLS 握手存在一个困境： 客户端发送 ClientHello 消息时，还没有指定要访问的具体域名 服务器收到 ClientHello 后，无法确定客户端想要哪个虚拟主机 服务器只能返回一个"默认"证书，无法为每个域名提供正确证书 这意味着： 一个 IP 地址只能部署一个 HTTPS 网站 要托管多个 HTTPS 网站，必须为每个网站分配独立 IP SNI 的出现改变了这一局面。客户端在 ClientHello 中直接携带 server_name 扩展，声明目标域名，服务器据此返回对应证书。 工作原理 TLS 握手中的 SNI SNI 作为 TLS 扩展（Extension），在 ClientHello 消息中发送： 1 2 3 4 5 6 7 8 9 ClientHello ├── Version: TLS 1.2 / TLS 1. https://secdoc.jazor.net/posts/tls13-0rtt-replay-attack-protection/ Sun, 03 May 2026 00:05:56 +0800 https://secdoc.jazor.net/posts/tls13-0rtt-replay-attack-protection/ TLS 1.3 引入了 0-RTT（Zero Round Trip Time）早期数据机制，可以在一个 RTT 内完成握手，大幅降低连接延迟。然而，这一特性带来了安全隐患：0-RTT 数据可能遭受重放攻击。本文详解攻击原理与防护措施。 0-RTT 快速回顾 TLS 1.3 的 0-RTT 模式允许客户端在首次握手时立即发送加密数据，无需等待服务器完成握手。典型场景： 1 2 3 4 5 6 7 客户端 服务器 | | |-------- ClientHello (+ EarlyData) --------->| | (立即发送加密数据) | | | |<-------- ServerHello + Finished ------------| | (握手完成) | 适用场景：需要快速建立连接的 HTTP/2 预热、频繁断连的移动应用等。 重放攻击原理 攻击场景 0-RTT 数据的核心风险在于缺乏前向安全性和可能重放： 客户端首次请求（包含敏感操作，如转账） 攻击者嗅探并记录这个加密的 0-RTT 数据包 攻击者重放这个数据包到服务器 服务器误认为是有效请求，重复执行 攻击条件 重放攻击需要满足以下条件： 0-RTT 数据包被攻击者截获 服务器未对 0-RTT 数据添加足够的时间限制 某些敏感操作（如只读操作）被重复执行不会造成危害 实际影响 典型的可重放场景： 操作类型 重放风险 GET 请求（幂等） 低风险 POST 表单提交 中等风险 支付/转账 高风险 状态变更操作 高风险 攻击演示 以下演示如何在 OpenSSL 中观察 0-RTT 数据传输： https://secdoc.jazor.net/posts/tls-session-resumption-guide/ Fri, 01 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls-session-resumption-guide/ TLS 握手是 HTTPS 连接建立的开销大头。每次完整握手都需要额外的往返时延和计算资源。Session Resumption（会话恢复） 技术允许客户端和服务器复用之前的会话密钥，跳过昂贵的公钥加密步骤，大幅降低连接延迟。 为什么要会话恢复？ 指标 完整握手 会话恢复 往返次数 2-RTT 或 1-RTT 0-RTT RTT 时间 ~30-100ms ~5-10ms CPU 消耗 高（RSA/ECDHE） 极低 适用场景 首次连接 短间隔重复访问 对于需要频繁建立连接的 HTTPS 场景（如 Web 攻击面扫描、API 调用），会话恢复可以将 TLS 握手耗时降低 80% 以上。 Session Resumption 的三种方式 1. Session ID（TLS 1.2 及更早） 服务端维护会话缓存，用 Session ID 作为 key。 1 2 3 4 5 # 客户端：保存会话 echo "" | openssl s_client -connect example.com:443 -sess_out session.pem # 客户端：恢复会话 echo "" | openssl s_client -connect example. https://secdoc.jazor.net/posts/tls-record-protocol-explained/ Sun, 26 Apr 2026 00:05:46 +0800 https://secdoc.jazor.net/posts/tls-record-protocol-explained/ TLS 记录协议（Record Protocol）是 TLS 协议栈的最底层，负责对数据进行分片、压缩、计算 MAC、加密和传输。理解它的工作原理有助于深入掌握 TLS 安全机制。 记录协议的核心功能 记录协议接收上层数据后，依次经过以下处理流程： 分片：将数据切分为固定大小的记录块 压缩：对数据进行压缩（TLS 1.3 已废弃） MAC 计算：添加消息认证码 加密：对数据加密 传输：发送加密后的数据 分片机制 每个 TLS 记录包含一个 5 字节的头部和可变长度的载荷： 1 2 3 4 5 +-----------+------------+----------------+ | 类型(1) | 版本(2) | 长度(2) | <- 头部 (5 字节) +-----------+------------+----------------+ | 加密数据... | <- 载荷 +-----------+---------------------------+ 类型：Content Type，1 字节，标识记录类型 0x14 = ChangeCipherSpec 0x15 = Alert 0x16 = Handshake 0x17 = Application Data 版本：Protocol Version，2 字节（TLS 1.2 为 0x0303，TLS 1. https://secdoc.jazor.net/posts/tls13-early-data-zero-rtt/ Sat, 25 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/tls13-early-data-zero-rtt/ 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. https://secdoc.jazor.net/posts/tls-alpn-protocol-negotiation/ Wed, 22 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/tls-alpn-protocol-negotiation/ 什么是 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. https://secdoc.jazor.net/posts/ocsp-stapling-deep-dive/ Tue, 21 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/ocsp-stapling-deep-dive/ 什么是 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. https://secdoc.jazor.net/posts/hsts-http-strict-transport-security/ Sun, 19 Apr 2026 00:05:56 +0800 https://secdoc.jazor.net/posts/hsts-http-strict-transport-security/ 什么是 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. https://secdoc.jazor.net/posts/tls12-vs-tls13-differences/ Sat, 18 Apr 2026 00:05:45 +0800 https://secdoc.jazor.net/posts/tls12-vs-tls13-differences/ 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 模式，允许在首次连接时就开始发送加密数据，但需要预先共享密钥。 https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ Sat, 11 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ 什么是双向 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，客户端响应自己的证书并用私钥签名证明身份。 https://secdoc.jazor.net/posts/https-mixed-content-solution/ Sun, 05 Apr 2026 17:20:00 +0800 https://secdoc.jazor.net/posts/https-mixed-content-solution/ 当 HTTPS 页面加载 HTTP 资源时，就会产生混合内容（Mixed Content）。浏览器会阻止不安全的请求，导致页面功能异常。本文介绍混合内容的类型、排查方法和解决方案。 什么是混合内容 HTTPS 页面中通过 HTTP 加载的资源称为混合内容： 1 2 3 4 <!-- HTTPS 页面中的混合内容 --> <script src="http://example.com/script.js"></script> <img src="http://example.com/image.jpg"> <link rel="stylesheet" href="http://example.com/style.css"> 混合内容类型 混合被动内容（Mixed Passive Content） 低风险资源，浏览器通常只显示警告： <img> 图片 <audio> / <video> 媒体 <object> 子资源 混合主动内容（Mixed Active Content） 高风险资源，浏览器会直接阻止： <script> 脚本 <link> 样式表 <iframe> 内嵌页面 XMLHttpRequest / Fetch 请求 <frame> / <object> 加载的页面 排查方法 浏览器控制台 打开开发者工具（F12），查看 Console 和 Security 面板： 1 2 3 Mixed Content: The page at 'https://example. https://secdoc.jazor.net/posts/openssl-s-client-troubleshoot-https/ Sun, 05 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-s-client-troubleshoot-https/ 使用 OpenSSL s_client 命令排查 HTTPS 连接问题，包括证书验证、握手过程、TLS 协议版本检测等实用技巧。 https://secdoc.jazor.net/posts/tls-13-handshake-process/ Fri, 03 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls-13-handshake-process/ 深入解析 TLS 1.3 协议的握手流程，包括 ClientHello、ServerHello、密钥交换、证书验证等关键步骤，对比 TLS 1.2 的改进。 https://secdoc.jazor.net/posts/ssl-tls-handshake-explained/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssl-tls-handshake-explained/ 本文深入解析 SSL/TLS 握手过程，理解加密通道如何建立以及密钥交换的原理。 https://secdoc.jazor.net/posts/tls13-features-and-configuration/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls13-features-and-configuration/ 介绍 TLS 1.3 的核心改进，包括握手优化、加密套件精简、0-RTT 等特性，以及 Nginx、Apache 配置方法。 https://secdoc.jazor.net/posts/tls-1.3-cipher-suites-guide/ Sun, 29 Mar 2026 00:00:19 +0800 https://secdoc.jazor.net/posts/tls-1.3-cipher-suites-guide/ TLS 1.3 密码套件配置指南 TLS 1.3 相比之前的版本有了重大改进，其中最重要的变化之一就是大幅简化了密码套件。本文将详细介绍 TLS 1.3 的密码套件配置和使用方法。 TLS 1.3 密码套件概述 TLS 1.3 对密码套件进行了大幅简化，移除了不安全的算法，只保留以下类型的密码套件： AEAD 密码套件：所有套件都使用 AEAD（Authenticated Encryption with Associated Data）算法 前向保密：所有套件都支持完美前向保密（PFS） 移除弱算法：不再支持 RC4、MD5、SHA-1 等 TLS 1.3 支持的密码套件 1. GCM 密码套件 密码套件 密钥交换 认证 加密 密钥长度 适用场景 TLS_AES_256_GCM_SHA384 ECDHE ECDSA/RSA AES-256-GCM 256位 高安全性要求 TLS_CHACHA20_POLY1305_SHA256 ECDHE ECDSA/RSA ChaCha20-Poly1305 256位 移动设备、弱网络 TLS_AES_128_GCM_SHA256 ECDHE ECDSA/RSA AES-128-GCM 128位 标准安全性 TLS_AES_128_CCM_SHA256 ECDHE ECDSA/RSA AES-128-CCM 128位 兼容性要求 2. 查看系统支持的 TLS 1.3 密码套件 1 2 3 4 5 # 查看 OpenSSL 支持的 TLS 1. https://secdoc.jazor.net/posts/ssl-handshake-optimization/ Sat, 28 Mar 2026 00:00:49 +0800 https://secdoc.jazor.net/posts/ssl-handshake-optimization/ SSL/TLS 握手是 HTTPS 性能的关键瓶颈。本文聚焦会话恢复（Session Resumption）技术，帮助你减少握手延迟。 问题：SSL 握手的开销 完整的 TLS 握手需要多次网络往返： 1 2 3 4 5 # 测试握手时间 curl -w "Time: %{time_total}s\n" -o /dev/null -s https://example.com # 使用 openssl 测试连接时间 time openssl s_client -connect example.com:443 </dev/null 对于 TLS 1.2，完整握手需要 2 个 RTT。通过会话恢复可以降至 0-1 个 RTT。 Session ID 复用 工作原理 服务器为每个会话分配唯一 ID，客户端在后续连接时发送该 ID，服务器据此恢复会话状态。 Nginx 配置 1 2 3 4 5 6 7 8 9 10 11 12 server { listen 443 ssl; server_name example. https://secdoc.jazor.net/posts/https-redirect-best-practice/ Thu, 26 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/https-redirect-best-practice/ 将 HTTP 流量重定向到 HTTPS 是网站安全的基本要求。本文聚焦 Nginx 中的最佳实践配置。 标准配置（推荐） 使用两个 server 块分离 HTTP 和 HTTPS 流量： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # HTTP server - 重定向到 HTTPS server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; } # HTTPS server server { listen 443 ssl http2; server_name example.com www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # HSTS - 告诉浏览器始终使用 HTTPS add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; root /var/www/html; index index.