买SSL证书的时候，商家页面上经常出现“256位加密”“银行级安全”这样的字眼。你点开证书详情，看到里面写着“公钥算法：RSA 2048位”，心里犯嘀咕：说好的256位呢，怎么变成2048位了?这两个数字指的不是同一个东西。

　　证书的“位数”和实际传输加密的“位数”是两回事。 2048位是证书里公钥的长度，属于非对称加密的范畴，用来做身份验证和密钥交换。而256位是TLS连接建立后，用来加密实际数据的对称密钥长度。浏览器和服务器握手时，先用证书里的公钥协商出一个临时对称密钥，之后的通信数据都用这个对称密钥加密。你访问网站时传输的密码、表单、支付信息，保护它们的是那个256位的对称密钥，不是证书里的2048位公钥。

　　搞清楚这个区别，才能理解“加密强度”到底该怎么看。

　　证书参数：看什么，不看什么

　　打开一张证书的详细信息，会看到几个关键字段。

　　公钥算法和密钥长度。 这是证书里最核心的密码学参数。当前的主流标准是RSA不低于2048位，或者ECC(椭圆曲线)不低于256位。ECC 256位的安全强度大致相当于RSA 3072位，但计算开销小得多，握手速度更快。证书链里的CA签名密钥同样有长度要求，如果中间证书用了1024位的RSA密钥，整条链的安全性都会被拖累。

　　签名算法。 证书本身是用CA的私钥签名的，签名用的哈希算法决定了“伪造证书”的难度。SHA-256是当前的标准底线，SHA-384或SHA-512更好。SHA-1已经被主流浏览器和CA淘汰，看到SHA-1签名的证书，基本可以判定是老旧的遗留系统。

　　但证书参数只是“入场券”。一张RSA 2048位的证书，如果服务器配置允许协商RC4或3DES这样的弱加密套件，实际连接的安全性可能远低于证书本身的标称强度。

　　协议版本：TLS 1.2和1.3的差距

　　TLS协议版本决定了“有哪些加密套件可以被选”。版本越新，可用的套件越干净。

　　TLS 1.2发布于2008年，支持的加密套件组合非常庞杂。它允许静态RSA密钥交换(没有前向保密)，允许CBC模式(存在Lucky 13等时序攻击的隐患)，允许RC4、3DES这些已经被证明有问题的算法。TLS 1.2本身不是“不安全”的，但它把太多选择权交给了配置者——配得好，安全性可以很高;配得差，就会留下一堆漏洞。

　　TLS 1.3发布于2018年，做了一次彻底的“减法”。它禁止了静态RSA密钥交换、RC4、CBC模式、SHA-1、MD5，以及所有不提供前向保密的套件。TLS 1.3的可选加密套件只剩五组，全部基于AEAD(认证加密)模式。握手过程也做了精简：TLS 1.2需要两次往返(2-RTT)才能完成握手，TLS 1.3压缩到一次往返(1-RTT)，甚至支持0-RTT的会话恢复。

　　对于“加密强度”这件事，TLS 1.3的核心价值在于消灭了弱选项。在TLS 1.2上，你有可能因为兼容性考虑而保留了一个弱套件，攻击者就可以利用它做降级攻击。在TLS 1.3上，弱套件根本不存在，降级攻击的入口被堵死了。

　　加密套件：读懂那串“暗号”

　　加密套件的名字看起来像密码，其实结构很清晰。以TLS 1.2时代的经典套件为例：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

　　拆开看四段：

　　ECDHE —— 密钥交换算法。ECDHE是“椭圆曲线临时Diffie-Hellman”，临时意味着每次握手都生成一对新密钥，用完就丢。这提供了前向保密：即使服务器私钥日后泄露，攻击者也无法解密之前录下的历史通信。RSA密钥交换(没有ECDHE前缀的套件)不具备这个特性，NIST已不再推荐使用。

　　RSA —— 身份验证算法。服务器用RSA证书证明自己的身份。如果证书是ECC的，这里会显示ECDSA。

　　AES_256_GCM —— 数据加密算法。AES是对称加密，256是密钥长度，GCM是工作模式。GCM属于AEAD模式，同时提供加密和完整性校验，比CBC模式安全得多。AES-128-GCM和AES-256-GCM在安全强度上差距不大，256位提供更长的安全边际，128位在性能上略有优势。

　　SHA384 —— 哈希算法，用于消息认证。SHA384比SHA256更长，但两者在当前算力下都足够安全。真正需要警惕的是SHA-1和MD5。

　　TLS 1.3的套件命名更简洁，比如 TLS_AES_256_GCM_SHA384。因为TLS 1.3把密钥交换和身份验证的算法从套件名称中剥离了，所有套件默认使用ECDHE做密钥交换，默认提供前向保密。你只需要看数据加密部分：AES-GCM还是ChaCha20-Poly1305，128位还是256位。

　　怎么验证：从在线工具到命令行

　　搞清楚该看什么之后，验证一台服务器的实际加密强度有几种方式。

　　在线工具是最快的。Qualys SSL Labs的测试会给出A到F的评级，同时列出服务器支持的协议版本、加密套件列表、证书链状态。一个配置良好的站点应该拿到A或A+，并且只在TLS 1.2和1.3上响应。

　　命令行适合需要精确排查的场景。用 nmap 的 ssl-enum-ciphers 脚本可以枚举服务器支持的所有加密套件，输出里会标注哪些套件被归类为“weak”或“insecure”。

　　openssl s_client 可以测试特定协议版本是否可用。尝试连接TLS 1.0或1.1，如果服务器拒绝了，说明旧协议已经被禁用。

　　有一个容易被忽略的细节：服务器配置的加密强度，取决于它“支持的最弱那个套件”，而不是最强的。如果一台服务器同时支持AES-256-GCM和一个老旧的3DES套件，攻击者可以选择3DES来协商连接。所以检查时不能只看“有没有强套件”，还要看“有没有弱套件被启用了”。

　　配置建议

　　如果只记一条原则：优先TLS 1.3，TLS 1.2作为兼容性兜底，但确保1.2只保留ECDHE + AES-GCM或ChaCha20的套件。

　　具体到Nginx的配置，ssl_protocols 应该只写 TLSv1.2 TLSv1.3。ssl_ciphers 的列表应该以 ECDHE 开头的套件为主，用 !aNULL:!MD5:!3DES 明确排除已知的弱算法。

　　ChaCha20-Poly1305在移动设备上值得关注。很多手机没有AES硬件加速，用AES-GCM做加密会消耗更多CPU，影响续航和响应速度。ChaCha20是纯软件实现的流密码，在移动端效率更高。一套好的配置会在套件优先级里给ChaCha20留一个位置。

　　证书本身的选择反而不用过度纠结。RSA 2048或ECC P-256都是合格的“达标线”，NIST的指南明确要求DH参数至少2048位，RSA签名密钥至少2048位。追求RSA 4096位带来的边际安全收益很小，握手开销却明显增加，老旧客户端还可能不支持。把精力花在“套件干净”上，比花在“密钥更长”上更有价值。