应禁用sslv2/3、tls 1.0/1.1及含null/anon、md5/sha-1、弱密钥交换的套件；推荐tls_ecdhe_ecdsa/rsa_with_aes_256_gcm_sha384，java需配置jdk.tls.disabledalgorithms。
系统默认加密套件中常包含已知存在风险的旧协议（如SSLv2、SSLv3、TLS 1.0/1.1）和弱认证机制（如基于MD5、SHA-1签名的证书验证、匿名密钥交换等），直接启用可能引发中间人攻击或降级攻击。筛选需结合协议版本、密钥交换算法、认证方式、对称加密强度四方面综合判断，而非仅依赖“默认开启”状态。
识别当前启用的加密套件与协议
不同系统获取方式不同，但核心是查清实际运行时协商能力：
- Linux（OpenSSL后端）：执行 openssl ciphers -V 'ALL:COMPLEMENTOFDEFAULT' 查看全部支持套件及其协议版本、密钥交换、认证与加密字段；搭配 openssl s_client -connect example.com:443 -tls1_2 测试具体服务启用情况
- Windows（SChannel）：通过注册表 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols 检查各协议开关状态；用 Get-TlsCipherSuite（PowerShell 5.1+）列出系统级可用套件
- Java应用：查看 jdk.tls.disabledAlgorithms 和 jdk.tls.legacyAlgorithms JVM参数，或用 javax.net.debug=ssl:handshake 日志观察握手时真实协商结果
明确不安全协议与套件的剔除标准
以下类型应无条件禁用，不因兼容性妥协：
- 已废弃协议：SSLv2、SSLv3、TLS 1.0、TLS 1.1（NIST SP 800-52r2、PCI DSS 4.1、RFC 8996均已明确弃用）
- 无认证或弱认证套件：含 NULL（如 TLS_RSA_WITH_NULL_SHA）、anon（如 TLS_DH_anon_WITH_AES_128_CBC_SHA）的套件，无法验证服务端身份
- 弱哈希与签名算法：使用 MD5、SHA-1 进行证书签名或 PRF 的套件（如 TLS_ECDHE_RSA_WITH_RC4_128_SHA）
- 弱密钥交换：密钥交换强度低于 2048 位 RSA 或 224 位 ECC（如 TLS_RSA_WITH_3DES_EDE_CBC_SHA 使用 1024 位 RSA 密钥）
按场景配置安全优先的套件列表
禁用不安全项后，主动指定强套件比依赖“默认”更可控：
- 现代Web服务（推荐）：优先启用 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384，要求 P-256 或 P-384 曲线，禁用 CBC 模式套件
- 兼顾旧客户端（谨慎）：可保留 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，但必须关闭所有 TLS 1.2 以下协议，且不启用 SHA-1 签名证书
- Java 应用配置示例：启动参数加入 -Djdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, DH, EC keySize
验证剔除效果与持续监控
配置后必须验证是否真正生效，避免“看似禁用实则 fallback”：
- 用 testssl.sh example.com 全面扫描协议支持、套件排序、证书链及漏洞（如 ROBOT、LOGJAM）
- 检查服务器响应头中的 Strict-Transport-Security 是否启用，并确认其 max-age ≥ 31536000（1年）
- 在生产环境部署前，用真实客户端（含旧版Android/iOS、IE11等）做兼容性探活，记录失败原因而非盲目放宽策略
