How to Disable TLS v1.1 and Below in AWS ELB and RDS Aurora

suzuki0430

Atsushi Suzuki

Posted on September 2, 2024

How to Disable TLS v1.1 and Below in AWS ELB and RDS Aurora

While reviewing a security checklist, I encountered a question about whether SSL 3.0 and TLS 1.1 and below were disabled, and to my embarrassment, I couldn’t immediately answer. This prompted me to investigate and address this issue.

This guide should serve as a helpful reference for others needing to make similar adjustments.

Our infrastructure setup consists of ELB (ALB) + ECS on Fargate + Aurora MySQL.

ELB (ALB)

I began by checking the details of the security policy ELBSecurityPolicy-2016-08 attached by default to our ELB using the AWS CLI. It revealed that both TLSv1 and TLSv1.1 were enabled.

$ aws elbv2 describe-ssl-policies --names ELBSecurityPolicy-2016-08 --output table
---------------------------------------------------
|               DescribeSSLPolicies               |
+-------------------------------------------------+
||                  SslPolicies                  ||
|+-----------------------------------------------+|
||                     Name                      ||
|+-----------------------------------------------+|
||  ELBSecurityPolicy-2016-08                    ||
|+-----------------------------------------------+|
|||                   Ciphers                   |||
||+--------------------------------+------------+||
|||              Name              | Priority   |||
||+--------------------------------+------------+||
|||  ECDHE-ECDSA-AES128-GCM-SHA256 |  1         |||
|||  ECDHE-RSA-AES128-GCM-SHA256   |  2         |||
|||  ECDHE-ECDSA-AES128-SHA256     |  3         |||
|||  ECDHE-RSA-AES128-SHA256       |  4         |||
|||  ECDHE-ECDSA-AES128-SHA        |  5         |||
|||  ECDHE-RSA-AES128-SHA          |  6         |||
|||  ECDHE-ECDSA-AES256-GCM-SHA384 |  7         |||
|||  ECDHE-RSA-AES256-GCM-SHA384   |  8         |||
|||  ECDHE-ECDSA-AES256-SHA384     |  9         |||
|||  ECDHE-RSA-AES256-SHA384       |  10        |||
|||  ECDHE-RSA-AES256-SHA          |  11        |||
|||  ECDHE-ECDSA-AES256-SHA        |  12        |||
|||  AES128-GCM-SHA256             |  13        |||
|||  AES128-SHA256                 |  14        |||
|||  AES128-SHA                    |  15        |||
|||  AES256-GCM-SHA384             |  16        |||
|||  AES256-SHA256                 |  17        |||
|||  AES256-SHA                    |  18        |||
||+--------------------------------+------------+||
|||                SslProtocols                 |||
||+---------------------------------------------+||
|||  TLSv1                                      |||
|||  TLSv1.1                                    |||
|||  TLSv1.2                                    |||
||+---------------------------------------------+||
|||         SupportedLoadBalancerTypes          |||
||+---------------------------------------------+||
|||  application                                |||
|||  network                                    |||
||+---------------------------------------------+||
Enter fullscreen mode Exit fullscreen mode

Given the output, which listed enabled protocols including outdated ones, I decided to update our configuration to the ELBSecurityPolicy-TLS13-1-2-2021-06, which supports only TLSv1.2 and TLSv1.3.

$ aws elbv2 describe-ssl-policies --names ELBSecurityPolicy-TLS13-1-2-2021-06 --output table
---------------------------------------------------
|               DescribeSSLPolicies               |
+-------------------------------------------------+
||                  SslPolicies                  ||
|+-----------------------------------------------+|
||                     Name                      ||
|+-----------------------------------------------+|
||  ELBSecurityPolicy-TLS13-1-2-2021-06          ||
|+-----------------------------------------------+|
|||                   Ciphers                   |||
||+--------------------------------+------------+||
|||              Name              | Priority   |||
||+--------------------------------+------------+||
|||  TLS_AES_128_GCM_SHA256        |  1         |||
|||  TLS_AES_256_GCM_SHA384        |  2         |||
|||  TLS_CHACHA20_POLY1305_SHA256  |  3         |||
|||  ECDHE-ECDSA-AES128-GCM-SHA256 |  4         |||
|||  ECDHE-RSA-AES128-GCM-SHA256   |  5         |||
|||  ECDHE-ECDSA-AES128-SHA256     |  6         |||
|||  ECDHE-RSA-AES128-SHA256       |  7         |||
|||  ECDHE-ECDSA-AES256-GCM-SHA384 |  8         |||
|||  ECDHE-RSA-AES256-GCM-SHA384   |  9         |||
|||  ECDHE-ECDSA-AES256-SHA384     |  10        |||
|||  ECDHE-RSA-AES256-SHA384       |  11        |||
||+--------------------------------+------------+||
|||                SslProtocols                 |||
||+---------------------------------------------+||
|||  TLSv1.2                                    |||
|||  TLSv1.3                                    |||
||+---------------------------------------------+||
|||         SupportedLoadBalancerTypes          |||
||+---------------------------------------------+||
|||  application                                |||
|||  network                                    |||
||+---------------------------------------------+||
Enter fullscreen mode Exit fullscreen mode

I then updated the security policy for the listener configured in the ELB through the AWS console. If you are using Terraform, you can replace the ssl_policy in the aws_lb_listener resource as follows:

resource "aws_lb_listener" "https_443_prod" {
  load_balancer_arn = aws_lb.alb_prod.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = data.aws_ssm_parameter.cert_arn.value

  default_action {
    type             = "fixed-response"
    fixed_response {
      content_type   = "text/plain"
      message_body   = "Not Found"
      status_code    = "404"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

You can also verify if communications using TLSv1.1 are still occurring by querying the ALB access logs in Athena:

SELECT *
FROM alb_access_logs
WHERE ssl_protocol = 'TLSv1.1'
Enter fullscreen mode Exit fullscreen mode

For more information on how to query ALB access logs with Athena, see my previous article Analyzing ELB Access Logs with Athena: Configuration and Query Examples.

Aurora (RDS)

In Aurora, you can specify the TLS version using a custom parameter group. By setting the tls_version parameter, you can allow only TLSv1.2 and TLSv1.3. Additionally, enabling require_secure_transport to ON ensures secure transport is mandated.

You can update these settings in the AWS console for the parameter group you have attached.

If you are using Terraform, you can add the necessary parameter blocks to the aws_rds_cluster_parameter_group resource to make these changes.

resource "aws_rds_cluster_parameter_group" "aurora_cluster_parameter_group_prod" {
  name        = "aurora-cluster-parameter-group-prod"
  family      = "aurora-mysql8.0"
  description = "Aurora MySQL Cluster Parameter Group for prod"

  parameter {
    name         = "require_secure_transport"
    value        = "ON"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "tls_version"
    value        = "TLSv1.2,TLSv1.3"
    apply_method = "pending-reboot"
  }
}
Enter fullscreen mode Exit fullscreen mode

Conclusion

Disabling TLSv1.1 and below is a vital security measure for modern infrastructures. By updating AWS ELB and Aurora RDS to use secure protocols like TLSv1.2 and TLSv1.3, organizations can enhance data transmission security. This guide provides practical steps for making these critical updates, ensuring compliance with best security practices and maintaining the integrity of your network communications.

References

💖 💪 🙅 🚩
suzuki0430
Atsushi Suzuki

Posted on September 2, 2024

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related