三十多年来，SSL 和 TLS 协议为数十亿次在线交易提供了保护。从 1994 年网景公司雄心勃勃的安全项目开始，发展到今天复杂的加密标准。SSL 的历史跨越了六个主要协议版本、无数次安全改进以及我们对网络安全思考方式的根本性转变。
了解 SSL/TLS 版本不仅仅是要知道哪些协议已经过时。而是要了解每个漏洞、攻击和突破是如何形成当前的格局的，其中 TLS 1.3 可确保 95% 的加密网络流量的安全。
目录
- 网景公司 SSL 协议的诞生
- SSL 3.0 – 协议的全面重新设计
- TLS 1.0 – IETF 标准化时代
- TLS 1.1 和 TLS 1.2 – 安全性逐步增强
- TLS 1.3 – 现代安全标准
- 关于 SSL/TLS 版本的常见误解
- 证书颁发机构在 SSL/TLS 演进中的作用
- 影响 HTTPS 采用的行业里程碑
- 推动协议演变的主要安全漏洞
- SSL/TLS 协议的未来
网景公司 SSL 协议的诞生
SSL 1.0 – 未发布的首次尝试（1994 年）
1994 年，网景公司首席科学家塔希尔-埃尔加马尔设计了最初的安全套接字协议层。但SSL 1.0从未面世。网景公司的安全研究人员在公开发布之前就发现了关键漏洞，这些漏洞严重到足以废弃整个版本。
教训是显而易见的：加密协议在部署前需要进行广泛的审查。这次挫折虽然令人沮丧，但却建立了一种严格的测试模式，这种模式将决定未来 SSL 和 TLS 的开发。
SSL 2.0 – 首次公开发布（1995 年）
SSL 什么时候问世的？答案是1995 年 2 月，Netscape 在Navigator 1.1 中捆绑了SSL 2.0。这个 SSL 版本引入了至今仍在使用的基本概念：SSL 握手 SSL 握手过程、X.509数字证书和服务器验证。
但 SSL 2.0 存在一些问题。它依赖MD5进行信息验证，使用相同的密钥进行加密和验证，而且缺乏对握手本身的保护。攻击者可以将连接降级为较弱的 40 位加密，而双方都不会察觉。
2011 年 3 月，IETF通过 RFC 6176 正式废除了 SSL 2.0。当时，大多数服务器都已继续使用。
SSL 3.0 – 协议的全面重新设计
与 SSL 2.0（1996 年）相比的主要改进
Paul Kocher、Phil Karlton 和Alan Freier在1996 年 11 月发布的 3.0 版中完全重写了 SSL 协议。他们将数据传输层与信息层分开，增加了对Diffie-Hellman密钥交换和Fortezza密码套件的支持，并实施了适当的128 位密钥。
SSL 3.0 还引入了记录压缩和更灵活的密码套件协商。IETF 后来将其记录在 RFC 6101 中，承认其历史重要性。近二十年来，SSL 3.0 一直是传统系统的备用选项。
POODLE 漏洞和 SSL 3.0 过时
2014 年 10 月，谷歌安全团队发现了 POODLE(填充 Oracle on Downgraded Legacy Encryption）。该攻击利用了 SSL 3.0 处理密码块链（CBC）模式填充的方式。攻击者可以通过迫使浏览器从 TLS 降级到 SSL 3.0 来解密安全 HTTP cookie。
IETF 迅速做出反应，于2015 年 6 月通过 RFC 7568 废弃了 SSL 3.0。这标志着SSL 时代的终结。当人们问及“最新的 SSL 版本“时，答案是 SSL3.0，因为 SSL 本身再也没有更新过。火炬已传递给 传输层安全.
TLS 1.0 – IETF 标准化时代
从 SSL 到 TLS 的过渡（1999 年）
20 世纪 90 年代末，IETF 希望实现互联网安全协议的标准化。蒂姆-迪尔克斯（Tim Dierks）和克里斯托弗-艾伦（Christopher Allen）领导了将 SSL 转变为开放标准的工作。微软和网景公司就命名问题进行了协商，最终妥协为 “传输层安全”（TransportLayer Security）。
TLS 1.0 于1999 年 1 月作为 RFC 2246 发布，本质上是 SSL 3.1 的新名称。虽然差异不大，但足以破坏兼容性。如果不仔细实施，就无法将 SSL 3.0 客户端与 TLS 1.0 服务器混合使用。
与 SSL 3.0 的主要区别
TLS 1.0 升级了底层加密技术。它用密码学家标准化的HMAC 取代了 SSL 的自定义消息验证码 (MAC)。密钥推导功能发生了变化，以防止某些理论攻击。警报系统增加了更具体的错误代码。
TLS 1.0 还要求支持DSS/DH密码套件，为实施提供了更大的灵活性。这些变化看似微小，却反映了从专有开发到社区驱动标准化的转变。IETF 现在控制着协议的发展。
TLS 1.1 和 TLS 1.2 – 安全性逐步增强
TLS 1.1 防范 CBC 攻击（2006 年）
TLS 1.1于2006 年 4 月通过 RFC 4346 发布，解决了特定的 CBC 漏洞。最大的变化是什么？显式初始化向量（IV）取代了隐式 IV。这就防止了攻击者预测 IV 和利用密码块链。
TLS 1.1 还改进了填充记录的错误处理。它不再显示特定的填充错误，而是返回一个通用的bad_record_mac警告。这些改进可防止多年后在 2011 年被发现的BEAST（Browser Exploit Against SSL/TLS）。
建立了 IANA 参数注册机构，使密码套件管理更加有序。但采用的速度很慢。许多组织完全跳过了 TLS 1.1，等待TLS 1.2 的更大改进。
TLS 1.2 增强灵活性（2008 年）
TLS 1.2 什么时候发布的？ 2008 年 8 月，通过 RFC 5246 发布。这次更新带来了 SSL 3.0 以来最重大的变化。协议从硬编码MD5/SHA-1组合转为密码套件指定的伪随机函数 (PRF)。 SHA-256成为新标准。
TLS 1.2 引入了带附加数据的验证加密（AEAD）密码模式，包括AES-GCM和ChaCha20-Poly1305。它为实现者提供了选择散列和签名算法的灵活性。随着加密标准的发展，这种适应性被证明是至关重要的。
如今，该协议仍在广泛使用。约95.8% 的网站仍支持 TLS 1.2，通常与TLS 1.3 同时运行。2021 年 3 月，IETF 通过 RFC 8996 联合废除了 TLS 1.0 和 1.1，使 TLS 1.2 成为可接受的最低标准。
TLS 1.3 – 现代安全标准
发展的五年（2018）
TLS 1.3历经十年才问世。经过 28 份草案和广泛合作，IETF 于2018 年 8 月发布了 RFC 8446。简化和性能推动了重新设计。工作组删除了遗留功能，简化了握手过程，并消除了整类漏洞。
谷歌、Mozilla、微软和苹果很快就增加了支持。到2019 年，所有主流浏览器都能协商 TLS 1.3 连接。Cloudflare 和其他 CDN 提供商默认启用了这一功能。最新的 TLS 版本不仅提高了安全性，还使加密连接的速度更快。
革命性的安全改进
TLS 1.3 删除了所有被破坏或削弱的内容。SHA-1、MD5、RC4、DES 和 3DES 密码套件？已删除。静态 RSA 和 Diffie-Hellman 密钥交换？取消了。协议现在要求 完美的前向保密所有连接都使用短暂的Diffie-Hellman 密钥。
握手过程发生了根本性变化。ServerHello 之后的每条信息都进行了加密，使协商过程不被窥探。密钥推导功能改为基于 HMAC 的提取和展开（HKDF），提供了更好的加密保证。
TLS 1.3 还引入了0-RTT（零往返时间）模式。客户端可以在第一条信息中向之前联系过的服务器发送加密数据，从而消除了握手延迟。简化的状态机降低了实现过程中的错误率。ECC 与 RSA-PSS 等新签名算法一起被纳入基本规范。
目前的采用和共存情况
最新的 TLS 版本是什么？ TLS 1.3。但 TLS 1.2 不会很快过时。企业需要时间升级服务器、测试兼容性和更新客户端软件。现在，大多数具有安全意识的网站都支持两种版本，让客户选择最佳的可用选项。
共存运行良好。服务器协商相互支持的最高版本。无法处理 TLS 1.3 的客户端会退回到 TLS 1.2。这种循序渐进的迁移方式避免了先前的兼容性灾难。
关于 SSL/TLS 版本的常见误解
为什么没有 TLS 2.0
TLS 2.0 的发布日期是什么时候？ 没有一个。 TLS 2.0 不存在，也永远不会存在。IETF 使用递增版本：TLS 1.0、1.1、1.2、1.3。下一个版本（如果有的话）将是TLS 1.4，也可能是 TLS 2.0，但在 SSL 3.0 之后直接跳到 “TLS 2.0 “会造成极大的混乱。
人们通常希望协议使用主要版本号（就像软件从版本 1 跳到版本 2）。但加密协议的发展更为保守，每个版本都是在前一个版本的基础上发展而来。
SSL 与 TLS 术语
如果要求提供 “SSL 证书”，你会得到一个适用于 TLS 1.2 和 TLS 1.3 的证书。业界仍在营销中使用 “SSL”，因为它耳熟能详。尽管目前的 SSL 版本在技术上并不存在（SSL 终止于 3.0 版），但这个词还是沿用了下来。
DigiCert 和 Sectigo 等证书颁发机构出售只使用 TLS 协议的 “SSL 证书”。这很令人困惑，但无伤大雅。只要记住：当有人在 2026 年提到 SSL 时，他们几乎肯定指的是 TLS。
证书颁发机构在 SSL/TLS 演进中的作用
验证类型开发
早期的 SSL 证书既昂贵又缓慢。 业务验证需要数天或数周的人工验证。2002 年，GeoTrust 推出了 域名验证，通过电子邮件或 DNS 记录验证域名所有权，使验证过程自动化。
扩展验证证书于2007 年推出，承诺通过浏览器中的绿色地址栏提供最高保证。Let’s Encrypt于2015 年推出，通过自动签发提供免费的域名验证证书。Cloudflare随后推出了自己的免费证书计划。这些变化使 HTTPS，使小型网站也能使用加密技术。
缩短证书有效期
证书有效期不断缩短。2015 年，基准要求将最长有效期从五年降至三年。2018 年，两年成为上限。苹果的 Safari 在 2020 年执行了一年的最长有效期，迫使其他浏览器跟进。
现在，业界正在推动缩短证书生命周期。CA/Browser Forum 已明确规定缩短证书有效期：自 2026 年 3 月 15 日起缩短 200 天，自 2027 年 3 月 15 日起缩短 100 天， 到 2029 年 3 月 15 日仅缩短 47 天。
这种转变使得人工证书管理变得不切实际，从而推动企业采用自动化解决方案，如基于 ACME 的证书即服务（CaaS），在这种解决方案中，验证、签发和续期都是自动处理的。
影响 HTTPS 采用的行业里程碑
谷歌推动 HTTPS
2014 年 8 月，谷歌宣布将 HTTPS 作为排名信号。这一决定改变了 SSL 的历史。忽视加密的网站管理员们突然有了关心加密的商业理由。到2016 年，一半的网络流量都已加密。
Chrome 68 在2018 年 7 月采取了下一步措施，将所有 HTTP 网站标记为”不安全.”该警告出现在每个未加密页面的地址栏中。如今，超过95%的网络流量使用 HTTPS。谷歌将加密从一项安全最佳实践变成了一项业务要求。
浏览器安全指标的演变
还记得扩展验证的绿色地址栏吗？它已经消失了。Chrome 浏览器在 2020 年移除了它，因为调查显示用户并没有注意到或理解它。挂锁图标本身也正在消失，取而代之的是使 HTTPS 正常化而非奖励它的中性指标。
Chrome 浏览器 69 删除了 “安全 “文本，只留下挂锁。当前浏览器的重点是警告不安全连接，而不是赞扬安全连接。这就是信息：HTTPS 是默认期望，而非特殊要求。
推动协议演变的主要安全漏洞
针对 SSL/TLS 的著名攻击
POODLE在2014 年攻击了 SSL 3.0，利用了 CBC 模式中的填充甲骨文漏洞。攻击者可以通过降级连接和反复修改密文来解密安全 cookie。这次攻击在几个月内就杀死了 SSL 3.0。
BEAST在2011 年利用类似的 CBC 弱点攻击了 TLS 1.0。攻击者可以通过注入客户端代码和观察加密响应来解密 HTTPS cookie。修复方法要求在 TLS 1.1 中实施显式 IV。
BREACH在2013 年滥用了 HTTP 压缩。这次攻击并不针对 TLS 协议本身，但显示了应用层的决策如何影响安全性。2014 年发现的 “心脏出血“暴露了一个关键的 OpenSSL实施漏洞，泄露了私钥和用户数据。
经验教训
每个漏洞都证明了同一个观点：向后兼容是危险的。为传统系统保留旧协议会产生攻击向量。业界学会了积极淘汰和强制升级。
安全研究人员也功不可没。公开披露漏洞加速了改进。如果没有 POODLE，SSL 3.0 可能至今仍潜伏在服务器配置中。
SSL/TLS 协议的未来
后量子密码学
量子计算机威胁着当前的加密算法。一旦量子计算机达到足够的规模，RSA 和椭圆曲线加密技术就会过时。NIST 正在对旨在抵御量子攻击的后量子算法进行标准化。
TLS 需要更新才能支持这些抗量子算法。后量子加密技术使用更大的密钥和不同的数学方法，因此过渡并不容易。但是，从 SSL 2.0 到 TLS 1.3 的协议演进证明，社区能够应对重大转型。
新兴技术
DTLS（数据报传输层安全）将 TLS 扩展到 UDP 连接。 QUIC由谷歌开发并由 IETF 标准化，将加密直接集成到传输层中。这些协议建立在 TLS 的加密基础之上，同时适应不同的使用情况。
Remme等基于区块链的替代方案正在尝试分布式PKI。证书颁发机构将继续发展，实现更多流程自动化并支持更短的有效期。TLS 1.3 之后会发生什么？可能是逐步改进，而不是完全重新设计。TLS 1.3 做对了大部分事情。
与 SSL Dragon 的 TLS 1.3 Ready 证书保持同步
了解协议演变是一回事。实施现代加密标准则是另一回事。SSL Dragon提供与 TLS 1.3 和 TLS 1.2 完全兼容的数字证书，支持最新的加密协议和密码套件。
我们与 DigiCert、Sectigo 和 GeoTrust 等领先的证书颁发机构合作，提供快速颁发、强大加密和 99.99% 的浏览器信任度。我们的自动证书管理解决方案可帮助您处理即将到来的 47 天生命周期，而无需手动更新。
从过时的协议迁移？我们的专业支持团队将指导您完成过渡。每次购买均享有 25 天退款保证。 了解我们的证书组合并使用最新的 TLS 版本保护您的基础架构。
