Closed martintoreilly closed 4 years ago
SCH_USE_STRONG_CRYPTO
For some cipher combinations, login fails with the following error:
:x: Login fails
✅ Login works
✅ Login works
Which ciphers are needed? Enabling any single one of the following ciphers (plus the recommended list) is enough
Name | Weaknesses |
---|---|
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
CBC |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
CBC, SHA1 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
CBC, SHA1 |
TLS_RSA_WITH_AES_256_CBC_SHA256 |
CBC |
TLS_RSA_WITH_AES_128_CBC_SHA256 |
CBC |
TLS_RSA_WITH_AES_128_CBC_SHA |
CBC, SHA1 |
Proposal
We should enable the recommended ciphers plus TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
; TLS_RSA_WITH_AES_256_CBC_SHA256
and TLS_RSA_WITH_AES_128_CBC_SHA256
.
This gives the following 11 supported ciphersuites
Proposal We should enable the recommended ciphers plus
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
;TLS_RSA_WITH_AES_256_CBC_SHA256
andTLS_RSA_WITH_AES_128_CBC_SHA256
.
I think there are concerns with using RSA
as the key exchange mechanism, so I would be more comfortable with just supporting TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
. It may be that the two specific `TLSRSAsuites combined with our RSA certificate parameters are not susceptible, but as we're looking at supporting secure connection between two parts of a system under our control and the
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256differs only in the mode of the AES symmetric cipher stage to the otherwise identical
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` suite, which is universally considered strong, it feels that supporting this single additional suite minimises our exposure to any potential weaknesses.
Edit: While reviewing the PR #848, I see there is a TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
suite. I think I'd prefer us to support only this suite if it works for RDS web app to gateway communication, as it maximises the strength of the AES cipher that uses the problematic CBC mode.
*
see articles recommending dropping RSA key exchange (noting that the R in RSA agrees), and describing the TLS 1.3 protocol (which drops support for RSA key exchange).
:scroll: Description
In July 2020, as part of the change to drop support for older TLS versions in PR #766, we limited the supported TLS cipher suites to remove all ciphers supported by Windows 2019 but not on the list at https://www.acunetix.com/blog/articles/tls-ssl-cipher-hardening/. This list resulted in the Qualys SSL Labs server test reporting no weak ciphers.
In October 2020, @jemrobinson experienced issues with connecting to a newly deployed SRE RDS server, with the error being due to a failure to find a common supported cipher suite between client and server (see issue #842). Note that this issue was only encountered when launching an RDS app, implying that the browser and server had successfully negotiated a common acceptable TLS cipher suite when securing the initial connection to the RDS web app but there was then a subsequent failure when the we app was negotiating a secure connection with the RDS Connection Broker endpoint.
Expanding the list of supported ciphers to those classed as recommended or strong by the Cipher Suite API (applied in PR #843) resolved the connection problem described in issue #842, but several of the ciphers classed as strong by the Cipher Suite API are classed as weak by Qualys SSL Labs test.
We'd like to determine a principled subset of commonly agreed non-weak ciphers that we can support, along with a principled (and ideally automated) way of ensuring this list remains up to date.
:strawberry: Desired behaviour
We have no issues connecting to RDS apps from the latest version of Chrome, Firefox, Edge, Safari on Windows, Mac or Linux while also ensuring that we don't support any cipher suite considered weak by Qualys SSL Labs, Cipher Suite or any other list we choose to rely on.
:page_facing_up: Tasks
Include specific tasks (if any) in the order in which they need to be done.
Initially labelled as medium security as I think having a defensible list of supported TLS ciphers that excludes ones with known issues forms part of our security accreditation.