14 | 优化TLS/SSL性能该从何下手？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
TLS/SSL协议在保障应用层消息安全的同时，可能会降低性能和用户体验。为了优化TLS性能，需要考虑对称加密算法的性能优化和高效协商密钥两个方向。现代对称加密算法如AES在性能和安全性上表现优秀，而对密钥长度的选择会影响性能和安全性。此外，分组密码工作模式也是影响AES性能的因素，因此应选择可以并行计算的GCM分组模式。另外，对于CPU支持AES-NI指令集的情况，应选择AES算法以提升性能。除了对称加密算法的优化，还需要关注密钥的传递方式。因此，优化TLS性能需要综合考虑加密算法、密钥长度、分组模式以及硬件支持等因素。 TLS1.3对性能的提升主要体现在将握手时间从2个RTT降为1个RTT，同时限制了不再安全的算法，难以用降级攻击来破解密钥。因此，升级到TLS1.3是提升性能和安全性的重要举措。此外，文章还提到了使用长连接来复用会话、session缓存和session ticket等方式来减少密钥协商次数，但需要注意它们的安全性和防御重放攻击的难度。对称加密算法的选择、密钥长度、分组模式以及硬件支持等因素都对TLS性能有影响，因此需要综合考虑。 总的来说，优化TLS性能需要综合考虑加密算法、密钥长度、分组模式以及硬件支持等因素，并且尽快升级到TLS1.3是提升性能和安全性的重要举措。同时，密钥协商的次数、会话复用等方面也是优化TLS性能的关键点。
《系统性能调优必知必会》，新⼈⾸单¥59
全部留言(14)
- 最新
- 精选
明翼老师我在另一本书上看DH算法不是前向安全算法动态DH算法或ECDH算法才是前向安全的作者回复: 是的明翼，Diffie-Hellman算法其实有很多种实现，如同文稿中的图里，如果每次解密协商p、g、a、b都是重新生成的，那么这就具有前向保密性，此时Diffie-Hellman算法也叫Ephemeral Diffie-Hellman，除此以外，还有一些Diffie-Hellman算法会出于性能等因素考虑，重复使用一些参数，比如static Diffie-Hellman算法就不具备前向保密性。
2020-08-034
Bourne当然，用 Chrome 浏览器配合 Wireshark 可以解密消息，帮助你分析 TLS 协议的细节（具体操作方法可参考《Web 协议详解与抓包实战》第 51 课）。严重怀疑老师在给自己打广告哇，点过去一看，干货这么多，又买了，哈哈哈。不过话说回来，老师的课程质量真的很高，《Nginx核心知识100讲》还没学完，到100节左右了（其实有150讲），学到了很多，从Nginx小白到写Nginx配置信手拈来（吹个牛逼），谢谢老师的付出。作者回复: ^_^
2020-08-073
妥协所以TLS1.3可以放重放攻击吗作者回复: 0RTT下，有重放攻击风险。1RTT下是安全的。
2020-08-072
Geek_007陶辉老师你好，我有一个问题一直很困惑，希望能解答一下，感谢。TLS的record size 是16KB，Nginx 上有 ssl_buffer_size 参数，这个参数也会设置死 record size。如果没有像cloudflare一样做了动态tls record 的话 ，就是说TLS的record size是固定的16KB，但是假设TLS建联后每次只发1k的数据，不够16k。那么对端该如何处理呢？是等待？还是说发送发现发送的数据不够16K，就填充？如果等待会造成时延问题，如果填充会造成发送的数据总是过大。所以不知道这个 record size 为16 字节怎么理解。哦，对了，大部分Nginx都没有做动态TLS record size 吧，我是参考 https://blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency/ 这篇文章才有这个疑惑的。希望讨论老师有空闲之余解答一下。作者回复: 因为TCP的MSS远小于16KB，比如为1500字节，这样接收方收到record length为16KB时，就必须在接收到多个TCP报文总数为16KB时，才能执行解密这个分段，因此及时性就会差一些。所以cloudflare的动态record size，主要是为了接收方的响应速度更快一点。 当然，如果TCP MSS大于record size，就会降低吞吐量，因为报文头部的关系，有效信息比就会降低。
2020-07-071
冬风向左吹请问老师，我在nginx配置中，不管ssl_certificate和ssl_certificate_key是否配置ecc证书，抓包查看服务器的server hello响应中的Cipher Suite字段都是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，这是正常的吗？作者回复: 你好东郭，这是正常的，TLS握手阶段Nginx的Cipher Suite，要通过ssl_ciphers 指令来配支持的suites，并可通过ssl_prefer_server_ciphers指定优先选用的算法。 证书只是包含了密钥、身份等信息，它们与密钥协商方式、对称加密算法并无关系。
2020-05-301
董永刚TCP三次握手过程中传递公钥，会被黑客拦截到吗，被拦截后就可以获取到公钥信息？作者回复: 不会，公钥即使被黑客拦截到，黑客也无法基于公钥反推出私钥，以及猜出后续对称加密的密钥，原因参见这里：https://time.geekbang.org/course/detail/100026801-109888 另外，通常TCP三次握手后才能传递公钥，只有TCP Fast Open时才能在三次握手过程中传递公钥
2021-04-19
J.Smile读了两遍，其义自见。谓读得熟！come on!作者回复: ^_^
2020-07-03- Geek_007TLS1.3 感觉其实也不是优化特别大，TLS1.2 有False Start，也能做到1RTT，至于0RTT，现在主流的CDN应该也还有很多厂家不支持PSK，所以0RTT的效果也不一定好。 课后题： 1、ECC证书应该算是一种优化，因为证书更小，加解密更快。（不过好像因为客户端公钥太长，对客户端不友好，尤其是移动端） 2、算法分离、使用硬件加速卡代理计算。可以极大减轻接入层压力。 3、去掉证书链中的根证书（证书链太长可能会导致多一个RTT，毕竟TCP还在慢启动） 4、还是保持连接吧、减少连接次数。 5、客户端的session ticket 持久化，之前都是提到的服务端的session ticket，但是客户端如果是浏览器或者APP，因为重新打开等操作导致重新建立链接，应该会清空保存的会话票据，服务端即便有票据也没有用了。（个人理解，不正确的话请老师指正）2020-05-2918
我来也最近就遇到过tls协议版本的问题，不过我们是在开倒车。😂 最近升级到k8s后，默认的ingress nignx只支持tls1.2以上的版本，导致某些安卓5.x版本上的app无法与服务器正常通讯，为了兼容这部分用户，只能强制把tls支持的最低版本号调回到1.0。2020-05-2946
斯蒂芬.赵老想想问一下再nginx里配置tls选项时候，设置了选项 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; 这个选项是从网上随便复制的，目前部分河南的用户安卓手机访问我们的app，报网络错误的问题，我们后台看安卓的上报日志显示：connect reset ，是因为客户端不支持这个加密套件导致的么？这个选项需要设置么？有啥影响?2023-04-23归属地：美国
