ELB.17: TLS policy allows weak ciphers or TLS 1.0 to 1.1

What does AWS Security Hub ELB.17 check?

ELB.17 fails when an Application or Network Load Balancer listener uses a TLS security policy that is not on AWS's recommended list, typically a legacy policy such as ELBSecurityPolicy-2016-08 that still negotiates TLS 1.0 or 1.1 and weak ciphers.

Why does ELB.17 matter?

TLS 1.0 and 1.1 were deprecated by the IETF and dropped by every major browser years ago. A listener still offering them protects no real users, only vulnerability scanners, ancient devices and attackers probing for downgrade or cipher attacks. Moving to a recommended TLS 1.3 policy closes the downgrade surface and, as a bonus, cuts handshake latency.

How do I fix ELB.17?

1. Inventory listener policies with describe-listeners and flag any not on the recommended list.
2. Pick the right recommended variant (standard TLS 1.3, restricted (Res), FIPS or post-quantum (PQ)) for each listener's compliance needs.
3. Apply it online with modify-listener; the change takes effect on new handshakes with no downtime.
4. Send HSTS from the listener and add a Config rule to prevent regression.

# 1. The canonical statement Security Hub S3.5 looks for (merge into the existing policy).
cat <<'EOF'
{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::acme-prod-logs",
    "arn:aws:s3:::acme-prod-logs/*"
  ],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}
EOF
aws s3api put-bucket-policy --bucket acme-prod-logs --policy file://acme-prod-logs-policy.json

# 2. Swap a load balancer listener onto a policy on ELB.17's recommended list (closes ELB.17).
#    ELBSecurityPolicy-TLS13-1-2-2021-06 is NOT on that list and still fails the control; use a -Res- or TLS13-1-3 variant.
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:listener/app/web-prod/abc/def \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-2021-06