ssl/tls握手的核心目标是安全协商共享密钥并验证身份，发生在tcp连接后、应用数据传输前；python ssl模块自动处理，但需理解四步流程及配置影响以排查证书、协议、套件等问题。
SSL/TLS 握手的核心目标
SSL/TLS 握手不是为了“加密数据”，而是为了在通信双方之间安全地协商出一组共享密钥，并确认对方身份。整个过程发生在 TCP 连接建立之后、应用层协议（如 HTTP）传输数据之前。Python 中的 ssl 模块（底层基于 OpenSSL）会自动完成大部分握手逻辑，但理解其步骤有助于排查连接失败、证书错误或兼容性问题。
典型四步握手流程（TLS 1.2 及以上）
以客户端主动发起 HTTPS 请求为例，实际交互包含以下关键环节：
-
ClientHello：客户端发送支持的 TLS 版本、加密套件列表（如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）、随机数（client_random），以及可选的 SNI（Server Name Indication）扩展（用于虚拟主机场景） - ServerHello + Certificate + ServerKeyExchange + ServerHelloDone：服务端选择一个加密套件，返回自己的随机数（server_random），发送证书链（含公钥），若使用 ECDHE 等临时密钥交换算法，还会附带签名后的临时公钥参数
- ClientKeyExchange + ChangeCipherSpec + Finished：客户端验证证书有效性（包括链式信任、域名匹配、有效期等），生成预主密钥（premaster secret），用服务端公钥加密后发送；随后双方基于 client_random、server_random 和 premaster secret 计算出相同的会话密钥（master secret → key block）；最后发送加密的 Finished 消息，验证密钥是否一致
- ChangeCipherSpec + Finished：服务端同样切换为加密通信，并发送自己的 Finished 消息。双方确认无误后，握手完成，开始传输加密的应用数据
Python 中影响握手的关键配置
使用 ssl.create_default_context() 或手动构建 SSLContext 时，以下设置会直接改变握手行为：
-
证书验证开关：
context.check_hostname = True启用主机名检查（默认开启）；context.verify_mode = ssl.CERT_REQUIRED强制验证服务端证书（生产环境必须）；设为CERT_NONE会跳过全部验证（仅测试用，不安全） -
自定义 CA 证书：通过
context.load_verify_locations(cafile="ca-bundle.pem")指定信任的根证书文件，适用于私有 PKI 或内网服务 -
协议版本限制：调用
context.minimum_version = ssl.TLSVersion.TLSv1_2可禁用老旧不安全版本（如 SSLv3、TLS 1.0） -
加密套件筛选：用
context.set_ciphers("ECDHE+AESGCM:!ECDSA")显式指定优先使用的算法组合，避免协商到弱套件
常见握手失败原因与调试方法
当 ssl.SSLError 抛出时，错误信息往往指向具体阶段。例如：
立即学习“Python免费学习笔记（深入）”；
- red">[SSL: CERTIFICATE_VERIFY_FAILED]：证书不可信 —— 检查系统/Python 是否缺少根证书，或服务端证书链不完整（需补全中间证书）
-
[SSL: UNKNOWN_PROTOCOL]：服务端未启用 TLS，或客户端发了 HTTP 请求却期望 TLS 响应 —— 确认 URL 是
https://，且服务监听在 TLS 端口（如 443） -
[SSL: HANDSHAKE_FAILURE]：加密套件不匹配、协议版本不兼容、SNI 未提供导致虚拟主机路由错误 —— 用
openssl s_client -connect example.com:443 -servername example.com手动测试可辅助定位 - 超时或连接重置：可能因防火墙拦截 TLS 流量、服务端 TLS 配置异常（如只支持 TLS 1.3 但客户端太旧），或网络中间设备（如某些代理）不支持 ALPN 扩展
