TLS 与 SSL 有什么区别？你应该使用哪一个？

一份面向网站站长、开发者与运维人员的深度技术指南，从协议演变、工作原理、安全漏洞、性能对比到升级实战，全面解析 SSL 为何已被废弃、TLS 1.3 为何成为现代标准，以及今天你到底该用哪一个。

1. 开头导语

自 1994 年 Netscape 推出 SSL 协议以来，互联网加密通信已经走过了三十余年。然而时至今日，仍有大量网站在配置中保留 SSL 3.0，仍有不少人在购买所谓的"SSL 证书"。根据 SSL Pulse 的长期监测，全球 Top 15 万网站中仍有少量站点未完全禁用旧版 TLS，而 SSL 3.0 的残余配置在中小站点中更为普遍。

对站长和开发者而言，能否正确理解 TLS 与 SSL 的区别，直接决定了三件事：通信数据的机密性（是否会被窃听解密）、用户信任度（浏览器是否显示安全锁标）、以及合规性（PCI DSS、等保 2.0 等均要求 TLS 1.2+）。本指南将系统讲解 SSL 与 TLS 的历史演变、协议结构差异、握手流程对比、已知安全漏洞、性能优劣、检测方法与升级配置实战，帮助你彻底告别 SSL，拥抱 TLS 1.3。

2. SSL 与 TLS 是什么

在讨论区别之前，必须先厘清两者的定义与定位。SSL 与 TLS 是同一技术谱系的前后两代协议，TLS 是 SSL 的官方继任者，但二者在协议细节上并不兼容。

2.1 SSL（Secure Sockets Layer，安全套接层）

SSL 是由Netscape（网景公司）于 1994 年设计的安全协议，旨在为客户端与服务器之间的通信提供加密、认证和数据完整性保护。SSL 是 HTTPS 的技术基础，曾广泛用于 Web 浏览器与网站之间的加密连接。SSL 共发布三个版本：1.0（未公开）、2.0（1995）、3.0（1996）。

2.2 TLS（Transport Layer Security，传输层安全）

TLS 是 SSL 的继任者，由IETF（互联网工程任务组）在 SSL 3.0 的基础上制定，于 1999 年发布首个版本 TLS 1.0（RFC 2246）。TLS 与 SSL 在设计理念上一脉相承，但修复了大量安全漏洞，引入了更强的加密算法，并经历了从 TLS 1.0 到 TLS 1.3 共四个版本的演进。

2.3 "SSL 证书"的真相

关键澄清：尽管 TLS 已经取代了 SSL 二十年，但"SSL 证书"这一术语至今仍在业界广泛使用。实际上，今天我们购买的所谓"SSL 证书"，本质上都是TLS 证书。证书本身不绑定协议版本，而是由服务器配置决定使用 SSL 还是 TLS。

3. 历史演变：从 SSL 到 TLS

理解历史脉络，才能理解为什么今天必须使用 TLS 而非 SSL。下表展示了 SSL 与 TLS 各版本的发布时间与当前状态。

3.1 协议版本时间线

3.2 关键历史节点

• 1994 年：Netscape 启动 SSL 协议设计，目的是为早期 Web 提供加密通道。
• 1995 年：SSL 2.0 发布，但很快被发现存在严重安全缺陷。
• 1996 年：SSL 3.0 发布，几乎是一次全面重写，成为 TLS 的直接基础。
• 1999 年：IETF 接手，发布 TLS 1.0（RFC 2246），标志着协议标准化。
• 2014 年：POODLE 攻击曝光，证明 SSL 3.0 可被利用解密 Cookie，SSL 彻底被判死刑。
• 2018 年：TLS 1.3 发布（RFC 8446），大幅简化握手流程并移除所有已知不安全机制。
• 2020 年：Apple、Google、Microsoft、Mozilla 联合宣布停止支持 TLS 1.0 和 1.1。

重要：自 2014 年 POODLE 攻击曝光后，SSL 3.0 已被证明不安全。所有主流浏览器（Chrome、Firefox、Safari、Edge）和 IETF 均已正式废弃 SSL。RFC 7568 明文禁止使用 SSL 3.0。

4. SSL 与 TLS 的核心区别

虽然 TLS 本质上是 SSL 的升级版本，但二者之间在协议结构、报文格式、密码套件和握手流程上存在多项重要差异，使得二者无法直接互通。

4.1 协议层级位置

SSL 和 TLS 都位于传输层之上、应用层之下，为上层协议（如 HTTP、SMTP、FTP 等）提供安全保障：

• 加密：对应用数据对称加密，防止窃听
• 认证：通过数字证书验证服务器（可选客户端）身份
• 完整性：通过 MAC/AEAD 保证数据不被篡改

4.2 记录协议差异

SSL 和 TLS 在协议报文格式（Record Protocol）上存在细微差别，版本号字段、MAC 算法、伪随机函数均不同，使得二者无法直接互通：

4.3 密码套件命名差异

TLS 1.2 的密码套件名称包含完整四元组（密钥交换 + 认证 + 加密 + MAC）：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 │ │ │ │ │ │ │ │ │ │ │ └─ MAC 算法（SHA384） │ │ │ │ └── 加密模式（GCM） │ │ │ └───── 对称加密算法（AES 256） │ │ └─────── 认证算法（RSA） │ └────────── 密钥交换算法（ECDHE） └─────────── 协议（TLS）

TLS 1.3 大幅简化了命名，因为密钥交换和认证已固定为 (EC)DHE，不再出现在套件名中：

TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256

4.4 握手流程差异

TLS 1.3 相比 SSL/TLS 早期版本大幅简化了握手流程。SSL 3.0 和 TLS 1.2 需要 2 个往返（2-RTT）完成握手：

Client Server │ ──────── ClientHello ──────────────► │ │ ◄──────── ServerHello ────────────── │ │ ◄──────── Certificate ────────────── │ │ ◄──────── ServerKeyExchange ───────── │ │ ◄──────── ServerHelloDone ────────── │ │ ──────── ClientKeyExchange ─────────► │ │ ──────── ChangeCipherSpec ─────────► │ │ ──────── Finished ─────────────────► │ │ ◄──────── ChangeCipherSpec ────────── │ │ ◄──────── Finished ────────────────── │ │ ═════════ 应用数据（已加密）═════════ │

而 TLS 1.3 将握手压缩到1-RTT，并支持 0-RTT 恢复连接：

Client Server │ ──── ClientHello + KeyShare ──────► │ │ ◄── ServerHello + KeyShare ──────── │ │ ◄── EncryptedExtensions ──────────── │ │ ◄── Certificate ──────────────────── │ │ ◄── CertificateVerify ────────────── │ │ ◄── Finished ─────────────────────── │ │ ──── Finished ─────────────────────► │ │ ════════ 应用数据（已加密）════════ │

TLS 1.3 优势：握手消息从第一条起就加密传输（除 ClientHello/ServerHello 部分字段），大幅减少握手往返次数，提升连接速度并增强隐私保护——中间人无法再窥探客户端访问了哪个网站（SNI 加密）。

5. TLS 工作原理与握手流程

TLS 协议由两个子协议组成，各司其职。理解这两个子协议，才能真正理解 TLS 在做什么。

5.1 握手协议（Handshake Protocol）

负责在通信双方之间协商加密参数，包括：

• 协议版本协商：客户端与服务器就使用的 TLS 版本达成一致
• 密码套件协商：选择加密算法、密钥交换算法、MAC 算法等
• 证书验证：服务器向客户端出示数字证书，证明其身份
• 密钥生成：通过密钥交换算法生成共享的会话密钥

5.2 记录协议（Record Protocol）

负责对应用数据进行实际的安全处理，流程为：

1. 分片：将应用数据切分为不超过 16KB 的块
2. 压缩：对数据块进行压缩（TLS 1.3 已移除此步骤，防止 CRIME 攻击）
3. 加密：使用协商好的对称密钥加密数据
4. 添加 MAC/AEAD：保证数据完整性与真实性
5. 传输：将处理后的记录通过 TCP 传输

5.3 TLS 1.3 的密码套件

TLS 1.3 仅保留 5 个密码套件，全部为 AEAD 模式（加密与认证一体化），彻底移除了 CBC 模式：

6. 安全性对比

安全性是 SSL 被废弃、TLS 取而代之的最根本原因。SSL 各版本均存在严重安全漏洞，已完全不适合现代安全需求。

6.1 SSL 的已知漏洞

6.2 TLS 1.3 的安全改进

TLS 1.3 针对性地移除了所有已知不安全的机制，从根源上杜绝了上述攻击：

• 移除静态 RSA 密钥交换：防止前向安全性丢失
• 移除 CBC 模式：防止 POODLE、Lucky13 等填充攻击
• 移除 RC4、3DES 等弱加密算法：防止统计攻击和生日攻击
• 移除压缩：防止 CRIME、BREACH 攻击
• 移除重协商：防止拒绝服务攻击
• 强制使用 AEAD 加密：AES-GCM、ChaCha20-Poly1305
• 强制使用前向安全密钥交换：ECDHE
• 握手消息加密：保护证书隐私，防止中间人窥探 SNI

6.3 前向安全性（Forward Secrecy）

前向安全性：即使服务器的长期私钥未来被泄露，过去已传输的加密通信也无法被解密。TLS 1.3 通过强制使用临时 Diffie-Hellman 密钥交换实现了这一点。每次连接使用一次性临时密钥，连接结束后即销毁，攻击者即使日后获取服务器私钥，也无法回溯解密历史流量。

6.4 安全能力对比汇总

7. 性能对比

TLS 1.3 相比旧版本不仅更安全，还更快。握手往返次数的减少和加密算法的优化，带来了显著的性能提升。

7.1 握手延迟对比

7.2 加密性能对比

7.3 实际影响

TLS 1.3 的 1-RTT 握手相比 TLS 1.2 的 2-RTT 可减少约一个往返时间的延迟。对于跨大洲连接，这一个 RTT 可能就是 100~300ms，对用户体验有显著影响。0-RTT 模式下，客户端甚至可以在第一个数据包中就携带应用数据，实现"零延迟"恢复连接（仅限此前已建立过连接的会话）。

0-RTT 注意事项：0-RTT 模式不具备前向安全性，且可能遭受重放攻击。建议仅在 GET 等幂等请求上启用，或干脆不启用 0-RTT 而使用普通 1-RTT。

8. 如何检测网站使用的协议

在升级之前，先要检测当前服务器支持哪些 TLS 版本，以及客户端实际协商使用了哪个版本。

8.1 浏览器查看

1. 在 Chrome 中访问目标网站
2. 点击地址栏左侧的锁形图标
3. 点击"连接是安全的" → “证书有效”
4. 在证书详情中查看协议版本

8.2 在线检测工具

• SSL Labs（SSL Server Test）：https://www.ssllabs.com/ssltest/，最权威的 TLS 配置检测工具，给出 A+~F 评级
• How’s My SSL：https://www.howsmyssl.com/
• TLS Scanner（Censys）：https://search.censys.io/

8.3 命令行检测

使用 OpenSSL 检测服务器支持的 TLS 版本：

# 检测服务器是否支持 TLS 1.3openssl s_client-connectexample.com:443-tls1_3# 检测 TLS 1.2openssl s_client-connectexample.com:443-tls1_2# 查看完整握手过程与协商的密码套件openssl s_client-connectexample.com:443-showcerts# 使用 nmap 扫描 SSL/TLS 配置nmap--scriptssl-enum-ciphers-p443example.com

示例输出：

$ openssl s_client -connect example.com:443 -tls1_3 --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server certificate: subject=CN=example.com ... SSL handshake has read 3896 bytes and written 835 bytes Protocol version: TLSv1.3 Ciphers: TLS_AES_256_GCM_SHA384

9. 为什么不应该再使用 SSL

如果你或你的服务器仍在使用 SSL，以下是坚决应立即升级的理由：

1. 安全漏洞：SSL 3.0 存在 POODLE 等严重漏洞，可被攻击者利用解密敏感数据
2. 已被官方废弃：IETF 在 RFC 7568 中正式禁止使用 SSL 3.0
3. 浏览器不支持：所有主流浏览器均已停止支持 SSL
4. 性能落后：SSL 的加密算法和握手流程效率远低于现代 TLS
5. 合规要求：PCI DSS、HIPAA、GDPR、等保 2.0 等合规标准要求使用 TLS 1.2 或更高版本
6. 证书机构不再签发：CA/Browser Forum 已禁止为 SSL 签发证书

警告：如果你的服务器仍在使用 SSL 3.0 或更低版本，请立即升级到 TLS 1.2 或 1.3。继续使用 SSL 将使你的网站和用户面临严重安全风险，并可能导致现代浏览器无法访问你的网站。

10. 你应该使用哪一个

10.1 结论

今天你应该使用 TLS 1.3，至少使用 TLS 1.2。不要使用 SSL。

SSL 已彻底过时且不安全。当你看到"SSL 证书"这个说法时，它实际上指的是 TLS 证书。

10.2 按场景选择

10.3 兼容性参考

• TLS 1.3支持：Chrome 70+、Firefox 63+、Safari 12.1+、Edge 79+（2018 年后浏览器基本均支持）
• TLS 1.2支持：所有 2010 年后发布的现代浏览器
• 如果你的用户群体中不存在极旧客户端，建议直接仅启用 TLS 1.2 + TLS 1.3

11. 如何升级到 TLS 1.3

11.1 Nginx 配置示例

server { listen 443 ssl http2; server_name example.com; # 证书路径 ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; # 仅启用 TLS 1.2 和 1.3 ssl_protocols TLSv1.2 TLSv1.3; # TLS 1.3 密码套件（自动协商） ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256; ssl_prefer_server_ciphers off; # 会话恢复（支持 0-RTT） ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; ssl_session_tickets off; # OCSP 装订 ssl_stapling on; ssl_stapling_verify on; # HSTS add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; }

11.2 Apache 配置示例

<VirtualHost *:443> ServerName example.com SSLEngine on SSLCertificateFile /etc/ssl/certs/example.com.crt SSLCertificateKeyFile /etc/ssl/private/example.com.key # 仅启用 TLS 1.2 和 1.3 SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 SSLHonorCipherOrder off # HSTS Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" </VirtualHost>

11.3 升级检查清单

• 确认服务器软件（Nginx/Apache/HAProxy）版本支持 TLS 1.3
• 确认 OpenSSL 版本 ≥ 1.1.1（TLS 1.3 最低要求）
• 申请符合 SHA-256 签名的证书（EV/OV 证书可选）
• 配置仅启用 TLS 1.2 + TLS 1.3
• 移除对 SSL 3.0、TLS 1.0、TLS 1.1 的支持
• 启用 HSTS 并提交到 HSTS Preload List
• 使用 SSL Labs 检测，确保评级达到 A 或 A+
• 验证关键客户端兼容性
• 启用 OCSP 装订（Stapling）

12. 最佳实践清单

按优先级从高到低，给出可立即落地的建议：

1. 立即禁用 SSL 3.0 及以下所有版本，这是当前最大的安全风险。
2. 仅启用 TLS 1.2 和 TLS 1.3，移除 TLS 1.0 和 1.1 的支持。
3. 强制使用 ECDHE 密钥交换，确保前向安全性。
4. 启用 HSTS 并提交 Preload List，防止降级攻击和 SSL 剥离。
5. 使用 SSL Labs 检测，确保评级达到 A 或 A+。
6. 启用 OCSP 装订，提升证书验证速度和隐私。
7. 使用 Mozilla SSL 配置生成器（https://ssl-config.mozilla.org/）生成安全配置。
8. 证书使用 RSA 2048 或 ECDSA 256+，禁用 SHA-1 签名证书。
9. 定期轮换证书密钥，使用 Let’s Encrypt 自动续期。
10. 每季度审计一次 TLS 配置，跟进新版本和漏洞公告。

13. 常见问题 FAQ

Q1：SSL 证书和 TLS 证书是同一回事吗？

是的。今天市面上购买的"SSL 证书"实际上都是 TLS 证书。"SSL 证书"只是个习惯叫法，证书本身并不绑定协议版本，而是由服务器配置决定使用 SSL 还是 TLS。

Q2：HTTPS 用的是 SSL 还是 TLS？

现代 HTTPS 使用的是TLS。虽然 HTTPS 全称是"HTTP over SSL"，但自 SSL 被废弃后，实际传输都基于 TLS。TLS 1.3 是当前推荐版本。

Q3：如果我的服务器配置了 TLS 1.3，旧客户端还能访问吗？

只要同时启用 TLS 1.2，绝大多数 2010 年后的客户端都能正常访问。仅当客户端极为陈旧（如 IE6/IE8）才可能无法连接。

Q4：升级到 TLS 1.3 需要更换证书吗？

不需要。TLS 1.3 兼容现有 X.509 证书，无需重新申请。只要私钥和证书格式正确，原有证书可继续使用。

Q5：TLS 1.3 的 0-RTT 模式安全吗？

0-RTT 模式不具备前向安全性，且可能遭受重放攻击。建议仅在 GET 等幂等请求上启用，或干脆不启用 0-RTT 而使用普通 1-RTT。

Q6：自签名证书和 CA 签发的证书在 TLS 上有区别吗？

加密强度没有区别。区别在于信任链：CA 签发的证书可被浏览器自动信任，而自签名证书会触发浏览器警告。可使用 Let’s Encrypt 免费获取受信任的证书。

Q7：SSL 3.0 到底有什么问题，为什么不能用？

SSL 3.0 使用了不安全的 CBC 模式填充方案，POODLE 攻击可利用此缺陷在约 1/256 的概率下解密一个字节，结合大量请求可逐步恢复 Cookie 等敏感信息。此外，SSL 3.0 使用 RC4 等已被破解的算法，且无降级攻击防护，IETF 在 RFC 7568 中已正式禁止其使用。

Q8：等保 2.0 对 TLS 版本有什么要求？

等保 2.0 第三级安全要求中，通信传输应采用密码技术保证数据机密性和完整性。实际测评中，通常要求至少使用 TLS 1.2，推荐 TLS 1.3，并禁用 SSL 和 TLS 1.0/1.1。

14. 总结与行动清单

TLS 与 SSL 之争，答案明确：SSL 已死，TLS 当立。请按以下时间线落地你的升级计划：

• 今天：检测服务器当前 TLS 配置（用 SSL Labs），禁用 SSL 3.0 和 TLS 1.0/1.1。
• 本周：配置 Nginx/Apache 仅启用 TLS 1.2 + TLS 1.3，使用 Mozilla 配置生成器生成安全参数。
• 本月：启用 HSTS 并提交 Preload List，开启 OCSP 装订，用 SSL Labs 复检达到 A+。
• 本季度：评估是否全面切换到仅 TLS 1.3（若客户端兼容），轮换证书密钥。
• 长期：每季度审计 TLS 配置，跟进新漏洞公告（如新一轮降级攻击、侧信道攻击），及时更新。

记住核心原则：禁用一切旧协议，只保留 TLS 1.2 和 1.3；强制前向安全密钥交换；启用 HSTS 防降级；定期审计配置。做到这四点，你的加密通信就站在了 2026 年的安全基线上。

「织码间」主理人：用代码构建世界，期待与你同频共振。