Skip to content

ADR-105: Standardise support cipher suites and protocols

Context

Currently our services support different cipher suites and SSL/TLS protocols with no clear rationale behind them. Not only does this incoherence make it hard to audit whether the cipher suite and protocol choices have withstood the test of time, it also generates extra work with every new service that needs to make yet another decision on what to support.

Decision

We're switching to three sets of cipher suites and protocols, each applicable to specific security requirements. These should be reviewed every year as well as with the publication of every new cipher or protocol weakness.

While there is no current need to specify key exchange groups for TLSv1.3, this will need to be reconsidered on every review, especially if post-quantum becomes a requirement.

Standard

This is the standard set. It excludes all known weak cipher suites and ensures perfect forward secrecy. This should be used for everything requiring confidentiality and/or every service with a login.

- security requirements: confidentiality and integrity - protocols: - TLSv1.2 - TLSv1.3 - ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECCPWD_WITH_AES_128_GCM_SHA256 - TLS_ECCPWD_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 - TLS_AES_128_CCM_8_SHA256 - TLS_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_256_CCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CCM - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM - TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 - TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Public

This is a compromise of the standard set that supports the weak TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. As this cipher is mandatory to implement according to RFC5246, this will ensure compatibility with any client supporting TLSv1.2, including things like IE11 on Windows 7. It does not ensure perfect forward secrecy and may be vulnerable to timing attacks. While it can not ensure long-term confidentiality, there are no known attacks that would allow an attacker to inject malicious data, so the integrity can still be guaranteed. This set can be used for services that only require integrity, but do not serve anything confidential, such as public websites and software download pages.

- security requirements: integrity only - protocols: - TLSv1.2 - TLSv1.3 - ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECCPWD_WITH_AES_128_GCM_SHA256 - TLS_ECCPWD_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 - TLS_AES_128_CCM_8_SHA256 - TLS_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_256_CCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CCM - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM - TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 - TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA

Insecure legacy

This is a legacy and insecure set, which supports many old and insecure cipher suites. It aims at being compatible with every SSL/TLS client. In doing so, it does not even ensure encryption at all, but it will talk to just about any old machine out there.

This should only be used for services that also have plain text counterparts and where there is no reasonable expectation of confidentiality or integrity. Unauthenticated communication between mailservers is a current example, where we choose to favour deliverability over any pretense of confidentiality or integrity.

This is the public set, plus TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA, which are mandatory to implement according to RFC 2246 (TLS 1.0) and RFC 4346 (TLS 1.1), plus the RSA and Diffie-Hellman based suites mentioned in RFC 6101 (SSL 3.0), plus the suites mentioned in the draft specification of SSL.

- security requirements: none - protocols: - SSL2.0 - SSL3.0 - TLSv1.0 - TLSv1.1 - TLSv1.2 - TLSv1.3 - ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECCPWD_WITH_AES_128_GCM_SHA256 - TLS_ECCPWD_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 - TLS_AES_128_CCM_8_SHA256 - TLS_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_128_CCM_SHA256 - TLS_ECCPWD_WITH_AES_256_CCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CCM - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM - TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 - TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 - TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA - SSL_RSA_WITH_NULL_MD5 - SSL_RSA_WITH_NULL_SHA - SSL_RSA_EXPORT_WITH_RC4_40_MD5 - SSL_RSA_WITH_RC4_128_MD5 - SSL_RSA_WITH_RC4_128_SHA - SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - SSL_RSA_WITH_IDEA_CBC_SHA - SSL_RSA_EXPORT_WITH_DES40_CBC_SHA - SSL_RSA_WITH_DES_CBC_SHA - SSL_RSA_WITH_3DES_EDE_CBC_SHA - SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA - SSL_DH_DSS_WITH_DES_CBC_SHA - SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA - SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA - SSL_DH_RSA_WITH_DES_CBC_SHA - SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA - SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA - SSL_DHE_DSS_WITH_DES_CBC_SHA - SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA - SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - SSL_DHE_RSA_WITH_DES_CBC_SHA - SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA - SSL_CK_RC4_128_WITH_MD5 - SSL_CK_RC4_128_EXPORT40_WITH_MD5 - SSL_CK_RC2_128_CBC_WITH_MD5 - SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 - SSL_CK_IDEA_128_CBC_WITH_MD5 - SSL_CK_DES_64_CBC_WITH_MD5 - SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Consequences

Traffic (and notably credentials) on our forum, gitlab, etc. will be better protected against eavesdropping.

Users on Windows 7 / IE 11 may no longer be able to use our forum, gitlab, etc. Windows 7 user could still use chrome or firefox to access these. They would still be able to access the public website and download torbrowser using IE11.

Implementation

For coherent implementation of this ADR across all TPA managed services, the different suites and protocols for each level are codified in hiera (in data/common/ciphers.yaml). For each level, you will see multiple lines describing the cipher suites and protocols. That is because IANA, OpenSSL, and GnuTLS all have their own ideas on how cipher suites should be named. Defining protocols is even more chaotic and every application seems to have its own ideas about it, but we will still centralise this data in the common hiera. If during the yearly evaluation changes are made to the suites or protocols we want to support, you can implement these changes by modifying the hiera data in one single point.

All cipher suites mentioned above are named using their IANA name, so they can't be copypasted blindly. Luckily, the openssl-ciphers man page provides translations, so you can translate the lists here into openssl-compatible lists. GnuTLS names tend to be the same as the IANA names without the WITH. In practice, however, GnuTLS is configured with a priority string instead of a list of cipher suites. This priority string also defines which protocols are supported. You can craft a string and run gnutls-cli -l --priority=YOURSTRING to check if it results in the desired suites and protocols.

Finally, some libraries may not support all the cipher suites mentioned in this ADR. Feel free to simply omit the unsupported ones if specifying them breaks anything.

More information

More information on specific cipher suites can be found on https://ciphersuite.info/

Metadata