最近做安全扫描，报告里经常会出现一句话：TLS 版本过低。

有的报告还会把它写成 TSL，或者直接写成 SSL 版本过低。名字一多，很多人就开始迷糊了。

到底是证书有问题？

还是 HTTPS 配置有问题？

TLS、SSL 和 HTTPS 到底是什么关系？

这篇把这几个概念捋一遍。之前我已经写过一篇图解 HTTPS 的握手交互过程，那篇重点放在握手消息怎么交互，这一篇则把视角往前拉一点，聊聊协议版本为什么会演进，以及扫描提示“版本太低”时我们到底该改什么。

先纠正一个拼写：正确的是 TLS，不是 TSL。

SSL 和 TLS 到底是什么

SSL 的全称是 Secure Sockets Layer，TLS 的全称是 Transport Layer Security。

它们都是用来保护网络通信的安全协议，主要解决三件事：

• 加密：别人即使截获了数据，也不能直接看懂内容
• 身份认证：客户端可以确认自己连接的确实是目标服务器
• 完整性校验：数据在传输过程中被修改，通信双方能够发现

可以把它理解成两个人在不安全的街道上通信。

加密是把聊天内容装进别人打不开的盒子里，身份认证是确认对面不是冒牌的，完整性校验则是确认盒子送到之后没有被偷偷换过内容。

SSL 是早期的名字，TLS 是后续标准化、演进后的名字。

今天我们口头上还经常说“SSL 证书”“SSL 加密”，但真实连接大多数已经使用 TLS。

所以现在再说“配置 SSL”，很多时候实际指的是配置 TLS 协议和服务器证书。

SSL 1.0        未公开使用
    ↓
SSL 2.0        1995，已经废弃
    ↓
SSL 3.0        1996，已经废弃
    ↓
TLS 1.0       1999，已废弃
    ↓
TLS 1.1       2006，已废弃
    ↓
TLS 1.2       2008，仍被广泛支持
    ↓
TLS 1.3       2018，当前更推荐
​

这里的箭头不是说旧版本升级后还能继续兼容所有能力，而是表示协议标准不断替代前一代。

SSL 2.0、SSL 3.0 现在都不应该再开启。

TLS 1.0 和 TLS 1.1 也已经进入淘汰范围，安全扫描提示“TLS 版本过低”，大概率就是发现服务器仍然允许这些旧版本连接。

HTTPS 和 TLS 是什么关系

HTTPS 并不是一个和 TLS 平行的加密协议。

HTTPS 可以直接理解成：HTTP 加上 TLS 保护。

普通 HTTP 大致是这样：

浏览器  ─────── 明文 HTTP 请求 ───────>  Web 服务器
        <────── 明文 HTTP 响应 ───────
​

中间经过代理、路由器、运营商网络时，理论上都可能看到请求内容。

HTTPS 则多了一层 TLS：

浏览器
   │
   │  HTTP 请求
   ▼
 TLS 加密层
   │
   │  加密后的 TLS 数据
   ▼
 TCP 连接
   │
   ▼
 Web 服务器
​

从网络分层角度看，可以粗略表示为：

HTTPS = HTTP + TLS

应用层：        HTTP
安全层：        TLS
传输层：        TCP
网络层：        IP
​

HTTP 负责“传什么”，TLS 负责“怎么安全地传”。

所以安全扫描检查 HTTPS 时，通常不只看网页能不能打开，还会继续检查：服务器支持哪些 TLS 版本、允许哪些密码套件、证书是否可信、是否存在弱算法和错误配置。

TLS 握手做了什么

这里不再把握手过程完整展开，详细交互可以看前面那篇 HTTPS 握手文章。

我们只抓住版本问题最相关的几个动作。

客户端                                      服务器
   │                                           │
   │  ClientHello：支持的 TLS 版本、随机数      │
   │──────────────────────────────────────────>│
   │                                           │
   │  ServerHello：选中的版本、密码套件、证书    │
   │<──────────────────────────────────────────│
   │                                           │
   │  校验证书、协商密钥                         │
   │  后续使用会话密钥加密通信                   │
   │<══════════════ 加密 HTTP 数据 ════════════>│
​

客户端会告诉服务器：“我支持这些协议版本和密码套件。”

服务器从中选一个自己也支持的组合。

如果服务器仍然允许 TLS 1.0，那么一个支持 TLS 1.0 的客户端就可能和它协商出 TLS 1.0。

这就是旧版本风险的来源：服务器为了兼容老客户端，开放了已经不推荐的协议版本。

注意，证书不是 TLS 版本。

证书主要用于身份认证和公钥交换相关流程，TLS 版本决定的是双方采用哪一代安全协议。

一张证书可能被 TLS 1.2 和 TLS 1.3 共同使用，也可能证书没过期，但服务器协议配置仍然很老。

TLS 版本经历了什么

SSL 时代的问题

SSL 2.0 和 SSL 3.0 已经不能作为现代安全配置使用。

它们的问题不只是“版本号老”，而是协议设计和密码算法选择已经跟不上现在的攻击能力。

其中 SSL 3.0 曾经受到 POODLE 等攻击影响，继续保留它没有实际价值，只会扩大攻击面。

所以现在看到配置里有 SSLv3，不要想着“先留着兼容一下”，通常应该直接关闭。

TLS 1.0 和 1.1

TLS 1.0 和 TLS 1.1 比 SSL 新，但现在也已经不适合继续作为对外服务的协议版本。

常见问题包括：

• 默认设计年代较早，对现代密码算法和加密实践支持不足
• 依赖较老的密码套件和加密模式
• 很多浏览器、云厂商和安全基线已经停止支持
• 为了兼容它们，服务器往往还会顺手开启更多弱算法

这里要注意一个常见误区：关闭 TLS 1.0 和 TLS 1.1，不等于 HTTPS 不能用了。

现代浏览器、移动端和主流 SDK 通常都支持 TLS 1.2，很多还支持 TLS 1.3。

真正可能受影响的，主要是非常老的客户端、老操作系统或多年没有升级的设备。

TLS 1.2

TLS 1.2 是目前仍然非常常见的一代版本。

它的生态成熟，兼容性好，很多旧系统即使不支持 TLS 1.3，也能正常使用 TLS 1.2。

但支持 TLS 1.2 也不代表配置一定安全。

如果同时开启了弱密码套件、过时的哈希算法或不安全的密钥交换方式，扫描仍然可能报风险。

所以检查 TLS 1.2 时，不能只看版本号，还要看密码套件配置。

TLS 1.3

TLS 1.3 是更新的一代协议，重点改进了握手速度和默认安全性。

它删除或禁用了很多历史包袱，握手交互也比以前更精简。

大致可以这样理解：

TLS 1.2：兼容项较多，配置空间大，也更容易配出弱组合
TLS 1.3：删除大量旧选项，默认安全边界更清晰，握手更快
​

TLS 1.3 并不意味着完全不需要 TLS 1.2。

如果系统还需要兼容一部分旧客户端，比较常见的做法是同时开放 TLS 1.2 和 TLS 1.3，而不是继续开放 TLS 1.0 和 TLS 1.1。

一个比较实际的基线通常是：最低 TLS 1.2，优先 TLS 1.3。

具体还要结合业务的客户端范围、操作系统版本和中间设备能力确认。

扫描提示版本太低怎么看

安全扫描说“TLS 版本太低”，先别急着改配置文件。

我们要先确认它到底扫到了什么。

先确认告警对象

同一个域名背后可能有多层入口：

• CDN 或云负载均衡
• WAF 或 API 网关
• Nginx、Apache、Ingress
• Java、Go、Node.js 等应用服务
• 内网反向代理或老旧设备

你以为改的是应用服务器，扫描实际命中的可能是最外层的 CDN。

也可能外层已经只开放 TLS 1.2，但内网某个端口仍然开放 TLS 1.0，扫描扫的是另一个地址。

所以第一步是确认：域名、端口、IP、证书和扫描报告中的服务是否对应。

用工具验证实际支持的版本

可以用 openssl s_client 分别测试某个版本。

# 测试 TLS 1.0
openssl s_client -connect example.com:443 -tls1

# 测试 TLS 1.1
openssl s_client -connect example.com:443 -tls1_1

# 测试 TLS 1.2
openssl s_client -connect example.com:443 -tls1_2

# 测试 TLS 1.3
openssl s_client -connect example.com:443 -tls1_3
​

如果旧版本还能成功完成握手，说明服务器确实还开放着它。

也可以用 nmap 的脚本查看协议和密码套件：

nmap --script ssl-enum-ciphers -p 443 example.com
​

注意，命令能否执行成功还取决于本机 OpenSSL、nmap 版本和服务端配置。

工具结果是定位依据，不要只凭浏览器地址栏那把小锁判断。

区分版本告警和密码套件告警

这两个问题经常一起出现，但不是一回事。

协议版本：TLS 1.0 / TLS 1.1 / TLS 1.2 / TLS 1.3
密码套件：ECDHE_RSA_AES_128_GCM_SHA256 等组合
证书：域名、有效期、签发机构、公钥算法
​

协议版本过低，重点看 ssl_protocols 或类似配置。

密码套件过弱，重点看 ssl_ciphers、加密算法和密钥交换配置。

证书有问题，则检查域名匹配、证书链、有效期和签发机构。

不要看到 SSL 这个词就把三类问题混成一个问题。

Nginx 怎么配置

以 Nginx 为例，现代配置通常至少应该关闭 TLS 1.0 和 TLS 1.1，只保留 TLS 1.2 与 TLS 1.3：

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    # 只允许现代协议版本
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
    }
}
​

改完不要直接重启生产服务，先检查配置：

nginx -t
​

确认通过后，再按发布流程 reload：

systemctl reload nginx
​

如果前面还有 CDN、负载均衡或网关，这段配置只是其中一层。

真正对外提供 TLS 的设备，才是需要修改的地方。

不同 Nginx、OpenSSL 版本对 TLS 1.3 的支持也不完全一样，配置前要先确认运行环境。

应用代码里的 TLS 配置

如果是 Go 服务直接监听 HTTPS，可以显式设置最低版本：

server := &http.Server{
    Addr: ":443",
    TLSConfig: &tls.Config{
        // MinVersion 表示不接受低于 TLS 1.2 的连接
        MinVersion: tls.VersionTLS12,
    },
}
​

Java、Node.js、Tomcat、Spring Boot 等也都有对应配置项。

原则是一样的：找到真正终止 TLS 的那一层，设置最低协议版本，再用外部工具验证实际效果。

升级时别忘了兼容性

关闭旧版本一般是正确方向，但生产环境不能只改一行配置就结束。

建议按下面的顺序来：

1. 盘点客户端、设备和第三方调用方，确认是否有老旧系统
2. 在测试环境关闭 TLS 1.0 和 TLS 1.1
3. 用真实业务客户端回归登录、支付、回调、文件上传等关键流程
4. 用 OpenSSL、nmap 或扫描平台复查协议版本和密码套件
5. 观察错误日志和连接失败率，再在生产环境发布

特别是一些嵌入式设备、老版本 Android、老 Java 运行时，它们可能不像现代浏览器一样自动支持 TLS 1.2。

如果确实有无法升级的客户端，别为了它把整个公网入口降回 TLS 1.0。

可以考虑单独隔离兼容入口、升级客户端，或者通过网关做受控过渡。

安全配置最怕“一刀切”和“为了兼容什么都开”。

小结

把这几个概念放在一起，关系其实很清楚：

• SSL 是 TLS 的前身，SSL 2.0 和 SSL 3.0 都不应该继续使用
• TLS 是负责通信加密、身份认证和完整性校验的安全协议
• HTTPS 就是 HTTP 运行在 TLS 保护之下
• 证书 不等于 TLS 版本，证书有效也不代表协议配置安全
• 安全扫描提示版本太低，通常要检查服务器是否仍开放 TLS 1.0 或 TLS 1.1
• 现代服务一般以 TLS 1.2 作为最低版本，并优先支持 TLS 1.3

一句话总结：别被“SSL 证书”这个叫法带偏，真正要检查的是 TLS 协议版本、密码套件和证书配置三件事。

下次再看到“TSL 版本过低”的扫描提示，先把它改正成 TLS，然后确认扫描入口，测试实际支持的协议版本，再决定改 Nginx、网关还是应用服务。

不要只在配置文件里自我感觉良好，工具测出来的结果才算数。