feat: Use recommended ELB security policy

[marsavar]

What does this change?

This PR ensures that when creating a GuEc2App, the listener (i.e. the process listening for connection requests on the load balancer) uses the security policy recommended by AWS, i.e. ELBSecurityPolicy-TLS13-1-2-2021-06.

This is the policy recommended by AWS, as it supports TLS 1.3, but it's also backward-compatible with 1.2. It also explicitly does not fall back to 1.1.

Looking at data from Cloudquery, the vast majority of our load balancers use an older default policy (ELBSecurityPolicy-2016-08) that defaults to 1.2. This PR makes 1.3 the default, but also preserves support for 1.2.

For completeness, I have added a table at the end of the PR which includes all the ciphers supported by the security policy included in this PR.

How to test

You can try and use curl on the DNS name of a load balancer specifying which TLS version to use for the connection.
E.g. Connecting to a load balancer with SSL policy ELBSecurityPolicy-2016-08 (old) using TLS 1.2, the connection should succeed:

curl -v -k --tlsv1.2 --tls-max 1.2 https://<ELB DNS name>

[...]
* Connected to <redacted>.eu-west-1.elb.amazonaws.com (<redacted>) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / secp256r1 / rsaEncryption
[...]

Using TLS 1.3 to connect to a load balancer with SSL policy ELBSecurityPolicy-2016-08 (old), the connection attempt should fail.

curl -v -k --tlsv1.3 --tls-max 1.3 https://<ELB DNS name>
[...]
* Connected to <redacted>.eu-west-1.elb.amazonaws.com (<redacted>) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, close notify (256):
* OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to <redacted>.eu-west-1.elb.amazonaws.com:443
* Closing connection
curl: (35) OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to <redacted>.eu-west-1.elb.amazonaws.com:443
[...]

On the other hand, using TLS 1.3 to connect to a load balancer with SSL policy ELBSecurityPolicy-TLS13-1-2-2021-06 (latest recommended security policy), the connection attempt will succeed:

curl -v -k --tlsv1.3 --tls-max 1.3 https://<ELB DNS name>

* Connected to <redacted>.eu-west-1.elb.amazonaws.com (<redacted>) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS

Forcing TLS v1.2 will also succeed as the latest security policy is backward-compatible.

How can we measure success?

Compliance with more recent standards. Better security.

Have we considered potential risks?

Potential risks include clients no longer being able to connect to our services.
Our public-facing services, however, are behind Fastly, and our current configuration does not support 1.1 anyway (I also don't think frontend is currently using GuCDK, but correct me if I'm wrong). You can check the SSL report here as proof that 1.1. is not supported.

For our internal services, I think it's good to default to 1.3, which this PR addresses.

Note that I've also attempted to connect to load balancers with an older SSL policy using TLS 1.1 and the connection simply failed, so I suspect AWS are also doing something on their part to deprecate 1.1.

Also, we have been using the latest security policy for load balancers elsewhere in the department with no downsides (e.g. connections still worked from browsers and mobile devices).

TLDR: This shouldn't break anything.

Checklist

• I have listed any breaking changes, along with a migration path ¹
• I have updated the documentation as required for the described changes ²

What's included in the new policy?

Protocol	Is supported?
Protocol-TLSv1
Protocol-TLSv1.1
Protocol-TLSv1.2	✓
Protocol-TLSv1.3	✓

Cipher	Is supported?
TLS_AES_128_GCM_SHA256	✓
TLS_AES_256_GCM_SHA384	✓
TLS_CHACHA20_POLY1305_SHA256	✓
ECDHE-ECDSA-AES128-GCM-SHA256	✓
ECDHE-RSA-AES128-GCM-SHA256	✓
ECDHE-ECDSA-AES128-SHA256	✓
ECDHE-RSA-AES128-SHA256	✓
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384	✓
ECDHE-RSA-AES256-GCM-SHA384	✓
ECDHE-ECDSA-AES256-SHA384	✓
ECDHE-RSA-AES256-SHA384	✓
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
AES256-GCM-SHA384
AES256-SHA256

Footnotes

1. Consider whether this is something that will mean changes to projects that have already been migrated, or to the CDK CLI tool. If changes are required, consider adding a checklist here and/or linking to related PRs. ↩

2. If you are adding a new construct or pattern, has new documentation been added? If you are amending defaults or changing behaviour, are the existing docs still valid? ↩

[changeset-bot]

🦋 Changeset detected

Latest commit: 4d12b1a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@guardian/cdk	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[marsavar]

I have specifically hardcoded the string here instead of using the enum variant SslPolicy.RECOMMENDED_TLS, as AWS might change the underlying string in a future version of cdk, so this test will help us catch unexpected changes.

[AshCorr]

Makes sense!

I'm surprised the ELB CDK default doesn't use AWS's recommended TLS settings!

[akash1810]

Brilliant!