浏览器地址栏里那把"小锁"已经是网站标配，但HTTPS到底保护了什么、又是怎么做到的，很多人并不清楚。简单说，HTTPS就是HTTP over TLS——把HTTP报文放进TLS建立的加密信道里传输，HTTPS的秘密几乎全部藏在TLS之中。本文从HTTP的明文风险讲起，拆解加密三要素，再走一遍TLS握手全过程。
一、HTTP明文传输，风险不止"看得见"
HTTP的数据在网络上以明文传递，途经路由器、交换机、Wi-Fi热点等每个环节，内容都暴露在传输链路上。电商下单、网银转账、登录提交这类敏感操作，一旦走明文通道，等于把家门钥匙放在门口。由此带来三类典型风险。
窃听：账号、密码、订单信息在传输途中被截获即可直接读取。在公共Wi-Fi环境下，这类截获的门槛很低。
篡改：报文在传输中被替换或插入，比如把页面中的下载链接指向被植入恶意代码的文件，用户难以察觉。
冒充：通过DNS劫持等手段，用户访问到的可能是一个外观相似的仿冒站点，而真实服务器无法向用户自证身份。
二、加密三要素：机密性、完整性、身份认证
TLS要解决的正是上述三类问题，对应三项安全目标。
机密性：数据只能被通信双方读懂。实现方式是会话密钥加密，通常采用AES等对称加密算法，速度快，适合批量数据。
完整性：数据在传输中未被篡改。实现方式是对消息计算消息认证码（MAC），接收方重新计算并比对，不一致即视为被篡改。
身份认证：确认"对方真的是对方"。实现方式是基于数字证书与数字签名：服务器向证书颁发机构（CA）申请证书，客户端沿证书链验证其身份。
三者缺一不可：只有加密没有认证，盗取者可以冒充服务器骗取密钥；只有认证没有加密，数据依然明文可读。TLS的加密策略是混合加密：握手阶段用非对称加密协商会话密钥，数据传输阶段用对称加密加密业务数据。原因并不复杂——非对称算法计算开销大，不适合海量数据；对称加密速度快，但密钥如何在公开网络上安全送达，正是握手要解决的核心问题。
三、TLS握手：从随机数到加密信道
握手的目标，是在公开网络上协商出一套双方认可、且不被第三方获知的加密参数。以TLS1.2为例，核心流程如下。
步骤1，ClientHello：客户端生成随机数ClientRandom，连同支持的TLS版本、密码套件清单发送给服务器。
步骤2，ServerHello：服务器选定版本与套件，生成随机数ServerRandom，连同自己的数字证书一起返回。
步骤3，证书校验：客户端用CA公钥沿证书链逐级验证，确认证书合法、域名匹配、且在有效期内，从而信任服务器身份。
步骤4，密钥交换：双方基于两次随机数及额外交换的秘密，各自独立计算出同一把会话密钥。采用RSA方式时，客户端用服务器公钥加密预主密钥发送；采用ECDHE方式时，双方交换椭圆曲线参数完成协商，并获得前向保密。
步骤5，握手完成：双方互发Finished消息确认，随后切换为对称加密通信。TLS1.3与1.2的差异，可概括为下表。
对比项 | TLS 1.2 | TLS 1.3 |
握手往返 | 通常2次RTT | 首次1次 RTT，会话恢复0-RTT |
密钥交换 | 支持RSA、ECDHE等 | 仅保留ECDHE等前向保密算法 |
密码套件 | 仍含CBC、SHA-1等旧算法 | 移除旧算法，仅留AEAD类 |
安全性默认值 | 需正确配置才安全 | 默认即安全，降低误配风险 |
需要说明的是，0-RTT携带的早期数据存在被重放的风险，实践中只用于幂等类请求，这是TLS1.3在速度与安全之间的明确取舍。
四、公钥加密、私钥签名：一对密钥两种分工
非对称加密拥有一对密钥：公钥公开，私钥保密。同一对密钥承担两种截然不同的职责。
公钥加密、私钥解密，用于保密。客户端把会话密钥用服务器公钥加密后发送，只有持有私钥的服务器能解开。中间人即便截获密文，没有私钥也无法读取。
私钥签名、公钥验签，用于认证与防篡改。CA用私钥为证书签名，客户端用CA公钥验签，确认证书确由该CA签发、内容未被改动；握手中服务器也会用私钥对关键消息签名，证明自己确实持有证书对应私钥。
理解这一分工，有助于避开一个常见误区：公钥可以公开，私钥绝不能泄露。私钥一旦失守，盗取者就能伪造握手、冒充站点。因此对运维而言，私钥的生成、存储与定期轮换，与证书本身同等重要。
结语
HTTPS并不解决所有安全问题，它解决的是"信道可信"这一环：加密保证机密性，MAC保证完整性，证书与签名保证身份。对网站运营者来说，启用HTTPS、保持TLS1.2及以上版本、妥善管理私钥，是基本的安全基线；证书的算法强度、证书链完整性与有效期管理，同样影响最终的安全效果。锐成信息提供SSL/TLS证书申请、自动化部署与证书全生命周期管理，帮助网站把HTTPS配置落到实处。
