如何识别实际在用的TLS密码套件并评估禁用弱套件的影响

1. TLS连接信息的获取路径 #

• TLS握手产生的协议版本、协商密码套件等信息，应用层服务、负载均衡、反向代理等上层组件均可直接读取，不需要从底层网络栈单独采集。
• 针对Azure网关托管Qlik Sense的场景：直接开启Azure网关的访问日志功能即可，日志默认内置TLS版本、协商密码套件两个核心字段，无需修改Qlik Sense的服务配置。如果Qlik Sense为IIS部署，也可以在IIS日志的自定义字段中添加TLS相关属性，重启服务后即可生成对应记录。

2. 受影响客户端的统计方法 #

• 先开启7~14天的全量访问日志采集，按客户端IP、可关联的用户身份标识（如Qlik Sense登录账号）分组，统计使用非目标密码套件的请求占比：
  • 若占比低于0.1%，可认为影响范围极小，裁剪弱套件前单独通知对应用户升级客户端即可
  • 若占比更高，先定位异常客户端的类型，再评估裁剪可行性
• 若条件允许，可先在测试环境启用白名单密码套件，邀约内部核心用户做兼容性验证，提前规避业务风险。

3. 指定密码套件的不兼容范围 #

你选用的TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256属于现代TLS安全套件，仅老旧系统无法原生支持：

• Windows 7及更早版本的Windows系统（默认未开启TLS1.2，且原生不支持AES-GCM模式套件，手动安装系统补丁并开启TLS1.2后可兼容）
• Android 4.4及更早版本的原生系统
• 2016年之前发布的未升级嵌入式设备、工控终端
• IE8及更早版本的老旧浏览器

内容的提问来源于stack exchange，提问作者Vbakke