CloudFront lanza modo Passthrough para mTLS del viewer: qué cambia en tu arquitectura de seguridad

Introducción

Hasta ahora, si querías usar mTLS en CloudFront para validar certificados de clientes en el viewer (el usuario final), tenías dos opciones limitantes: required mode o optional mode. Ambos exigían que CloudFront gestionara los trust stores y realizara la verificación de certificados directamente en el edge. Esto obligaba a los equipos a mantener dos lógicas de validación paralelas: una en el origen (donde finalmente se toma la decisión de acceso) y otra en CloudFront.

El nuevo Passthrough Mode rompe ese paradigma. CloudFront ahora puede forwardear el certificado completo del cliente hacia tu origen sin hacer cache ni verificar el certificado en sí. Así, tu infraestructura de validación mTLS sigue siendo responsabilidad exclusiva del origen, tal como lo tenías planeado desde un principio.

Qué ocurrió

AWS anunció el 14 de mayo de 2025 la disponibilidad del modo Passthrough para mTLS en CloudFront Viewer. Este cambio se enmarca en la estrategia de AWS de reducir la complejidad en el edge y permitir que los clientes adopten mTLS sin duplicar lógica de seguridad.

Diferencias clave con los modos existentes

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

• Reducción de complejidad en el edge: CloudFront ya no necesita mantener trust stores ni actualizarlos cuando tus CAs rotan certificados. Esto simplifica las tareas de patch management en CloudFront y evita situaciones donde un trust store desactualizado en el edge bloquee accesos legítimos.
• Consistencia en la validación: Al centralizar la lógica de mTLS en el origen, eliminás la asimetría entre lo que valida CloudFront y lo que valida tu backend. Esto es crítico en entornos con múltiples orígenes (por ejemplo, APIs en Kubernetes con Istio o Linkerd que ya implementan mTLS).
• Costo operativo: CloudFront no cobra extra por este modo. Solo pagás por las invocaciones de Lambda@Edge si las usás para procesar el certificado (por ejemplo, extraer el Subject Alternative Name antes de llegar al origen).

Para equipos de Seguridad

• Visibilidad total: CloudFront ahora puede adjuntar el certificate chain completo a los headers de request que llegan a tu origen. Esto permite que tus sistemas de SIEM (como Splunk o Elastic) correlacionen el certificado del cliente con logs de acceso, mejorando la trazabilidad.
• Rotación de certificados simplificada: Si usás short-lived certificates (por ejemplo, con Let’s Encrypt y renovaciones cada 90 días), ya no tenés que preocuparte por sincronizar esos cambios en CloudFront. Tu origen ya maneja esa lógica.
• Compliance: En entornos regulados (como HIPAA o PCI DSS), la validación centralizada en el origen facilita auditorías, ya que podés demostrar que la lógica de mTLS reside en un solo punto controlado.

Ejemplo de impacto en performance

En pruebas internas de AWS (documentadas en el blog de AWS), el modo Passthrough introdujo un overhead de ~2ms por request en CloudFront para adjuntar el certificate chain a los headers. Comparado con el required mode (que valida en el edge y puede agregar ~5ms adicionales por la verificación criptográfica), el Passthrough es más eficiente cuando la validación se hace en el origen.

Detalles técnicos

Componentes afectados

• CloudFront: Versión mínima requerida 2025.05.14 (publicada el 14/05/2025). Los clientes en AWS CloudFront con viewer mTLS habilitado automáticamente ven la opción de Passthrough en la consola o API.
• Origen: Cualquier backend que implemente mTLS y pueda procesar el certificate chain enviado por CloudFront. Ejemplos comunes:

– APIs en Kubernetes con Istio (versión 1.21+) configurado para validar certificados de clientes.

– Aplicaciones en Rust usando rustls (versión 0.22+) para validar certificados entrantes.

Configuración mínima para habilitar Passthrough

1. En la consola de CloudFront:

– Seleccioná Passthrough en el modo de autenticación.

– Guardá y espera la propagación (tarda ~5 minutos en entornos estándar).

1. En tu origen (ejemplo con NGINX):

   server {
       listen 443 ssl;
       server_name api.tudominio.com;

       # Configuración para recibir el certificate chain desde CloudFront
       ssl_client_certificate /etc/nginx/trusted-cas.pem;
       ssl_verify_client on;
       ssl_verify_depth 3; # Profundidad para validar la cadena

       # CloudFront adjunta el certificado en el header X-Client-Certificate
       if ($http_x_client_certificate) {
           set $client_cert $http_x_client_certificate;
       }
       location / {
           # Validación adicional aquí si es necesario
           proxy_pass http://backend;
       }
   }
   

– CloudFront adjunta el certificado en el header X-Client-Certificate en formato PEM.

1. En tu aplicación (ejemplo en Rust con rustls):

   use rustls::{RootCertStore, Certificate, PrivateKey};
   use std::sync::Arc;

   fn validate_client_cert(cert_chain: &[u8]) -> Result<(), String> {
       let mut root_store = RootCertStore::empty();
       // Cargá tus CAs de confianza (ej: desde un archivo o base de datos)
       root_store.add_parsable_certificates(&[Certificate(cert_chain.to_vec())])?;
       let config = rustls::ServerConfig::builder()
           .with_safe_defaults()
           .with_client_cert_verifier(Arc::new(rustls::server::AllowAnyAuthenticatedClient::new(root_store)))
           .with_single_cert(
               vec![/* tu certificado del servidor */],
               PrivateKey(/* tu clave privada */),
           )?;
       // Aquí validás el certificado del cliente
       Ok(())
   }
   

Limitaciones conocidas

• No hay cache: CloudFront no cachea requests que pasan por Passthrough. Esto es intencional para garantizar que cada request llegue al origen para validación.
• Headers modificables: CloudFront adjunta el certificado en X-Client-Certificate, pero no modifica otros headers. Si necesitas extraer datos del certificado (como el Subject), debés hacerlo en Lambda@Edge o en tu origen.
• TLS 1.2+: El modo Passthrough requiere TLS 1.2 o superior. No es compatible con TLS 1.0/1.1.

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar si el modo Passthrough aplica a tu arquitectura

El modo Passthrough es ideal si:

✅ Tu origen ya implementa mTLS y tenés una infraestructura de validación consolidada.

✅ Usás short-lived certificates (rotación frecuente) y no querés sincronizar trust stores en CloudFront.

✅ Necesitás correlacionar logs de acceso con certificados de clientes para forensics o compliance.

No lo uses si:

❌ Tu origen no valida certificados y dependés de CloudFront para hacerlo (en ese caso, usá required o optional mode).

❌ Necesitás cachear respuestas basadas en el certificado del cliente (el modo Passthrough no cachea).

2. Actualizar tu origen para recibir el certificate chain

Si ya tenés mTLS en tu origen, solo necesitás:

• Asegurarte de que tu servidor acepte el header X-Client-Certificate de CloudFront.
• Validar el certificado en el origen (ej: en NGINX con ssl_verify_client on; o en Rust con rustls).

Si tu origen no valida certificados hoy, el modo Passthrough no es la solución. En ese caso, migrá primero a required mode en CloudFront y luego implementá la validación en el origen.

3. Probar en staging antes de prod

1. En una distribución de staging:

– Usá curl -v --cert client.pem --key client.key https://tu-distribution.cloudfront.net para simular un cliente con certificado.

1. Verificá logs:

– En tu origen: revisá que el certificado llegue en X-Client-Certificate.

1. Monitoreo:

– mTLS_Passthrough_Requests (conteo de requests con certificado adjunto).

– mTLS_Validation_Failures (si tu origen reporta rechazos).

4. Migrar de required/optional a Passthrough

Si ya usás required o optional mode hoy, seguí estos pasos para migrar sin downtime:

1. Configurá Passthrough en modo optional en CloudFront para probar.
2. Modificá tu origen para validar el certificado en el header X-Client-Certificate además de la validación en CloudFront.
3. Deshabilitá la validación en CloudFront (poné el modo en Passthrough).
4. Monitoreá errores en los logs del origen. Si hay rechazos, revertí temporalmente a optional mode.

Ejemplo de Terraform para migrar:

resource "aws_cloudfront_distribution" "ejemplo" {
  # ... otras configuraciones ...

  viewer_certificate {
    cloudfront_default_certificate = false
    minimum_protocol_version       = "TLSv1.2_2021"
    ssl_support_method            = "sni-only"

    # Cambiá esto de "static" a "passthrough"
    viewer_protocol_policy = "passthrough" # Solo disponible en versiones recientes de AWS Provider
  }
}

> Nota: La sintaxis exacta depende de tu versión del AWS Provider para Terraform. Revisá la documentación oficial para detalles.

5. Documentar el cambio

Actualizá tus runbooks y diagramas de arquitectura para reflejar que la validación de mTLS ahora reside en el origen. Incluí:

• Los headers que CloudFront adjunta (X-Client-Certificate).
• Los endpoints de origen afectados.
• Los trust stores que ya no necesitan sincronizarse en CloudFront.

Conclusión

El modo Passthrough de CloudFront mTLS no es un cambio menor: es una redefinición de responsabilidades en tu arquitectura de seguridad. Al mover la validación de certificados al origen, eliminás la duplicación de lógica, simplificás la rotación de certificados y ganás consistencia en la validación. Eso sí, este modo exige que tu origen esté preparado para recibir y procesar el certificate chain adjunto por CloudFront.

Si tu equipo ya implementa mTLS en el origen, este cambio te ahorrará horas de mantenimiento en trust stores y te dará mayor control sobre la lógica de acceso. Si aún no validás certificados en el origen, considerá primero implementar esa capa de seguridad allí antes de migrar a Passthrough. La inversión en validación centralizada en el origen paga dividendos en compliance, auditorías y operaciones.

Fuentes

• AWS What’s New: Amazon CloudFront ahora soporta modo Passthrough para mTLS del viewer
• AWS Blog: Mutual TLS en CloudFront
• Documentación oficial de CloudFront mTLS
• Rustls: Validación de certificados en Rust