Cifrado en tránsito

Cifrado en tránsito

1) Definición y límites de control

El cifrado in transit es la protección de datos en toda la ruta de transmisión de la red (navegador ↔ servidor, servicio ↔ servicio, agente ↔ corredor, base ↔ aplicación, datacenter ↔ datacenter) para que la intercepción pasiva y los ataques activos al canal no revelen el contenido ni permitan su modificación sin detectarlo.

Lo que cubrimos son: APIs públicas y privadas (HTTP/HTTPS, gRPC), streaming y brokers (Kafka, NATS, RabbitMQ), WebSocket, bases y cachés a través de la red, tráfico de servicios dentro de clústeres, VPN/entre centros de datos y nubes, consultas DNS, clientes móviles/IoT.

Lo que no cubrimos completamente: ataques a puntos finales (compromiso host/navegador), vulnerabilidades de aplicaciones, filtraciones de registros/volcado. Esto lo resuelven los controles separados (A&A, minimización de derechos, encriptación de datos, lógica segura).

2) Modelo de amenazas y objetivos

Riesgos: interceptación/sustitución de tráfico (MITM), downgrade de protocolo/cifrado, certificados/CA falsos, fugas de claves, ataques a SNI/metadatos, contenido mixto, terminación de TLS incorrecta en equilibradores, conexiones interservicios inseguras.

1. Privacidad + integridad con autenticación criptográfica.

2. Confrontación con el downgrade (política estricta y confección).

3. Identificación de las partes (servidor, si es necesario, mutuo).

4. Ciclo de vida administrado de certificados/claves y auditoría.

5. Perfil de rendimiento sin compromiso de seguridad.

3) Principios básicos

TLS está en todas partes por defecto. Tráfico externo e interno - cifrado.
Versiones modernas. TLS 1. 3 como estándar; TLS 1. 2 - sólo con políticas estrictas. Desactivar 1. 0/1. 1.
AEAD cifrados con PFS. AES-GCM o ChaCha20-Poly1305; PFS a través de (EC) DHE.
Curvas/kay-exchange. X25519 (preferiblemente) o secp256r1 (P-256). Llaves RSA ≥2048, mejor ECDSA (P-256).
mTLS donde hay poca confianza. Canales interservicios, API de administración, corredores, bases - a través de la autenticación mutua.
HSTS para la web. Forzar HTTPS + preload para dominios públicos.
«Cifrar y volver a cifrar» conscientemente. Terminal TLS en el perímetro + encriptación re-backend o passthrough de extremo a extremo - seleccione por modelo de amenaza.
Crypto-agility. Posibilidad de cambiar curvas/suites/versiones con tiempo de inactividad cero.

4) Pila de protocolos y scripts

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 para HTTP/2, h3 para HTTP/3; prohibición h2c (sin TLS).
HTTP/3/QUIC: reduce la latencia, la 0-RTT incorporada y la migración de conexiones; 0-RTT resolver selectivamente (riesgo de reproducción).
gRPC: sobre h2/h3; necesariamente TLS, opcional mTLS + autorización per-RPC.
WebSocket: sólo wss ://; en proxy/balancers - actualización correcta y pinning TLS del dominio.

4. 2 Tráfico interservicios y servicio-meshi

Modelo Sidecar (Istio/Linkerd, etc.). mTLS automático, directivas de permiso, rotación de certificados.
SPIFFE/SPIRE. Identidades descentralizadas de servicios (SPIFFE ID), certificados SVID, TTL cortos.
Los parámetros TLS se centralizan. Minimizar la variedad de confecciones en el código de servicio.

4. 3 Corredores/streaming/colas

Kafka/NATS/RabbitMQ: TLS para kliyent↔broker y broker↔broker; si es posible - mTLS.
SASL sobre TLS: si mTLS no es posible, la autenticación es por token/login, pero el canal es cifrado.
ACL y autorización de temas. Cifrado ≠ control de acceso.

4. 4 Bases de datos y cachés

PostgreSQL/MySQL/SQL Server: habilitar TLS, validación CN/SAN, pin CA/raíz.
Redis/Memcached: utilizar rábanos stunnel/TLS; prohibición del tráfico de plain en la venta.

4. 5 Red/túneles

Entre centros de datos/nubes: IPsec (IKEv2) o WireGuard (conjunto moderno de primitivas).
Acceso administrativo: SSH con CECH/cifrados modernos; prohibición de contraseñas, sólo claves/SSO.

4. 6 DNS y protocolos auxiliares

DNS over HTTPS (DoH )/DNS over TLS (DoT) para clientes y dentro del clúster donde sea posible.
Deshabilitar contenido mixto. Nada por http ://en las páginas https ://.

5) Certificados, PKI y administración de claves

Modelo PKI: para dominios externos - CA públicos; para el tráfico interno - su propia CA o SPIRE-CA.
Automatización: ACME/Cert-manager para Kubernetes, TTL corto, rotación automática.
OCSP stapling и CRL. Habilitar el stapling en los frentes; actualizar las cadenas regularmente.
Pinning - con precaución. En clientes móviles/de escritorio - pin CA/SPKI con mecanismo de laminación de emergencia.
Almacenamiento de claves: claves privadas en HSM/KMS/repositorios secretos; mínimo de exposiciones; prohibición de la lógica.

6) Configuraciones: perfiles prácticos

• Versiones: TLS 1. 3 (obligatorio), TLS 1. 2 (fallback).

• TLS 1. 3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256' (+ opciones AES256/CHACHA20 si es necesario).
• Curvas: X25519, secp256r1.
• Certificados: ECDSA-preferiblemente, RSA-fallback.
• Títulos seguros: 'Strict-Transporte-Seguridad', 'X-Content-Type-Options', 'X-Frame-Options' (por caso), 'Referrer-Policy'.
• Cookies: 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict por diseño).

• Certificado de cliente obligatorio.
• Cortocircuito TTL cliente SVID (horas/días), rotación automática.
• Políticas: quién puede conectarse a quién (intent-based/trabajo a través de la autorización mesh).

7) Rendimiento y confiabilidad

Aceleración por hardware: AES-NI/ARMv8 Crypto, preferencia por ChaCha20-Poly1305 en CPU sin AES-NI.
Session resumption: TLS 1. 3 tickets; pensar en la vida útil (equilibrio entre la perforación y la seguridad).
0-RTT: sólo para solicitudes idempotentes; proteja contra el replay (mecanismos anti-replay del servidor).
Equilibradores/proxy: seleccione claramente termination vs passthrough; con termination - volver a cifrar al backend.
Observabilidad: métricas de apretones de manos/errores/negociaciones ALPN, porcentaje TLS 1. 3, certificados de caducidad, estado OCSP.

8) Pruebas y verificación

Escaneo de perfil TLS. Revisiones regulares de versiones/suits/curvas compatibles y HSTS/OCSP.
Pruebas negativas: prohibición de downgrade, desviación de suits débiles, fallas de compuestos sin SNI/sin certificado de cadena válida.
Pentest de canal: simulaciones MITM, comprobación de pinning en clientes móviles, intentos de replay 0-RTT.
Pruebas Chaos: caducidad/revocación del certificado, inaccesibilidad de OCSP/CA.

9) Errores frecuentes y cómo evitarlos

TLS habilitado, pero sin validación de host. Siempre revisamos CN/SAN, prohibimos 'InsecureSkipVerify'.
Contenido mixto. Bloquee los recursos http en las páginas https, use CSP.
Versiones débiles/obsoletas y suites. Desactivar TLS 1. 0/1. 1, CBC/RC4/3DES.
No hay encriptación en el interior. El tráfico de Plain del balanceador a la aplicación es un riesgo.
Certificados de larga vida. Haga una actualización corta de TTL y auto.
SNI/ALPN incorrecto por proxy. Transmisión correcta de SNI/ALPN a TLS pass-tru/termination.

10) Mini recetas (fragmentos de configuración)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Políticas y cumplimiento

Requisitos mínimos: TLS 1. 3 siempre que sea posible; TLS 1. 2 - con un conjunto limitado de suits.
Regulación: PCI DSS/finsector - prohibición de versiones débiles/suites; rotación obligatoria y auditoría.
Enfoque de confianza cero: identidades para cada carga de trabajo, verificación continua y políticas a nivel de servicio.

12) Operación y SLO

SLO: ≥99% de apretones de manos exitosos, ≥95% de tráfico en TLS 1. 3, 0% de contenido mixto.
Alertas: expiración de certificados (<14 días), aumento de fallos de apretones de manos, caída de la proporción de TLS 1. 3, errores de stapling OCSP.
Procedimientos: reemplazo de emergencia de CA/raíz, revocación de clave comprometida, desactivación de 0-RTT.

13) Hojas de cheques

• TLS 1 está deshabilitado. 0/1. 1 y suits débiles, incluidos AEAD y PFS.
• ALPN configurado (h2/h3); prohibición h2c.
• HSTS está habilitado (para dominios públicos), no hay contenido mixto.
• Los certificados se actualizan automáticamente, OCSP stapling funciona.
• Los canales internos están protegidos por mTLS (o equivalente a WireGuard/IPsec).
• Validación verificada de hosts/cadenas en clientes/SDK.

• Monitoreo de versiones TLS/ALPN/errores y expiraciones.
• Plan crypto-agility (traducido a nuevas suitas/curvas).
• Los pentestos periódicos del canal y el rugido de las confesiones.

14) FAQ

P: ¿El TLS solo es suficiente en el perímetro?
Oh no. El tráfico interno también debe ser encriptado (mTLS/túneles/mesh), especialmente en las nubes y cuando hay varios alquileres.

P: ¿Necesitas 0-RTT?
R: Encienda puntualmente para solicitudes idempotentes, de lo contrario, desconecte debido al riesgo de repetición.

P: ¿Qué elegir para el centro de datos? ¿IPsec o WireGuard?
R: WireGuard es más fácil y rápido, IPsec es maduro y ampliamente compatible. Ambos son válidos con la configuración correcta.

P: ¿Cómo proteger los webhooks «en camino»?
R: HTTPS con perfil moderno + verificación del certificado del remitente (si mTLS) + firma de carga útil y verificación de tiempo de ejecución (consulte "Garantías de entrega de webhooks'," Firma y verificación de solicitudes ").

• «Encriptación de At Nat»
• «Autenticación y autorización»
• «Firma y verificación de solicitudes»
• «Autenticación S2S»
• «Administración de claves y rotación»