非对称加密在TLS握手中扮演什么角色？
说实话，每次面试问到这个问题，我都能看到不少候选人卡壳。他们知道非对称加密比对称加密慢，但具体在TLS握手里到底干了什么，讲不清楚。嗯，这其实是个核心问题。
我个人习惯把非对称加密在TLS握手中的角色，总结成两个词：身份验证和密钥交换。说白了，它解决的是“我怎么相信你是你”和“我们怎么安全地商量一个共同密码”这两个问题。
核心记忆点：非对称加密在TLS1.2及之前的握手中，至少承担了“验证服务器身份”和“保护预主密钥传输”两项关键任务。在TLS1.3中，它依然是密钥协商的基石。
非对称加密的两大职责
你想想看，如果纯用对称加密，双方连密钥都没商量好，怎么加密通信？这就陷入死循环了。非对称加密就是用来打破这个死循环的。
- 职责一：身份验证——通过数字证书和签名，证明服务器（或客户端）确实持有对应的私钥。我在项目中遇到过有人直接把自签名证书扔到生产环境，结果客户端一直报证书错误，排查了半天才发现是证书链没配全。
- 职责二：密钥交换——协商出一个只有通信双方知道的对称密钥（会话密钥）。这个过程中，非对称加密用来保护“预主密钥”或者参与“密钥协商参数”的签名。
我的避坑经验：曾经有一次，团队为了优化握手速度，把RSA密钥长度从2048位降到了1024位。结果安全扫描直接报了高危漏洞。别在这种地方省性能，真的不值得。
从RSA到ECDHE：我经历的演进
我记得刚入行那会儿，TLS握手基本就是RSA的天下。客户端用服务器证书里的公钥加密一个随机数，服务器用私钥解密，双方就有了共同的预主密钥。流程简单，但有个致命问题。
| 特性 | RSA密钥交换 | ECDHE密钥交换 |
|---|---|---|
| 前向安全性 | 不支持。私钥泄露，所有历史会话可解密 | 支持。即使私钥泄露，历史会话依然安全 |
| 密钥交换方式 | 客户端生成预主密钥，用公钥加密传输 | 双方用椭圆曲线Diffie-Hellman协商密钥 |
| 服务器私钥用途 | 用于解密预主密钥 | 仅用于签名协商参数 |
| 性能 | 慢（尤其RSA解密） | 较快（ECDHE计算） |
| 现代推荐 | 不推荐。已有多起漏洞 | 强烈推荐。TLS1.3强制使用 |
为什么说RSA没有前向安全性？你想象一下：攻击者现在没法解密你的通信，但他可以把加密流量全部存下来。等哪天你的服务器私钥泄露了，他就能把以前存的所有流量都解密。这就是我常说的“今天录下来，明天解密”。ECDHE就解决了这个问题——每次握手用的临时密钥都是独立的，私钥泄露只影响将来的通信，不影响过去。
警告：千万不要在TLS配置里只开RSA密钥交换套件。我曾经帮一个银行客户做安全审计，发现他们的TLS服务器只支持TLS_RSA_WITH_AES_128_CBC_SHA。这相当于大门上只挂了一把锁，钥匙还插在外面。
握手流程中非对称加密的具体工作
我画了一张图，把这个流程串起来。你跟着走一遍，就清楚了。
从上图你能看到，非对称加密主要集中在前半段握手。客户端拿到服务器证书后，首先验证证书上的签名——这个签名就是服务器用私钥对证书内容算出来的。如果验证通过，说明这个证书确实是证书颁发机构（CA）颁发给这个服务器的。嗯，这里要注意，证书链的根证书必须是信任的，否则浏览器会报警。
面试里最容易被追问的几个点
我当过很多次面试官，下面这几个坑，几乎每轮面试都会有人踩。你提前准备好，面试时就能稳住。
- “非对称加密比对称加密慢，为什么还要用？”
这个问题其实是在考你对TLS设计哲学的理解。我的回答思路是：非对称加密只用在握手阶段，只加密几个字节的关键数据（预主密钥或签名）。握手完成后，我们就用对称加密来加密大量数据。这叫“用昂贵的工具开锁，用便宜的工具锁门”。 - “RSA密钥交换到底哪里不安全？”
说白了就是没有前向安全性。我曾经在技术分享时打个比方：RSA就像你把家门钥匙放在门口的脚垫下，今天没人偷，不代表明天没人偷。ECDHE则是每次都用新钥匙，旧钥匙丢了也不影响以前的房间。 - “量子计算机会彻底摧毁非对称加密吗？”
这是个好问题。目前来看，RSA和ECC在量子计算机面前确实不安全。但TLS协议已经在推进后量子密码（PQC）的标准化。我建议你现在面试时可以说：“传统非对称加密面临量子威胁，但TLS 1.3已经开始兼容混合密钥协商方案，比如结合传统ECDHE和基于格的加密。”
面试加分回答模板：非对称加密在TLS握手中有两个核心角色。第一，通过数字证书和签名实现服务器身份验证，防止中间人冒充。第二，通过密钥交换机制（如ECDHE）协商出一个临时的对称密钥，确保后续通信的机密性和前向安全性。这两个角色缺一不可，也是TLS协议安全性的基石。
实际项目中的选择建议
我建议你在配置TLS时，优先选择基于ECDHE的密码套件。比如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。ECDHE提供前向安全性，AES-GCM是认证加密模式，性能和安全都兼顾。
如果你用的是TLS 1.3，就不用操这个心了——它已经把RSA密钥交换彻底移除了，只支持基于ECDHE或DHE的密钥协商。TLS 1.3的设计者跟我思路一致：不安全的选项干脆别给。
一个小技巧：检查你的TLS配置可以用 openssl ciphers -v 'ECDHE:!RSA' 命令，看服务器支持哪些密码套件。我曾经帮一家电商公司用这个命令发现他们还开着过时的RC4套件。删掉之后安全评分直接涨了30分。
面试官如果问你“非对称加密在TLS握手中的角色”，能说出身份验证和密钥交换这两点，再结合前向安全性展开讨论，基本就能拿到不错的分数了。记住，别只背书，带上你的理解和实际经验，效果会好很多。