TLS1.2连接过程解析|HTTP协议篇
# TLS1.2连接过程解析
30 秒速记
- 在原文讨论的
TLS 1.2中，浏览器先完成TCP连接，再执行TLS握手，握手成功后才传输受保护的HTTP报文。 - 客户端与服务器通过
Client Hello、Server Hello协商版本和密码套件，并交换Client Random、Server Random。 - 采用
ECDHE时，服务器发送证书及带签名的临时密钥参数；客户端验证证书链和签名后，再发送自己的密钥交换参数。 - 双方利用
ECDHE独立算出相同的Pre-Master，再结合两个Hello随机数，经PRF生成Master Secret并派生不同方向的会话密钥。 - 双方发送
Change Cipher Spec和加密的Finished校验握手完整性；其后使用协商出的对称算法保护应用数据。 - 传统
RSA密钥交换由客户端直接生成Pre-Master，再用服务器公钥加密发送；它与ECDHE的关键差异在于第三个秘密值的产生和传递方式。
TLS 1.2 会在 TCP 建连后完成身份验证和密钥协商，成功后才传输受保护的 HTTP 报文。 双方通过两个 Hello 协商版本、密码套件和随机数，再结合密钥交换结果派生会话密钥。使用 ECDHE 时，双方各自计算出相同的秘密值；传统 RSA 则由客户端生成并用服务器公钥加密发送。最后通过 Change Cipher Spec 和加密的 Finished 确认握手完整性，再用对称算法保护应用数据。
面试官追问
追问 1安全评审拿着一份仅包含 Client Hello、Server Hello 的抓包，断言旁路者已经能恢复后续明文，你会接受这个结论吗？
不能仅凭这两类消息得出会话密钥已泄露的结论，当前材料也没有提供完整握手字段与推导过程。现有角度只表明双方随机数可出现在握手中，仍需结合所选密码套件、密钥交换消息和验证结果判断；缺少完整记录时不应作确定性归因。
追问 2网关团队要为 TLS 1.2 握手增加观测日志，只准备记录连接成功和失败两个状态，你会要求补充哪些阶段信息？
至少应让日志能够区分协商、证书验证、密钥交换和握手完成等阶段，并关联同一次连接，才能缩小失败位置。具体字段和消息顺序需以实际密码套件及实现为准；当前来源只有章节标题，无法据此规定固定日志格式或完整消息清单。
追问 3客户端把密码套件从 ECDHE 类方案换成另一种密钥交换方式后，开发仍沿用原先的会话密钥推导解释，你会怎样审查？
应要求重新核对该套件对应的密钥交换输入和握手消息，不能把一种流程直接套到所有 TLS 1.2 连接。来源没有给出不同套件的对照细节，因此只能确认实现与解释必须保持一致；若缺少协商结果和抓包证据，不宜断言具体哪一步必然存在。
追问 4线上连接能收到服务端证书，但客户端随后中止，值班同学认为“证书没过期，所以只能是网络抖动”，你会怎么推进排查？
不能只检查有效期，也不能仅凭收到证书就认定身份验证已经通过。应继续核对客户端报告的握手阶段、证书相关错误、协商参数及后续消息是否出现；由于来源未列出失败类型，最终原因必须依赖实际日志或抓包，避免编造确定结论。
追问 5实现方计划让客户端和服务端共用一份密钥处理双向数据，以减少密钥管理代码，架构评审能否仅凭本节标题放行？
不能仅凭标题批准这种安全敏感的简化，当前来源没有给出密钥派生与双向密钥材料的规范细节。应要求实现方提交对应协议依据、密码套件信息和互操作验证，再判断是否符合流程；证据不足时维持标准实现更稳妥，不能用代码量收益替代安全论证。
# HTTPS 建立连接
30 秒速记
- 浏览器解析
httpsURI 后识别目标域名，并按默认端口443准备连接。 - 域名先经
DNS解析得到目标IP地址，随后客户端通过三次握手建立TCP连接。 TCP建连只提供传输通道，不能直接代表HTTPS安全连接已经完成。- 浏览器还要在
TCP之上执行TLS握手；握手完成后，才开始发送受保护的HTTP请求和响应。 - 相较普通
HTTP，首次访问增加了TLS握手阶段，也因此产生额外的建连步骤。
建立 HTTPS 连接要依次完成域名解析、TCP 建连和 TLS 握手，之后才能收发受保护的 HTTP 报文。 浏览器从地址中取出域名，通常连接默认端口 443，但连上这个端口并不代表证书可信或安全握手成功。首次访问比普通 HTTP 多了身份验证与密钥协商这一步。连接复用或会话恢复时流程可能缩短；若证书链或域名校验失败，TCP 即使已连通，正常请求也不会发出。
当你在浏览器地址栏里键入“https”开头的 URI，再按下回车，会发生什么呢？
你应该知道，浏览器首先要从 URI 里提取出协议名和域名。因为协议名是“https”，所以浏览器就知道了端口号是默认的 443，它再用 DNS 解析域名，得到目标的 IP 地址，然后就可以使用三次握手与网站建立 TCP 连接了。
在 HTTP 协议里，建立连接后，浏览器会立即发送请求报文。但现在是 HTTPS 协议，它需要再用另外一个“握手”过程，在 TCP 上建立安全连接，之后才是收发 HTTP 报文。
这个“握手”过程与 TCP 有些类似，是 HTTPS 和 TLS 协议里最重要、最核心的部分，懂了它，你就可以自豪地说自己“掌握了 HTTPS
**原理拆解：**一次全新的访问按依赖关系推进：DNS 把域名转换为可连接的地址，TCP 三次握手建立可靠字节流，TLS 在该字节流上完成身份验证与密钥协商，最后 HTTP 报文才获得机密性和完整性保护。端口 443 只是默认约定，连接到该端口并不等于证书已经可信，也不等于握手已经成功。
**最小验证：**输入一个可公开访问的 HTTPS 地址，用 curl 的详细模式观察解析、连接、TLS 和 HTTP 各阶段；要验证的结论是收到响应头前已经完成安全握手。
curl --verbose --head --connect-timeout 10 https://example.com/
输出通常依次包含域名对应的地址、连接到 443、TLS 握手及证书信息、发出的 HEAD / HTTP/1.1 或协商后的 HTTP/2 请求，以及服务器响应状态。关键点是请求行出现在握手成功之后。不同版本的 curl、TLS 后端和代理环境会改变日志文字，不能依赖某一行的固定格式。
**边界与排查：**已有连接复用时，新的请求不必重复执行完整的 DNS、TCP 和 TLS 流程；会话恢复也可能缩短握手，所以抓包结果未必每次相同。若 DNS 失败，连目标地址都无法确定；若 TCP 超时，应检查网络、端口和防火墙；若证书域名不匹配或证书链不可信，TCP 仍可能已连接，但 TLS 会失败，受保护的 HTTP 请求不会正常发出。通过代理访问时，日志还可能包含代理隧道建立过程，应把它与目标站点的 TLS 握手区分开。
面试官追问
追问 1前端监控显示 TCP 三次握手已经成功，但页面一直没有出现业务请求，值班同学准备回滚 JavaScript 包，你会先拦住吗？
会先拦住，因为 HTTPS 在 TCP 建连后还必须完成 TLS 握手，业务请求尚未发出不一定与页面代码有关。应区分 DNS、TCP、TLS 和 HTTP 阶段并查看握手错误；证书域名不匹配或证书链不可信时，TCP 仍可能成功。
追问 2代码评审中有人把首次访问 https://example.com/ 的流程写成“解析域名后立即发送 GET，再建立安全连接”，你会如何纠正？
首次全新访问的依赖顺序应是解析 URI、通过 DNS 获得地址、建立 TCP，随后在该字节流上完成 TLS，最后才发送受保护的 HTTP 报文。把请求提前会绕过机密性和完整性保护；已有连接复用时流程可能缩短，但不能据此改写首次建连顺序。
追问 3业务把测试站配置为 https://example.com:8443，网络团队仍只检查 443 的防火墙规则，你会怎样判断责任边界？
应以 URI 显式指定的 8443 为连接目标，443 只是未写端口时的默认约定。先检查目标端口的监听、网络和防火墙，再观察其上的 TLS 握手；端口能够连接也不代表证书可信或安全连接已经成功。
追问 4同一页面连续请求十个接口，抓包却没有为每个请求重复出现完整的 DNS、TCP 和 TLS 流程，测试人员认为抓包缺失，你怎么解释？
不能据此认定抓包不完整，因为已有连接可能被复用，会话恢复也可能缩短后续握手。应先确认这些请求是否共享连接及协议协商结果，再判断缺失阶段；只有全新连接才适合按完整依赖链逐段验证。
追问 5通过企业代理执行 curl --verbose --head https://example.com/ 时，日志先出现隧道建立，随后才显示目标站点握手，排障人员把前一阶段当成证书协商失败，你会怎么拆分？
应把代理连接或隧道建立与目标站点的 TLS 握手分开分析，二者虽然连续出现在日志中，却对应不同链路阶段。重点确认目标握手完成后才出现 HEAD 请求和响应头；日志文字受 curl 版本、TLS 后端与代理环境影响，不能依赖固定行序机械判断。
# TLS 协议的组成
30 秒速记
- 记录协议
Record Protocol定义TLS数据的承载单位，其他子协议的消息都通过记录发送。 - 握手协议
Handshake Protocol负责协商版本、随机数和密码套件，并交换证书与密钥参数，最终形成会话密钥。 - 警报协议
Alert Protocol传递版本不兼容、证书异常等状态，接收方可据此继续处理或终止连接。 - 变更密码规范协议
Change Cipher Spec Protocol用于通知对端切换到已协商的加密保护；按原文的TLS 1.2流程，其前后的保护状态不同。 TLS记录与TCP包不是一一对应关系：多个记录可以合并在一个TCP包中，记录协议自身也不要求逐条返回ACK。
TLS 主要由记录、握手、警报和变更密码规范这几类子协议配合完成安全通信。 记录协议负责统一封装数据，握手协议协商版本、密码套件和密钥材料，并借助证书验证身份。警报协议传递错误或关闭状态；在经典 TLS 1.2 流程中，Change Cipher Spec 通知对端切换到新协商的保护参数。TLS 记录和 TCP 包没有一一对应关系，多个记录可以合并发送，一个记录也可能跨越多个 TCP 段。
