一、基础概念:从明文到加密的演进
HTTP(超文本传输协议) 作为Web的基石,定义了浏览器与服务器之间的通信规则。它采用明文传输模式,数据在传输过程中未经任何加密处理,如同在公共场合高声对话。这种设计使其默认端口为80,仅需完成TCP三次握手即可传输数据
HTTPS(安全超文本传输协议) 本质是“HTTP over SSL/TLS”,通过在HTTP与TCP层之间插入SSL/TLS加密层实现安全加固
- 端到端加密:所有数据经TLS协议加密后传输
- 身份认证:通过CA证书验证服务器真实性
- 完整性保护:防止数据在传输中被篡改
- 默认使用443端口,需先建立安全通道才能通信
技术演进关键节点: 1994年网景公司发布SSLv2 → 1999年TLS 1.0取代SSL → 2018年TLS 1.3成为主流 → 至今全球HTTPS流量占比超95%(W3Techs数据)
二、核心差异深度剖析
1. 安全机制对比
安全维度 | HTTP | HTTPS |
---|---|---|
传输方式 | 明文传输 | TLS/SSL加密 |
数据防篡改 | 无保护机制 | HMAC摘要算法验证 |
身份认证 | 无 | CA数字证书体系 |
典型攻击防范 | 无法抵御中间人攻击 | 可阻断窃听/篡改/伪造 |
三、协议实现关键差异点
1. 工作流程对比
HTTP通信流程:
浏览器 → TCP三次握手(80端口) → 发送明文请求 → 接收明文响应 → 关闭连接
HTTPS握手过程:
步骤 | 交互内容 | 技术作用 |
---|---|---|
ClientHello | 协议版本+随机数+密码套件 | 协商加密参数 |
ServerHello | 选定套件+随机数+证书 | 身份认证 |
密钥交换 | ECDHE生成预主密钥 | 前向保密保障 |
会话密钥 | HKDF生成加密密钥 | 建立安全通道 |
应用数据传输 | AES-GCM对称加密 | 高效加密传输 |
2. 证书体系解析
HTTPS必须部署SSL/TLS证书,分为三类:
证书类型 | 验证深度 | 适用场景 | 浏览器标识 |
---|---|---|---|
DV | 域名所有权 | 个人博客 | 锁形图标🔒 |
OV | 企业实名认证 | 电商平台 | 🔒+公司名称 |
EV | 严格法律审核 | 银行/支付 | 绿色地址栏 |
证书链示例: 服务器证书 → 中间CA → 根CA(预置在操作系统信任库)
四.SSL/TLS握手详解
TLS 第一次握手
首先,由客户端向服务器发起加密通信请求,也就是 ClientHello 请求。在这一步,客户端主要向服务器发送以下信息:
- (1)客户端支持的 TLS 协议版本,如 TLS 1.2 版本。
- (2)客户端生产的随机数(Client Random),后面用于生成「会话秘钥」条件之一。
- (3)客户端支持的密码套件列表,如 RSA 加密算法
TLS 第二次握手
服务器收到客户端请求后,向客户端发出响应,也就是 SeverHello。服务器回应的内容有如下内容:
- (1)确认 TLS 协议版本,如果浏览器不支持,则关闭加密通信。
- (2)服务器生产的随机数(Server Random),也是后面用于生产「会话秘钥」条件之一。
- (3)确认的密码套件列表,如 RSA 加密算法。(4)服务器的数字证书。
TLS 第三次握手
客户端收到服务器的回应之后,首先通过浏览器或者操作系统中的 CA 公钥,确认服务器的数字证书的真实性。
如果证书没有问题,客户端会从数字证书中取出服务器的公钥,然后使用它加密报文,向服务器发送如下信息:
- (1)一个随机数(pre-master key)。该随机数会被服务器公钥加密。
- (2)加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
- (3)客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数,会发给服务端,所以这个随机数客户端和服务端都是一样的。
服务器和客户端有了这三个随机数(Client Random、Server Random、pre-master key),接着就用双方协商的加密算法,各自生成本次通信的「会话秘钥」。
TLS 第四次握手
服务器收到客户端的第三个随机数(pre-master key)之后,通过协商的加密算法,计算出本次通信的「会话秘钥」。
然后,向客户端发送最后的信息:
- (1)加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
- (2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供客户端校验。