Reputation: 746
Or vice versa, how to find out which cipher suites can be used for a certain version of SSL/TLS protocol? Both questions imply there are constraints, ie that any cipher suite is not suitable for any protocol version. In particular, I would like to be pointed out at the exhaustive list of suitable ciphers for TLS 1.2, if there is one.
The question may be rephrased as compatibility between cipher suites and protocol versions.
Upvotes: 0
Views: 825
Reputation: 12515
This is kind of offtopic here as not related to programming. But why concerning yourself about other versions than 1.2 or 1.3?
TLS 1.3 has a very small list of ciphers, separate from all previous ones:
This specification defines the following cipher suites for use with 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} |
+------------------------------+-------------+
For other versions, a tool like https://github.com/mozilla/cipherscan can help it shows ciphers and which version they apply to.
Or just openssl with the openssl ciphers
command, adding the -s
parameter and then -tls1
, -tls1_1
or -tls1_2
.
If you look at its manual you also have lists, look at bottom of https://www.openssl.org/docs/manmaster/man1/ciphers.html
There are a lot of possible ciphers to use in TLSv1.2 but not all are a good idea. Some people try to maintain lists of good parameters, see for example https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations or https://weakdh.org/sysadmin.html
I also recommend you to look at this effort to define a "Long Term Support" TLSv1.2 that is a specification on top of current TLS version 1.2 for people that will not more to 1.3, that tries to improve security by removing everything from TLS v1.2 that was found not to be a good idea, while still being 100% TLS v1.2 conformant.
https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/?include_text=1
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed.
About ciphers it has this to say:
TLS-LTS restricts the more or less unlimited TLS 1.2 with its more
than three hundred cipher suites, over forty ECC parameter sets, and
zoo of supplementary algorithms, parameters, and parameter formats,
to just two, one traditional one with DHE + AES-CBC + HMAC-SHA-256 +
RSA-SHA-256/PSK and one ECC one with ECDHE-P256 + AES-GCM + HMAC-
SHA-256 + ECDSA-P256-SHA-256/PSK with uncompressed points:o TLS-LTS implementations MUST support TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. For these suites, SHA-256 is used in all locations in the protocol where a hash function is required, specifically in the PRF and per-packet MAC calculations (as indicated by the _SHA256 in the suite) and also in the client and server signatures in the CertificateVerify and ServerKeyExchange messages.
[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].
Upvotes: 1