ELBSecurityPolicy-TLS13-1-2-Res-2021-06 policy allows RSA+SHA1 cipher even when undocumented. How can this RSA+SHA1 be disallowed?

Question

Hi,

It appears that using the recommended  ELBSecurityPolicy-TLS13-1-2-Res-2021-06 ELB policy still allows for a deprecated algorithm signature: RSA+SHA1. Given that RSA1 is now considered deprecated and the recommendation is to stop allowing it, how can this one be disallowed? This signature is also not documented as allowed in the link here: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html

This can be checked using testssl as below:

docker run --rm  drwetter/testssl.sh -f https://example-website-with-this-policy.com

```
 Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4

FS is offered (OK)           TLS_AES_256_GCM_SHA384
                              TLS_CHACHA20_POLY1305_SHA256
                              ECDHE-RSA-AES256-GCM-SHA384
                              TLS_AES_128_GCM_SHA256
                              ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 secp521r1 X25519
 TLS 1.2 sig_algs offered:    RSA-PSS-RSAE+SHA256 RSA-PSS-RSAE+SHA384
                              RSA-PSS-RSAE+SHA512 RSA+SHA256 RSA+SHA384
                              RSA+SHA512 RSA+SHA224 RSA+SHA1
 TLS 1.3 sig_algs offered:    RSA-PSS-RSAE+SHA256 RSA-PSS-RSAE+SHA384
                              RSA-PSS-RSAE+SHA512

```

Notice the last sig offered for TLS 1.2 to be RSA+SHA1

UPDATE: Indeed, the documentation describes just the encryption cyphers, and it would appear that SHA1 is not allowed as an encryption cypher, but allowed as a signature algorithm:

The below command can verify that (assuming that your open_ssl client has rsa_pkcs1_sha1 as supported algorithm)

openssl s_client -connect :443 -tls1_2 -sigalgs rsa_pkcs1_sha1 -cipher 'ECDHE-RSA-AES256-GCM-SHA384'

will contain the following:

```
Peer signing digest: SHA1
Peer signature type: RSA
```

Gary Mclean · Accepted Answer

* A cipher suite is a collection of algorithms that define how TLS will secure a connection.
* Signatures in TLS are used during the handshake phase to authenticate participants and ensure the integrity of exchanged messages

The one in question are specified using signature_algorithms during TLS negotiation (separate from the cipher suite).

**How They Work Together**
* The cipher suite might specify ECDHE_RSA, meaning key exchange is done with ECDHE, and the certificate is authenticated using an RSA key.
* The signature algorithm (e.g., rsa_pss_rsae_sha256) tells how exactly the RSA key signs handshake messages.

They must be compatible, but are negotiated and specified separately.

The AWS documentation only list Ciper Suites

Manvitha Potluri · Answer

You're right —>RSA+SHA1 should ideally not appear in a modern security policy like ELBSecurityPolicy-TLS13-1-2-Res-2021-06, especially since SHA1 is deprecated and considered insecure.

**I assume this is What’s happening:**
While AWS documentation doesn't explicitly list RSA+SHA1 in the TLS 1.2 sig_algs, OpenSSL-based scanners (like testssl.sh) still show RSA+SHA1 in the signature algorithm negotiation for TLS 1.2. This doesn’t necessarily mean the cipher is used — just that it’s advertised as available during handshake negotiation.

AWS currently doesn’t allow you to customize or remove individual sig_algs from managed policies like ELBSecurityPolicy-TLS13-1-2-Res-2021-06. This is a limitation in how the policies are provisioned.

**How to mitigate or disallow RSA+SHA1:**

Option 1: Use TLS 1.3 only (where supported)
TLS 1.3 does not use SHA1 anywhere in its handshake or cipher negotiation.

Restrict your listener to TLS 1.3 only via the AWS CLI or console (note: not all clients support this yet).

Option 2: Use a custom security policy (if feasible)
While AWS Application Load Balancer does not support fully custom cipher suites, if you're using Network Load Balancer with TLS, you can define a custom TLS security policy.

But with ALBs, you're limited to AWS-managed policies — so the best you can do is:

Option 3: Enforce stronger client cipher preference
Clients like modern browsers and APIs will prefer RSA-PSS or SHA2-based signatures first.

Weak options like RSA+SHA1 will only be negotiated with outdated clients.

Option 4: Log and block outdated clients
Use AWS WAF or CloudFront headers to identify user-agents or TLS versions and block legacy traffic manually.

Or at a minimum, raise visibility for connections using legacy sig_algs.

Note: There is no way to remove it from AWS-managed ALB policies today.

To fully eliminate SHA1 exposure, use TLS 1.3-only listener or use NLB with a custom policy.

Manvitha Potluri · Answer

Liviu, Yes, SHA1 can still appear in the TLS handshake:
Even though SHA1 is not in any AWS-documented cipher suite, it can still show up as a supported signature algorithm (RSA+SHA1) during the TLS 1.2 handshake negotiation.

**This is because:**
Cipher suites define encryption, key exchange, and MAC.
Signature algorithms (like RSA+SHA1, RSA-PSS+SHA256) are negotiated separately via the signature_algorithms extension in TLS 1.2+.
AWS only lists cipher suites, not signature algorithms — so SHA1's presence is undocumented, but real.

Note:
Custom NLB TLS policy: Only NLB (not ALB) allows fine-grained cipher control via custom security policies.
Terminate TLS upstream (e.g., CloudFront or nginx) if you want full control

ELBSecurityPolicy-TLS13-1-2-Res-2021-06 policy allows RSA+SHA1 cipher even when undocumented. How can this RSA+SHA1 be disallowed?

Add your answer

Relevant content