HTTPS详解，及与HTTP的差异

1. 基础定义

HTTP：超文本传输协议（HyperText Transfer Protocol），是互联网上应用最广泛的无状态、明文传输协议，用于客户端（浏览器 / APP）与服务器之间的数据交互，默认端口为 80。

HTTPS：超文本传输安全协议（HyperText Transfer Protocol Secure），是 HTTP 的加密增强版，通过 SSL/TLS 协议对传输数据进行加密，默认端口为 443。本质是 "HTTP + SSL/TLS"，在 HTTP 基础上增加了安全层。

2. 核心差异对比表

HTTP 与 HTTPS 对比表

对比维度	HTTP	HTTPS
传输方式	明文传输，数据未加密	加密传输（对称加密 + 非对称加密结合）
安全层	无，直接传输	基于 SSL/TLS 协议（如 TLS 1.2/1.3）
端口	80	443
认证机制	无服务器身份认证，仅验证 IP	需 CA 证书认证服务器身份，防伪装
数据完整性	无校验，易被篡改	基于 MAC / 哈希值校验，防篡改
性能	无加密 / 解密开销，速度快	握手阶段需密钥交换，略有性能损耗（TLS 1.3 已大幅优化）
证书要求	无需证书	需向可信 CA 机构申请 SSL 证书（免费 / 付费）
浏览器标识	地址栏无 "锁" 图标，显示 "不安全"	地址栏有 "锁" 图标，部分浏览器显示 "安全"
适用场景	静态资源、非敏感信息展示（如纯资讯网站）	敏感数据传输（支付、登录、隐私信息）、所有需要信任的场景

3.HTTP的缺点

到现在为止，我们已了解到 HTTP 具有相当优秀和方便的一面，然 而 HTTP 并非只有好的一面，事物皆具两面性，它也是有不足之处的。
HTTP 主要有这些不足，例举如下。
● 通信使用明文（不加密），内容可能会被窃听
● 不验证通信方的身份，因此有可能遭遇伪装
● 无法证明报文的完整性，所以有可能已遭篡改
这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。
除此之外，HTTP 本身还有很多缺点。而且，还有像某些特定的 Web 服务器和特定的 Web 浏览器在实际应用中存在的不足（也可以说 成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等编程语言开发的 Web 应用也可能存在安全漏洞。

a.通信使用明文可能会被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。
■TCP/IP是可能被窃听的网络

• 如果要问为什么通信时不加密是一个缺点，这是因为，按 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。 所谓互联网，是由能连通到全世界的网络组成的。无论世界哪个角 落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光 缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到 恶意窥视行为。
• 即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加 密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解 报文信息的含义，但加密处理后的报文信息本身还是会被看到的。
• 窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据 包（帧）就行了。对于收集来的数据包的解析工作，可交给那些抓包 （Packet Capture）或嗅探器（Sniffer）工具。

■加密技术
在目前大家正在研究的如何防止窃听保护信息的几种对策中，最为普及的就是加密技术。加密的对象可以有这么几个。
通信的加密
一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通 过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS （HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

内容的加密
还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没 有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报 文里所含的内容进行加密处理。
在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送

诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍 有被篡改的风险。

b.不验证通信方的身份就可能遭遇伪装

HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在 "服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真 的返回到实际提出请求的客户端"等类似问题。

■任何人都可发起请求

在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。
HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患。
● 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
● 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
● 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服 务器上保存着重要的信息，只想发给特定用户通信的权限。
● 无法判定请求是来自何方、出自谁手。
● 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。

■查明对手的证书

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。
另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web网站的认证环节

c.无法证明报文完整性，可能已遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。
■接收到的内容可能有误
由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到 篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。
示例：黑客伪造某银行的 HTTP 登录页面，诱导用户输入银行卡号和密码，用户误以为是官方网站，导致信息泄露（即 "钓鱼攻击"）。
像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

■如何防止篡改
虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。
提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。
不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
可惜的是，用这些方法也依然无法百分百保证确认结果正确。因为PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。

4.HTTP+加密+认证+完整性保护=HTTPS

HTTPS 是身披 SSL 外壳的 HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。
SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

HTTPS 通过 "SSL/TLS 握手 + 加密传输 + 身份认证 + 完整性校验" 四大机制，彻底解决 HTTP 的安全缺陷，具体作用如下：

a. 数据机密性：加密传输，防止窃听

HTTPS 采用 "对称加密 + 非对称加密" 的混合加密方案，确保数据无法被截获者破解：

• 非对称加密（如 RSA、ECC）：用于握手阶段的 "密钥交换"。服务器持有私钥，客户端获取服务器的公钥（从 SSL 证书中提取），客户端生成一个随机的 "会话密钥"，用公钥加密后发送给服务器，服务器用私钥解密得到会话密钥（仅双方知晓）。
• 对称加密（如 AES）：握手后的数据传输均使用 "会话密钥" 加密，对称加密速度快，可避免非对称加密的性能损耗。
• 结果：中间节点即使截获加密数据，因没有会话密钥，无法解密内容（破解 AES-256 加密需要超级计算机级别的算力，实际不可行）。

b. 数据完整性：校验机制，防止篡改

HTTPS 在传输数据时，会对数据计算 "消息认证码（MAC）" 或 "哈希值（如 SHA-256）"，并将其与数据一起传输：

• 客户端接收数据后，会重新计算哈希值，与服务器发送的哈希值对比；
• 若数据被篡改，两次哈希值会不一致，客户端会直接拒绝接收，提示 "数据传输错误"。

c. 身份真实性：CA 证书认证，防止伪装

HTTPS 要求服务器必须部署由可信 CA 机构（如 Let's Encrypt、赛门铁克、阿里云 CA） 颁发的 SSL 证书，证书包含服务器域名、公钥、CA 签名等信息：

• 客户端（浏览器）内置了全球可信 CA 机构的根证书，接收服务器证书后，会通过根证书验证服务器证书的合法性（防止证书伪造）；
• 只有验证通过的服务器，才被认定为 "真实服务器"，避免钓鱼攻击；
• 扩展：EV 型 SSL 证书还会在浏览器地址栏显示 "绿色企业名称"，进一步强化信任（如银行、电商平台常用）。

d. 合规性与兼容性：满足现代网络要求

• 合规性：符合《网络安全法》《个人信息保护法》等法规对 "个人敏感信息传输加密" 的要求，避免企业因数据泄露面临法律风险；
• 兼容性：支持 HTTP/2、HTTP/3 协议（大幅提升传输速度），兼容现代浏览器、APP、物联网设备，是当前网络传输的 "标准安全方案"。

5.HTTPS 的安全通信机制

• 步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
• 步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出的。
• 步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
• 步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段SSL 握手协商部分结束。
• 步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
• 步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret密钥加密。
• 步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
• 步骤 8： 服务器同样发送 Change Cipher Spec 报文。
• 步骤 9： 服务器同样发送 Finished 报文。
• 步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
• 步骤 11： 应用层协议通信，即发送 HTTP 响应。
• 步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

6.补充：HTTPS 的性能优化与常见误解

1. 性能误解：HTTPS 并非 "变慢很多"

早期 HTTPS 因 TLS 握手（需 2-3 次网络往返）和加密 / 解密，确实存在一定性能损耗，但现代优化已大幅缓解：

• TLS 1.3 简化握手流程（仅 1 次往返），握手时间缩短 50%；
• 服务器硬件升级（如支持 AES-NI 硬件加速）、CDN 缓存加密内容，可抵消加密开销；
• 实际用户感知：HTTPS 与 HTTP 的加载速度差异小于 100ms，几乎无法察觉。

2. 常见误解澄清

• 误解 1：HTTPS 能防病毒 / 木马？→ 不能。HTTPS 仅保障 "传输过程安全"，若服务器本身被植入病毒，或用户下载的文件本身带毒，HTTPS 无法检测；
• 误解 2：免费 SSL 证书不安全？→ 安全。免费证书（如 Let's Encrypt）与付费证书的加密强度一致，仅在 "有效期（免费通常 3 个月）""售后支持""企业认证（EV 证书）" 上有差异；
• 误解 3：HTTPS 一定不会被攻击？→ 并非绝对。HTTPS 可抵御绝大多数攻击，但存在 "证书劫持""私钥泄露" 等极端风险（需通过定期更换证书、安全存储私钥规避）。