Todos los cursos > Informática ( TI ) > Seguridad de la Información ::

TLS aplicado en sistemas reales: configuración segura y validación

Capítulo 8

Tiempo estimado de lectura: 11 minutos

Qué problemas resuelve TLS en sistemas reales

TLS protege comunicaciones cliente-servidor frente a interceptación y manipulación en tránsito, y reduce el riesgo de suplantación del servidor (y opcionalmente del cliente). En la práctica, TLS aporta:

Confidencialidad: el tráfico viaja cifrado.
Integridad: evita modificaciones silenciosas.
Autenticación: el cliente valida que habla con el servidor esperado; con mTLS, el servidor también valida al cliente.
Negociación segura: acuerda parámetros (versión, suite, claves) con resistencia a degradación cuando está bien configurado.

En producción, la seguridad no depende solo de “usar HTTPS”, sino de decisiones concretas: versiones permitidas, suites, intercambio de claves, certificados, ALPN, HSTS y el uso (o no) de mTLS. Además, la validación en el cliente (hostname, cadena, stores de confianza) suele ser el punto donde aparecen fallos críticos.

Decisiones de configuración que más impactan la seguridad

Versiones TLS: qué permitir

Recomendación general actual:

Permitir TLS 1.3 y, si necesitas compatibilidad, TLS 1.2.
Deshabilitar TLS 1.0/1.1 (riesgo y falta de soporte moderno).

TLS 1.3 simplifica y endurece la negociación (menos opciones peligrosas), reduce latencia y elimina suites heredadas. Si mantienes TLS 1.2, debes ser explícito con suites y curvas.

Suites de cifrado: elegir lo seguro y eliminar lo ambiguo

En TLS 1.3 las suites son pocas y razonables; en TLS 1.2 hay más variabilidad. En términos prácticos:

Prioriza AEAD (por ejemplo, AES-GCM o ChaCha20-Poly1305).
Evita suites sin PFS (Perfect Forward Secrecy) y suites antiguas.
En TLS 1.2, prioriza ECDHE para intercambio de claves (PFS).

Continúa en nuestra aplicación.

Escuche el audio con la pantalla apagada.
Obtenga un certificado al finalizar.
¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Regla operativa: si no puedes explicar por qué una suite está habilitada, probablemente deberías deshabilitarla.

Intercambio de claves y curvas: PFS y compatibilidad

En TLS 1.2, exige ECDHE (no RSA key exchange). En TLS 1.3, el intercambio es (E)DHE por diseño. Para curvas, en entornos modernos suele bastar con X25519 y/o P-256 (según librería y requisitos de cumplimiento). Mantén el conjunto pequeño para reducir superficie.

Certificados en el servidor: parámetros que importan en producción

Decisiones prácticas:

SAN: el nombre del host debe estar en Subject Alternative Name; no dependas de CN.
Cadena completa: sirve el certificado del servidor + intermedios (no la raíz).
Algoritmo: usa certificados con algoritmos modernos (RSA 2048/3072 o ECDSA según tu ecosistema).
Rotación: automatiza renovación (ACME o PKI interna) y despliegue sin downtime.

ALPN: HTTP/2, HTTP/3 y negociación correcta

ALPN (Application-Layer Protocol Negotiation) permite acordar el protocolo de aplicación (p. ej., h2 para HTTP/2, http/1.1). Riesgos típicos:

Deshabilitar HTTP/2 por accidente y degradar rendimiento.
Configurar ALPN de forma inconsistente entre balanceador y backend, causando fallos intermitentes.

Recomendación: habilita ALPN en el punto donde termina TLS (LB/ingress) y valida que el cliente negocia lo esperado.

HSTS: forzar HTTPS en navegadores

HSTS (HTTP Strict Transport Security) indica al navegador que siempre use HTTPS para un dominio. Es una defensa práctica contra downgrade y ciertos escenarios de MITM en el primer salto. Pautas:

Actívalo solo cuando estés seguro de que todo el sitio funciona en HTTPS.
Incluye subdominios si tu inventario está bajo control.
Usa un max-age razonable y aumenta gradualmente.

Strict-Transport-Security: max-age=31536000; includeSubDomains

mTLS: autenticación mutua y control de acceso en la capa de transporte

mTLS añade autenticación del cliente mediante certificado. Es útil en:

APIs internas entre servicios.
Integraciones B2B con identidad fuerte.
Acceso a planos de control (admin APIs) con alta sensibilidad.

Decisiones clave:

Quién emite los certificados de cliente (PKI interna, CA privada, SPIFFE/SPIRE, etc.).
Qué atributo autoriza: no basta con “cert válido”; define reglas (OU, URI SAN, SPIFFE ID, etc.).
Revocación/rotación: preferible vida corta + rotación automatizada frente a depender solo de CRL/OCSP en redes internas.

Guía práctica de hardening (servidor)

Paso 1: define el punto de terminación TLS

Identifica dónde se descifra el tráfico:

En el propio servicio (end-to-end).
En un balanceador/ingress (terminación en borde).
En un service mesh (sidecar).

Esto determina dónde aplicar políticas (versiones, suites, certificados) y dónde observar métricas y logs de handshake.

Paso 2: configura versiones y suites

Objetivo: permitir TLS 1.3 y 1.2, deshabilitar lo demás. En TLS 1.2, limita suites a AEAD + ECDHE. Ejemplo conceptual (los nombres exactos dependen del servidor):

# Pseudoconfiguración (conceptual): permitir solo TLS 1.3 y 1.2, y suites modernas en 1.2

Valida con escáneres y desde clientes reales (algunos SDKs embebidos tienen limitaciones).

Paso 3: certificados y cadena completa

Checklist de despliegue:

El certificado incluye el/los DNS en SAN.
Se sirve la cadena intermedia completa.
La clave privada está protegida (permisos mínimos; idealmente HSM/KMS si aplica).
Renovación automatizada y alerta antes de caducar.

Paso 4: habilita ALPN según tu stack

Si expones HTTP/2, habilita h2 y http/1.1. Asegura coherencia: si el LB termina TLS y habla HTTP/1.1 al backend, no intentes forzar HTTP/2 end-to-end sin soporte.

Paso 5: HSTS (solo web)

Aplica HSTS en respuestas HTTPS del dominio web. No aplica a APIs consumidas por apps no navegador de la misma forma, pero no suele perjudicar si el consumo es exclusivamente HTTPS.

Paso 6: mTLS (si corresponde)

Implementación práctica:

Configura el servidor para requerir certificado de cliente en rutas/hosts que lo necesiten (no necesariamente en todo).
Valida la cadena del certificado de cliente contra una CA/Bundle de confianza específico (no el store público del sistema).
Mapea identidad a autorización: por ejemplo, permitir solo ciertos Subject/SAN o un SPIFFE ID concreto.

Evita el anti-patrón: “mTLS habilitado” pero sin reglas de autorización (cualquier certificado emitido por la CA interna obtiene acceso amplio).

Guía práctica de hardening (cliente)

Validación estricta del hostname

Regla: el cliente debe verificar que el nombre al que se conecta coincide con el certificado (SAN). Errores comunes:

Desactivar verificación en desarrollo y olvidarlo en producción.
Conectar por IP cuando el certificado solo tiene DNS (o al revés).
Usar un nombre interno distinto al público sin certificados adecuados.

Buenas prácticas:

Conecta usando el hostname real (no IP) si tu PKI está basada en DNS.
En librerías HTTP, no uses flags tipo “insecure/skip verify”. Si necesitas excepciones, hazlas por entorno y con controles.

Verificación de cadena (chain validation)

El cliente debe validar:

Que la cadena llega a una CA confiable.
Que los intermedios son correctos.
Que el certificado no está caducado y cumple usos esperados.

En entornos corporativos, es frecuente que haya inspección TLS (proxy) o CAs internas. Decide explícitamente si tu cliente debe confiar en esas CAs. Para servicios críticos, considera un bundle de confianza propio (pinning o trust store dedicado) en lugar del store global del sistema.

Manejo de stores de confianza: sistema vs bundle dedicado

Opciones típicas:

Store del sistema: más compatible; confía en CAs públicas (y en CAs corporativas instaladas).
Bundle dedicado: más control; ideal para servicios internos o mTLS; reduce riesgo de CAs añadidas por terceros.

Patrón recomendado para APIs internas: el cliente usa un bundle de CA interna específico para esos endpoints, y mantiene el store del sistema para tráfico público general.

Escenarios reales

APIs internas con mTLS (service-to-service)

Objetivo: que solo workloads autorizados llamen a la API. Guía práctica:

Identidad: emite certificados de cliente por servicio/instancia (no compartidos).
Vida corta: certificados de horas/días con rotación automática.
Autorización: define políticas por identidad (por ejemplo, solo service-a puede llamar a /admin).
Separación de CAs: una CA para clientes internos y otra para servidores, o al menos políticas distintas.
Observabilidad: registra el identificador del certificado (Subject/SAN) en logs de acceso para auditoría.

Si hay un mesh o un ingress interno, decide si mTLS es end-to-end (app a app) o hop-by-hop (sidecar a sidecar). Documenta el modelo para evitar “zonas en claro” inesperadas.

Aplicaciones móviles: pinning con estrategia de rotación

El pinning reduce el riesgo de CAs comprometidas o proxies con CAs instaladas, pero aumenta el riesgo de caída si no rotas bien. Estrategia práctica:

Qué pinnear: preferible pinnear a una clave pública (SPKI) o a un conjunto de claves, no a un certificado exacto.
Multipin: incluye al menos dos pins válidos (actual y siguiente) para permitir rotación.
Ventana de transición: despliega primero la app con el nuevo pin adicional, luego rota el certificado en servidor, luego retira el pin antiguo en una versión posterior.
Fallback controlado: define qué ocurre si falla el pinning (normalmente, bloquear; en casos extremos, un mecanismo de emergencia con feature flag muy restringido).

Evita pinning “a ciegas” sin telemetría: instrumenta métricas de fallos de handshake y pinning para detectar incidentes tras rotaciones.

Balanceadores y terminación TLS en nube

Patrones comunes:

Terminación en LB: el LB gestiona certificados públicos y negocia TLS con el cliente; hacia el backend puede ir HTTP o HTTPS.
Re-encrypt: TLS cliente→LB y TLS LB→backend (recomendado si el backend está en red compartida o hay requisitos de cifrado interno).
End-to-end: el LB pasa TLS hasta el backend (menos común; útil para ciertos requisitos, pero complica observabilidad en el LB).

Riesgos y controles:

Backend en claro: si LB→backend es HTTP, asegúrate de que la red es privada y segmentada; considera re-encrypt.
Cabeceras de identidad: si el LB añade cabeceras (p. ej., usuario autenticado), protege contra spoofing desde dentro (solo el LB debe poder llegar al backend).
Políticas divergentes: el LB puede permitir TLS 1.2/1.3 pero el backend no; documenta y prueba ambos tramos.

Validación y pruebas: cómo comprobar que tu TLS es el esperado

Pruebas rápidas con herramientas estándar

Usa clientes de diagnóstico para inspeccionar negociación y certificados. Ejemplos:

# Ver cadena y parámetros negociados (SNI importante: -servername)
openssl s_client -connect api.ejemplo.com:443 -servername api.ejemplo.com -alpn h2 -showcerts

curl -v --http2 https://api.ejemplo.com/

Qué mirar:

Versión TLS negociada.
Suite/cipher.
ALPN acordado.
Cadena completa (intermedios presentes).
Errores de verificación (hostname, expiración, CA).

Pruebas automatizadas en CI/CD

Integra checks en pipeline:

Que el endpoint no acepta TLS 1.0/1.1.
Que ofrece TLS 1.3.
Que el certificado caduca en más de X días.
Que la cadena es válida y completa.
Que HSTS está presente en dominios web.

Esto evita regresiones cuando se cambia LB, ingress o librerías.

Lista de verificación para diagnosticar fallos comunes

Errores de certificado

Certificado caducado: revisa fecha de expiración y si la renovación se desplegó realmente (a veces se renueva en el gestor pero no en el LB).
CN/SAN incorrecto: el hostname al que te conectas debe estar en SAN; si usas api vs api.interno, necesitas cubrir ambos o usar el correcto.
Cadena incompleta: falta un intermedio; algunos clientes fallan aunque otros “lo arreglen”. Solución: servir fullchain.
CA no confiable: el cliente no tiene la CA (pública o interna) en su store/bundle.

Problemas de tiempo y entorno

Clocks desincronizados: si el reloj del cliente/servidor está mal, puede parecer “aún no válido” o “caducado”. Verifica NTP.
Intercepción por proxy: un proxy corporativo puede presentar un certificado distinto. Decide si tu app debe permitirlo (store del sistema) o bloquearlo (pinning/bundle dedicado).
SNI ausente: algunos clientes antiguos no envían SNI; en hosts virtuales el servidor puede devolver un certificado por defecto incorrecto.

Negociación TLS y compatibilidad

Handshake failure: suele ser incompatibilidad de versión/suites/curvas. Verifica qué ofrece el servidor y qué soporta el cliente.
ALPN inesperado: el cliente quería HTTP/2 pero negocia HTTP/1.1; revisa configuración del LB/servidor y librería cliente.
mTLS falla: revisa si el servidor está pidiendo certificado, si el cliente lo presenta, si la CA de cliente es la esperada y si la política de autorización coincide con el Subject/SAN.

Problemas por topología (LB/ingress/nube)

Terminación TLS múltiple: TLS termina en LB y también en un proxy interno; puede haber doble reescritura y confusión de cabeceras.
Backend en claro no esperado: auditorías detectan tráfico HTTP interno; decide re-encrypt o segmentación estricta.
Certificado distinto por región: en despliegues multi-región, un LB puede servir un cert diferente; asegúrate de sincronizar configuración y renovación.

Ahora responde el ejercicio sobre el contenido:

En una API interna entre servicios que usa mTLS, ¿qué configuración ayuda a evitar el anti-patrón de “mTLS habilitado” pero con acceso demasiado amplio?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

En mTLS no basta con aceptar cualquier certificado válido: se debe mapear la identidad del certificado a políticas de autorización explícitas (por atributos como SAN/Subject/ID) para limitar qué clientes pueden acceder a qué recursos.