引言：为什么需要 HTTPS？
在传统的 HTTP 协议中，数据是以明文形式在网络中传输的，这带来了三大安全风险：窃听（隐私泄露） 、篡改（数据被劫持修改）和冒充（钓鱼网站） 。
为了解决这些问题，HTTPS 应运而生。HTTPS 的本质是在 HTTP 与 TCP 之间引入了一个安全层——TLS/SSL 协议。它通过混合加密体系，完美兼顾了安全与效率：
- 非对称加密：在握手阶段使用，用于验证服务器身份并安全地协商出“会话密钥”。
- 对称加密：在握手完成后使用，双方用协商出的“会话密钥”进行高性能的数据传输。
一、 TLS 1.2 握手流程七步走
第一步：Client Hello（客户端问好）
浏览器（客户端）向服务器发送请求，携带以下信息：
- 客户端支持的 TLS 版本。
- 客户端支持的加密套件列表（如 RSA、ECDHE、AES256-GCM 等）。
- 客户端生成的随机数 Random1。
第二步：Server Hello（服务器回应）
服务器确认客户端信息，并返回：
- 确认使用的加密套件。
- 服务器生成的随机数 Random2。
- 服务器的数字证书（内含服务器域名、服务器公钥、CA数字签名等）。
第三步：浏览器验证证书
浏览器利用操作系统或浏览器内置的 CA 公钥，对收到的证书进行有效性验证（验证域名、过期时间及 CA 签名）。验证通过后，浏览器便可以安全、放心地拿到服务器的公钥。
第四步：生成并发送预主密钥（Pre-Master Secret）
浏览器在内存中随机生成第三个随机数——预主密钥（Pre-Master Secret） 。接着，使用刚拿到的服务器公钥对该预主密钥进行加密，并发送给服务器。此时，网络上的窃听者即便截获了密文，没有服务器私钥也无法解密。
第五步：服务器解密
服务器收到密文后，使用自己妥善保管的服务器私钥进行解密，成功获取到预主密钥（Pre-Master Secret） 。
第六步：双方独立生成会话密钥（Session Key）
至此，客户端和服务器双方都同时拥有了三把钥匙：Random1、Random2 和 Pre-Master Secret。
双方通过相同的伪随机数函数（PRF）算法，将这三个输入源合并计算，各自派生出完全相同的会话密钥（Session Key） ：
Session Key=PRF(Pre-Master Secret,Random1,Random2)\text{Session Key} = \text{PRF}(\text{Pre-Master Secret}, \text{Random1}, \text{Random2})Session Key=PRF(Pre-Master Secret,Random1,Random2)
第七步：开始对称加密通信
握手正式完成。后续所有 HTTP 请求和响应（如 GET /api/user），都将转用效率极高的对称加密算法（如 AES、ChaCha20）结合 Session Key 进行加密传输。
三、 现代 TLS 1.3
虽然 TLS 1.2 足够安全，但在现代网络中，大部分主流浏览器（Chrome、Edge、Firefox 等）已经全面升级到了 TLS 1.3。TLS 1.3 带来了两项颠覆性的改进：
1. 废弃 RSA 密钥交换，全面拥抱 ECDHE
- TLS 1.2 的隐患：若使用 RSA 进行密钥交换，一旦服务器的私钥泄露，攻击者就可以解密过去捕获的所有历史流量（因为历史流量中的 Pre-Master Secret 是用该公钥加密的，私钥能解开一切）。
- TLS 1.3 的解决手段：彻底禁用 RSA 密钥交换，强制使用 ECDHE（椭圆曲线迪菲-赫尔曼） 算法。
2. 核心优势：前向保密（Forward Secrecy）与更快的速度
- 前向保密（完美正向安全） ：在 ECDHE 算法下，每次握手双方都会临时生成一对密钥对，用完即丢。服务器的静态私钥仅用于“身份认证（验签）”，而不参与“密钥交换”。这意味着，即使未来服务器的私钥泄露了，攻击者也绝对无法解密过去抓包拦截的历史数据。
- 1-RTT 握手速度：TLS 1.2 协商密钥需要 2 个往返时延（2-RTT），而 TLS 1.3 将算法精简，允许客户端在 Client Hello 时就直接发送椭圆曲线公钥参数，将握手压缩至 1-RTT，甚至支持 0-RTT 恢复连接，传输速度大幅提升。
四、 HTTPS 误区
误区 1：服务器的密钥对是握手时临时生成的？
- 正确事实：服务器的公钥和私钥早就生成好了。通常是运维人员提前向权威的证书颁发机构（CA）申请证书，CA 对服务器的公钥和域名进行数字签名并颁发证书。服务器在启动时直接加载这些证书和私钥。
误区 2：浏览器是用 CA 公钥去“解密”证书？
- 正确事实：数字证书并不是加密传输的，其内容（域名、公钥、有效期等）全是明文。CA 解决的是防篡改问题。
- CA 签名过程：CA 先对证书内容计算一个哈希摘要，然后用 CA 自己的私钥对这个摘要进行加密，生成“数字签名”。
- 浏览器验签过程：浏览器收到证书后，使用内置的 CA 公钥解密数字签名得到“摘要 A”；同时，浏览器对证书内容重新计算一次哈希得到“摘要 B”。若
摘要 A == 摘要 B，且域名、有效期均匹配，则验签通过。 - 结论：这个过程本质是验签（Verify Signature） ，而不是解密（Decrypt） 。
总结
https传输流程：浏览器先发起请求，给服务器传输支持的加密算法以及随机数1，服务器将选择的加密算法和数字证书以及随机数2传给浏览器，浏览器通过内置的CA公钥验证数字签名和重新计算证书内容的哈希摘要进行比对，验证证书内容没有被篡改，然后浏览器生成预主密钥，使用证书里的公钥加密后传回服务器，服务器使用私钥解密后加上随机数1和随机数2通过算法得到和浏览器一样的session key，至此握手完成，之后双方使用session key 进行对称加密通信。
《https连接传输流程》 是转载文章，点击查看原文。
