反之亦然,如何找出可用于特定版本的SSL / TLS协议的密码套件?这两个问题都暗示有约束,即任何密码套件都不适合任何协议版本。特别要指出的是,如果存在TLS 1.2合适密码的详尽列表。
这个问题可以改写为密码套件和协议版本之间的兼容性。
答案 0 :(得分:1)
这与编程无关,在这里有点偏离主题。但是,为什么要考虑除1.2或1.3之外的其他版本呢?
TLS 1.3的密码列表非常小,与以前的密码分开:
此规范定义了以下密码套件,可用于 TLS 1.3。
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
对于其他版本,像https://github.com/mozilla/cipherscan这样的工具可以帮助它显示密码以及密码适用的版本。
或者仅使用openssl ciphers
命令打开openssl,添加-s
参数,然后添加-tls1
,-tls1_1
或-tls1_2
。
如果您查看其手册,也有列表,请查看https://www.openssl.org/docs/manmaster/man1/ciphers.html
的底部在TLSv1.2中有很多可能使用的密码,但并非所有人都是一个好主意。有些人尝试维护良好参数的列表,例如参见https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations或https://weakdh.org/sysadmin.html
我还建议您考虑一下这项工作,以定义“长期支持” TLSv1.2,该规范是当前TLS版本1.2之上的规范,适用于不超过1.3的人群,该规范试图通过删除来提高安全性发现TLS v1.2中的所有内容都不是一个好主意,同时仍然100%符合TLS v1.2。
https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/?include_text=1
此文档指定了TLS 1.2的更新,以长期支持 系统可能具有多年甚至十年的更新周期, 尽可能整合已经部署的 TLS 1.2,但修复了安全漏洞和错误。
关于密码,它是这样说的:
TLS-LTS通过更多限制TLS或多或少限制无限的TLS 1.2 超过三百个密码套件,四十多个ECC参数集和
o必须支持TLS-LTS实现 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256和 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256。对于这些套房,SHA-256 用于协议中哈希函数所在的所有位置 是必需的,特别是在PRF和每个数据包的MAC计算中 (如套件中的_SHA256所示)以及客户端 和证书中的服务器和服务器签名 ServerKeyExchange消息。
补充算法,参数和参数格式的动物园,
只有两个,一个传统的,带DHE + AES-CBC + HMAC-SHA-256 +
RSA-SHA-256 / PSK和1个ECC,带有ECDHE-P256 + AES-GCM + HMAC-
具有未压缩点的SHA-256 + ECDSA-P256-SHA-256 / PSK:[Note: TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 is based on draft-ietf-tls-ecdhe-psk-aead, currently still progressing as an IETF draft, the reference will be updated to the full RFC once it's published].