HTTPS 的 TLS 握手解决什么问题？证书和会话密钥是什么关系？

HTTPS 是在 TLS 安全通道上传输 HTTP，主要防止传输内容被窃听或篡改，并验证连接的服务端身份。客户端发起握手时提供支持的协议参数等信息，服务端选择参数、提供证书及必要的密钥协商材料；客户端需要验证证书信任链、有效期、域名等条件，不能只看到证书就认为身份可信。

证书把域名身份与公钥关联，私钥由服务端保护。在现代 TLS 1.3 等常见握手中，双方通常使用临时的椭圆曲线 Diffie-Hellman 等密钥交换方式得到共享秘密，再派生会话所需密钥，并用证书对应密钥的签名证明身份。不能一概描述为“浏览器生成随机 AES 密钥，再用证书公钥加密发给服务器”，那只是历史上某些 RSA 密钥交换方案的解释，不能套在所有 TLS 版本。

应用数据主要使用对称的认证加密，兼顾性能、保密和完整性。TLS 不会自动修复业务越权、XSS、恶意源站或终端泄漏，证书也不证明网站内容本身可信。排障要区分 DNS、TCP/QUIC、TLS 证书、协议协商和 HTTP 业务响应处在哪一步失败。

参考：RFC 8446：TLS 1.3。

抓包或 DevTools 看 HTTPS 请求慢时，先区分 DNS、连接、安全握手与 TTFB。证书域名不匹配属于身份验证失败，不能通过前端“忽略错误”修复；复用已有连接时则可能根本没有完整新握手。TLS1.3 的证书认证与临时密钥协商职责不同。

安全设计不能依赖把私钥放到前端或关闭证书校验。证书与会话密钥都不解决接口越权和恶意脚本已经进入同源后的问题。

HTTPS 是在 TLS 安全通道上传输 HTTP，主要防止传输内容被窃听或篡改，并验证连接的服务端身份。客户端发起握手时提供支持的协议参数等信息，服务端选择参数、提供证书及必要的密钥协商材料；客户端需要验证证书信任链、有效期、域名等条件，不能只看到证书就认为身份可信。