[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fdpfmOdqRFyItqbQEMuJ2pHS314vWnmprwxVHbjhsUdw":3},{"item":4,"related":44},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":36,"sourceUrl":36,"status":37,"seoTitle":36,"seoDescription":36,"canonicalUrl":36,"isFeatured":38,"sno":39,"sortOrder":40,"publishedAt":41,"updatedAt":42,"createdAt":43},"858bf91b-e11c-4ead-96e1-4fc3eb99ab5d","article","HTTPS 握手：浏览器和服务器刚连上时到底在聊什么","tls-13-handshake-explained","TLS 1.3 握手用证书确认身份，用密钥协商建立共享秘密，再用 Finished 消息确认双方看到的是同一条会话。本文按消息顺序拆解 1-RTT 握手、前向保密、0-RTT 重放风险，以及 HTTPS 的保护边界。","浏览器地址栏出现 HTTPS 后，页面并不是立刻开始传输业务数据。客户端和服务器要先完成一场 TLS 握手：确认服务器身份、协商密码套件、建立共享密钥，并证明双方都拥有正确的握手状态。TLS 1.3 规范把这套流程、密钥派生和消息保护写得非常明确。[RFC 8446](https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc8446\u002F)\n\n很多人会把 HTTPS 简化成“用公钥加密网页”。更准确的说法是：公钥密码主要用于身份认证和建立密钥，真正的大量业务数据通常使用对称加密，因为对称加密更适合高吞吐的数据传输。\n\n## TLS 握手要解决三个问题\n\n### 1. 我连到的是谁\n\n服务器发送证书链。证书把域名、公钥和证书颁发机构的签名联系起来。浏览器根据信任根、域名匹配、有效期、用途和撤销策略检查证书。如果证书验证失败，浏览器会阻止或强烈警告，而不是把任意公钥都当成服务器身份。\n\n### 2. 双方用什么算法\n\n客户端在 `ClientHello` 中带上支持的版本、密码套件、随机数和密钥交换信息。服务器在 `ServerHello` 中选择参数。TLS 1.3 的密码套件主要描述对称加密和哈希组合，密钥交换与认证算法被拆开协商，让协议结构更清晰。\n\n### 3. 如何得到同一把会话密钥\n\n现代 TLS 通常使用基于椭圆曲线的临时 Diffie–Hellman 密钥交换。双方交换公开参数，各自用私密参数计算出相同的共享秘密，但旁观者无法仅凭公开信息得到它。随后，TLS 的密钥派生函数把握手上下文、共享秘密和随机值变成不同用途的握手密钥与应用数据密钥。\n\n## TLS 1.3 的消息顺序\n\n可以把一次完整握手理解为：\n\n1. 客户端发送 `ClientHello`，提出能力并带上临时公钥。\n2. 服务器返回 `ServerHello`，选择参数并带上自己的临时公钥。\n3. 双方据此派生握手密钥，后续很多握手消息开始被加密。\n4. 服务器发送证书、`CertificateVerify` 和 `Finished`，证明自己拥有证书对应的私钥，并确认握手摘要。\n5. 客户端验证服务器后发送自己的 `Finished`。\n6. 双方切换到应用数据密钥，开始传输 HTTP 内容。\n\n```mermaid\nsequenceDiagram\n    participant C as 客户端\n    participant S as 服务器\n    C->>S: ClientHello + 临时公钥\n    S-->>C: ServerHello + 临时公钥\n    Note over C,S: 双方派生握手密钥\n    S-->>C: Certificate + CertificateVerify\n    S-->>C: Finished\n    C->>S: Finished\n    Note over C,S: 双方切换到应用数据密钥\n    C->>S: 加密的 HTTP 请求\n    S-->>C: 加密的 HTTP 响应\n```\n\n## “Finished” 为什么重要\n\n如果只有证书和密钥交换，攻击者仍可能篡改握手参数，让双方对“到底协商了什么”产生不同理解。`Finished` 消息包含对前面握手消息的认证结果，双方验证它，就能确认握手 transcript 没有被悄悄改写。\n\n这也是 TLS 的一个关键思想：不仅要加密后续数据，还要认证建立加密通道的整个过程。认证失败时，不能继续使用一条看似加密、实际参数被篡改的连接。\n\n## 为什么 TLS 1.3 更快\n\n完整 TLS 1.3 握手通常可以在一次往返中完成，减少了旧版本里的一些协商步骤。连接复用和会话恢复还能进一步降低后续访问的握手成本。\n\n但“0-RTT 更快”需要谨慎。TLS 1.3 的 0-RTT 允许恢复会话的客户端更早发送数据，可是这类早期数据可能被攻击者重放。适合 0-RTT 的应是幂等、可安全重复的请求；支付、下单和修改状态的操作不能因为追求少一次往返就直接放开。\n\n## TLS 保护了什么，没保护什么\n\nTLS 主要保护客户端与终止 TLS 的服务器之间的数据机密性、完整性和服务器身份。它不自动保证：\n\n- 服务器内部不会泄露数据。\n- 业务接口没有越权和重放漏洞。\n- DNS 一定把你带到正确的 IP。\n- 页面里的第三方脚本不会读取敏感信息。\n- 用户连接的域名本身一定值得信任。\n\n如果前面还有 CDN、反向代理或服务网格，TLS 可能在多个位置终止。每个终止点都是一个需要保护、审计和控制访问的信任边界。\n\n## 一句话带走\n\nHTTPS 的“锁”不是一次简单的公钥加密，而是一套先认证身份、再协商共享秘密、最后切换高效对称加密的协议流程。真正值得记住的是：证书回答“你是谁”，密钥交换回答“我们如何共享秘密”，`Finished` 回答“刚才的协商有没有被改过”。\n\n## 延伸阅读\n\n- [RFC 8446：TLS 1.3](https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc8446\u002F)\n- [TLS 1.3 完整握手图](https:\u002F\u002Fcommons.wikimedia.org\u002Fwiki\u002FFile:Full_TLS_1.3_Handshake.svg)","\u002Fuploads\u002F2026-08-09\u002F16956b29-034c-4cbc-a6ca-80d04f65774d.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":28,"name":29,"slug":30},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse","资料来源",null,"published",false,65,0,"2026-08-09T00:00:00.000Z","2026-08-09T12:48:30.097Z","2026-08-09T12:13:31.177Z",[45,54,63],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":52,"createdAt":53},"62724dbd-ce49-4be9-afa9-4ba127513a62","语音搜索一定先变成文字吗？AI 开始绕过转写这一步","speech-to-retrieval-without-transcription","传统语音搜索先把声音转成文字，再拿文字查资料，一次听错就可能让搜索方向完全跑偏。Speech-to-Retrieval 尝试直接把语音与相关文档映射到同一个语义空间。本文用蒙克名画的例子讲清新旧架构及其边界。","\u002Fuploads\u002F2026-09-08\u002Fe1173842-1ec4-48f3-8349-240fc2d78197.jpg",50,"2026-08-30T00:00:00.000Z","2026-08-14T03:06:11.525Z",{"id":55,"type":6,"title":56,"slug":57,"summary":58,"coverUrl":59,"authorName":14,"sno":60,"publishedAt":61,"createdAt":62},"0999bb14-a97c-4003-84e7-61ad2da998e0","文件删除以后去了哪里？为什么有时还能恢复？","where-deleted-files-go-data-recovery","普通删除往往只是移除文件系统里的索引并把空间标记为可重用，数据本身未必立即消失；SSD 的 TRIM、磨损均衡与加密又让情况更加复杂。本文区分回收站、删除、覆盖和安全清除，说明何时应停止写入设备。","\u002Fuploads\u002F2026-09-08\u002Fb7222764-de75-4863-8679-0a94a8965af3.jpg",51,"2026-08-20T00:00:00.000Z","2026-08-14T03:06:15.710Z",{"id":64,"type":6,"title":65,"slug":66,"summary":67,"coverUrl":68,"authorName":14,"sno":69,"publishedAt":70,"createdAt":71},"55f42805-a25a-4ce3-89d9-121b9a268a8f","0.1＋0.2 为什么不等于 0.3？计算机真的算错了吗？","why-point-one-plus-point-two-not-point-three","许多十进制小数无法用有限位二进制精确表示，计算机只能保存最接近的值。微小误差在显示时常被隐藏，却会在比较、累计和金额计算中冒出来。本文用三分之一的类比讲清浮点数，并给出可靠的处理原则。","\u002Fuploads\u002F2026-09-08\u002Ffd3a7daf-2a2c-4ef0-8f57-38f1d9de962c.jpg",54,"2026-09-06T00:00:00.000Z","2026-08-14T03:06:15.129Z"]