Defending Against “Harvest Now, Decrypt Later” on AWS with Hybrid PQC TLS
AWS Application Load Balancers (ALBs) support post-quantum key agreement through the `ELBSecurityPolicy-TLS13–1–2-Res-PQ-2025–09` security policy. The policy introduces hybrid key exchanges that combine classical algorithms like X25519 with post-quantum algorithms like ML-KEM (formerly Kyber) to protect HTTPS traffic against future quantum attacks.
How Hybrid Key Exchange Mitigates Retrospective Decryption
Current public-key encryption relies on mathematical problems such as integer factorization and discrete logarithms that Shor’s algorithm running on a cryptanalytically relevant quantum computer (CRQC) could solve. Adversaries can record encrypted TLS sessions today and store the ciphertext until quantum hardware can recover the session keys (Harvest Now, Decrypt Later, or HNDL).
To counter HNDL without abandoning proven classical algorithms, AWS uses hybrid key agreement:
1. The client and ALB negotiate both a classical secret (via ECDH / X25519) and a post-quantum secret (via ML-KEM).
2. The final TLS session key derives from both shared secrets combined.
3. An attacker must break both key exchanges to decrypt the intercepted session. If ML-KEM holds, the traffic remains confidential even if classical algorithms break. If ML-KEM has an unforeseen vulnerability, classical X25519 security still applies.
Get vishal acharya’s stories in your inbox
Join Medium for free to get updates from this writer.
The policy supports TLS 1.2 and TLS 1.3 while maintaining fallback compatibility for standard clients that lack ML-KEM support.
ALB Configuration Examples
Terraform Listener
To configure an Application Load Balancer listener in Terraform:
resource "aws_lb_listener" "https" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09"
certificate_arn = aws_acm_certificate.cert.arn
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}Kubernetes Ingress (AWS Load Balancer Controller)
When managing ALBs through the AWS Load Balancer Controller in Kubernetes or Amazon EKS, assign the policy via the `alb.ingress.kubernetes.io/ssl-policy` annotation:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
namespace: production
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/example-uuid
spec:
ingressClassName: alb
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80Production Deployment Considerations
Enabling a post-quantum policy on an ALB changes handshake characteristics and network boundaries:
- Application clients must support hybrid key encapsulation mechanisms (such as ML-KEM-768 groups in Chromium-based browsers) to benefit from PQC. Unsupported clients fall back to standard TLS 1.2/1.3 ciphers automatically.
- ML-KEM public keys and ciphertexts are larger than classical curve keys, adding roughly 1 to 2 KB to TLS ClientHello and ServerHello packets. Test round-trip latency and ensure network middleboxes do not drop fragmented initial packets.
- The ALB terminates TLS at the edge. Traffic between the ALB and internal target groups (ECS tasks, EC2 instances, or EKS pods) remains unencrypted unless you configure end-to-end TLS or internal service meshes independently.
- Server authentication remains classical. Standard RSA or ECDSA certificates issued by AWS Certificate Manager (ACM) continue to authenticate the server; post-quantum protection in this policy applies specifically to session key agreement.









