SSL/TLS — 是什么、协议及加密工作原理

什么是 SSL/TLS？

SSL（安全套接层）——是 Netscape 公司于 1995 年为保护网络流量而开发的协议。第一版 SSL 1.0 从未发布，SSL 2.0（1995）和 SSL 3.0（1996）一直使用到 2000 年代初，但存在严重漏洞。取代 SSL 的是 TLS（传输层安全）——由 IETF 标准化的改进版本。TLS 1.0（1999）基于 SSL 3.0，后续版本 TLS 1.1（2006）、TLS 1.2（2008）和 TLS 1.3（2018）逐渐远离原始架构，添加了新的加密算法并消除了漏洞。如今 SSL 已被视为过时，所有现代系统都使用 TLS，尽管出于惯性，这两种协议经常被一起提及为 SSL/TLS。

协议的创建历史

SSL/TLS 的历史始于早期网络对安全数据传输的需求。1994 年，Netscape 为其 Navigator 浏览器开发了 SSL 1.0，但由于严重的安全问题，该协议从未发布。SSL 2.0 于 1995 年发布并在实践中使用，但包含众多漏洞：缺乏针对中间人攻击的保护、加密算法薄弱以及易受截断攻击。SSL 3.0（1996）解决了大部分问题，但到 2014 年发现了 POODLE 漏洞，之后 IETF 正式宣布所有版本的 SSL 都已过时。TLS 1.0–1.3 相继提高了加密强度、性能和机密性，其中 TLS 1.3 将握手从两次往返减少到一次，这对于连接不稳定的移动应用至关重要。

SSL/TLS 握手如何工作

握手——是客户端和服务器之间建立安全连接的过程。它由多个连续步骤组成，双方在此过程中协商协议版本、选择加密算法、交换密钥并相互验证身份。在 TLS 1.3 中，握手只需要一次网络交互（1-RTT），而在 TLS 1.2 中需要两次（2-RTT）。

第一步，客户端发送 ClientHello——包含支持的 TLS 版本列表、密码套件（cipher suites）和随机数的消息。服务器以 ServerHello 回应，包含选定的版本和密码、其 X.509 证书和数字签名。客户端通过证书颁发机构（CA）链验证证书，生成会话密钥，并用证书中服务器的公钥加密后发送。服务器确认后，开始安全的数据传输。整个握手在现代设备上只需 1-3 毫秒，对用户来说不可见。

X.509 证书与信任链

TLS 身份验证的基础是建立在 X.509 格式证书上的公钥基础设施（PKI）。每个证书包含：域名（通用名称或主题备用名称）、服务器的公钥、颁发者名称（证书颁发机构）、有效期和 CA 的数字签名。客户端通过信任链验证服务器证书：从服务器证书到根 CA，其证书嵌入在操作系统中。在 Android 设备上，根证书存储在系统存储中，通过 Google Play 服务更新；在 iOS 中——通过 iOS 更新。当链中任何一环被破坏（证书过期、域名不匹配、未知 CA）时，客户端断开连接。对于自签名证书（开发中使用），需要显式信任——在 Android 中通过网络安全配置，在 iOS 中通过 Info.plist 中的 NSExceptionDomains。证书链的验证过程还包括通过 CRL（证书吊销列表）或 OCSP（在线证书状态协议）检查吊销状态，尽管在移动设备上 OCSP 请求通常被跳过以加快连接速度——这是架构师需要权衡的安全性与性能之间的折衷。

SSL vs TLS：主要区别

虽然 SSL 和 TLS 这两个术语经常互换使用，但它们之间存在根本的技术差异，影响移动应用的安全性和性能。

TLS 1.3 与之前版本的主要区别——通过 ECDHE 协议强制使用完美前向保密（PFS）。这意味着即使攻击者获得了服务器的私钥，也无法解密先前拦截的流量。对于服务器入侵是真实威胁的移动应用，带 PFS 的 TLS 1.3 是强制性的安全要求。

旧版本的已知漏洞

过时版本的 SSL 和 TLS 存在已记录的漏洞，使其不适合生产使用。POODLE（CVE-2014-3566）通过填充预言机攻击 SSL 3.0，可在 256 个请求内解密会话 Cookie。BEAST（CVE-2011-3389）通过可预测的 IV 利用 TLS 1.0 在 CBC 模式下的漏洞。Heartbleed（CVE-2014-0160）——不是协议漏洞，而是 OpenSSL 实现中的错误，允许读取服务器内存：根据 Netcraft 的数据，2014 年有超过 50 万台服务器容易受到攻击。从 Android 10（API 29）和 iOS 13 开始，所有上述协议在系统级别被禁用。尽管如此，开发人员应在启动应用程序之前通过 SSL Labs 测试（qualys.com）检查服务器配置，以确保没有过时的密码套件并且支持 TLS 1.3。

SSL/TLS 如何保护移动应用中的数据

在移动应用中，TLS 在三个层面保护数据：内容加密（除服务器外无人能读取数据）、完整性检查（数据在传输过程中无法被修改）和服务器身份验证（客户端确信正在连接到正确的服务器）。身份验证尤为关键：没有它，攻击者可以通过 DNS 欺骗或伪造的 Wi-Fi 接入点冒充服务器。

根据 Google Play Protect（2024）的研究，76% 的 Android 应用正确使用 TLS 并验证证书。其余 24% 会犯错误：为测试禁用证书验证（并忘记在生产中启用）、使用未经验证的自签名证书或允许过时的 SSL 3.0 和 TLS 1.0 协议。Apple App Transport Security（ATS）在 iOS 中自 2017 年起要求至少 TLS 1.2，从 iOS 15 开始默认对所有网络请求使用 TLS 1.3。为了额外保护，还建议实施证书固定——绑定到特定的服务器证书。

在移动应用中实现 SSL/TLS

让我们看一个使用 OkHttp（最流行的网络库之一）在 Android 中配置安全 HTTPS 连接的示例。正确的配置包括强制使用 TLS 1.3 和证书验证。

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

在此示例中，我们将支持的 TLS 版本集限制为仅 1.3 和 1.2 协议，排除过时的 TLS 1.0/1.1。密码套件从具有 AEAD 模式和强制完美前向保密的现代算法中选择。HostnameVerifier 检查主机名与证书的匹配。对于 iOS，通过 URLSession 配置进行类似设置，参数为 tlsMinimumSupportedProtocolVersion，指定为 .TLSv13。此外，在 iOS 中还可以设置 tlsMaximumSupportedProtocolVersion 来限制版本上限——这对于与尚未迁移到 TLS 1.3 的旧服务器兼容很有用。这样的配置可确保移动应用中数据传输时的最大安全级别。