Patrones de implementación de TLS mutuo (mTLS)

El TLS estándar solo autentica el servidor ante el cliente mediante un certificado. TLS mutuo (mTLS) amplía este mecanismo: ambas partes presentan y verifican certificados. El cliente presenta un certificado de cliente después de que el servidor lo solicite mediante CertificateRequest durante el handshake de TLS. El servidor verifica el certificado del cliente frente a una CA de confianza. mTLS es la base de las redes de confianza cero: en lugar de depender de la seguridad del perímetro de red, los servicios se autentican criptográficamente en cada conexión. Service meshes como Istio, Linkerd y Consul Connect implementan mTLS de forma transparente entre microservicios.

El handshake de mTLS amplía TLS 1.3 de la siguiente manera: después de ServerHello y del certificado y Finished del servidor, este envía un mensaje CertificateRequest que especifica las autoridades de certificación y los algoritmos de firma aceptables. El cliente responde con Certificate (la cadena de certificados del cliente) y CertificateVerify (una firma sobre la transcripción realizada con la clave privada del cliente). El servidor verifica la cadena de certificados del cliente frente a su almacén de CA de confianza y valida la firma de CertificateVerify. Si ambas verificaciones son correctas, la conexión queda autenticada mutuamente. El cliente no puede falsificar CertificateVerify sin la clave privada correspondiente al certificado.

En entornos de service mesh, los certificados de cliente suelen ser emitidos por una CA interna. Istio utiliza SVID de SPIFFE (Secure Production Identity Framework for Everyone): cada carga de trabajo recibe un certificado con un SAN de URI de SPIFFE (Subject Alternative Name, nombre alternativo del sujeto), como spiffe://cluster.local/ns/default/sa/payment-service. Estos certificados tienen una duración breve (24 horas) y el plano de control del mesh (istiod) los rota automáticamente. En mTLS orientado al usuario (por ejemplo, en VPN empresariales o clientes de API), los certificados pueden ser emitidos por una CA corporativa, tener una duración mayor y distribuirse mediante MDM (Mobile Device Management) a los dispositivos de los empleados.

La verificación de mTLS en el servidor implica varios pasos: (1) Validación de la cadena: verificar que la cadena del certificado del cliente llegue hasta una CA raíz de confianza en el almacén de CA de clientes del servidor. (2) Comprobación del periodo de validez: asegurarse de que el certificado no haya caducado ni haya entrado aún en vigor. (3) Comprobación de revocación: verificar mediante OCSP o CRL que el certificado no haya sido revocado. (4) Coincidencia de SAN/CN: extraer la identidad declarada del SAN del certificado (URI de SPIFFE, nombre DNS o correo electrónico). (5) Autorización: comprobar que la identidad autenticada tenga autorización para acceder al recurso solicitado. Los pasos 4 y 5 requieren lógica a nivel de aplicación que va más allá de la configuración básica de TLS.

Los certificados de corta duración eliminan la necesidad de una revocación explícita: si un certificado caduca en 24 horas, el impacto de una vulneración queda limitado a ese intervalo. La rotación requiere: (1) Pre-rotación: emitir un certificado nuevo antes de que caduque el anterior (rotar al alcanzar el 80 % de su duración). (2) Intercambio sin tiempo de inactividad: el servicio debe aceptar los certificados antiguo y nuevo durante el periodo de transición. (3) Recarga gradual: la pila TLS debe recargar las credenciales sin cerrar las conexiones existentes (nginx: nginx -s reload; Envoy: dynamic xDS certificate update). La SPIFFE Workload API (implementada por SPIRE) automatiza la entrega y rotación de certificados mediante una API de socket de dominio Unix.

Istio implementa mTLS de forma transparente mediante proxies sidecar de Envoy inyectados en cada pod. El plano de control (istiod) actúa como una CA mediante un certificado intermedio firmado por la CA raíz de la malla. El sidecar de cada pod recibe un SPIFFE SVID mediante la API SDS (Secret Discovery Service). Las políticas PeerAuthentication configuran el modo de mTLS: STRICT (mTLS obligatorio), PERMISSIVE (se aceptan tanto mTLS como texto sin cifrar, para la migración) o DISABLE. Los recursos AuthorizationPolicy definen qué servicios pueden comunicarse; esta comunicación se comprueba con la identidad SPIFFE incluida en el certificado del cliente. Esto implementa un modelo de confianza cero dentro del clúster sin modificar el código de la aplicación.

Para los clientes de API externos, mTLS proporciona una autenticación más sólida que las claves de API o los tokens de OAuth. El cliente almacena una clave privada en un almacenamiento seguro (HSM, almacén de claves del sistema operativo o una clave de software protegida con una frase de contraseña). El certificado del cliente se vincula a la CA esperada por el endpoint de la API. Cada solicitud de API se autentica en la capa TLS, por lo que no se necesita un encabezado Authorization independiente. API Shield de Cloudflare, los certificados de cliente de AWS API Gateway y el mTLS de cuentas de servicio de Google Cloud implementan este modelo. Una clave de API comprometida puede utilizarse desde cualquier lugar; para utilizar una clave privada de mTLS comprometida también es necesario robar el dispositivo que ejecuta el cliente.

Las implementaciones de mTLS afrontan varios retos operativos. (1) Distribución de certificados: entregar certificados de cliente de forma segura a todos los servicios, especialmente en entornos dinámicos donde los pods aumentan y disminuyen. (2) Compromiso de la CA: la CA interna es un objetivo de gran valor; si se compromete, todos los certificados de servicio quedan invalidados. Las CA respaldadas por HSM y las CA raíz sin conexión ayudan a mitigar este riesgo. (3) Depuración: el tráfico mTLS cifrado es opaco para las herramientas de depuración estándar; se necesita observabilidad de la malla de servicios (Jaeger, Kiali). (4) Compatibilidad con dispositivos intermedios: los proxies de inspección TLS interrumpen mTLS a menos que se configuren explícitamente para reenviar los certificados de cliente. (5) Incidentes por expiración de certificados: un fallo en la rotación puede provocar interrupciones completas de los servicios.

SPIFFE (Secure Production Identity Framework for Everyone) define un estándar para la identidad de cargas de trabajo mediante SVID de X.509. SPIRE (SPIFFE Runtime Environment) es la implementación de referencia. SPIRE Server actúa como autoridad de registro y CA. Los SPIRE Agents se ejecutan en cada nodo y atestiguan la identidad de la carga de trabajo mediante mecanismos de atestación de nodos (identidad de instancia de AWS, JWT de cuenta de servicio de Kubernetes, TPM) y mecanismos de atestación de cargas de trabajo (PID de Unix, metadatos del entorno de ejecución de contenedores). La Workload API entrega SVID a las cargas de trabajo mediante un socket de dominio Unix y una API gRPC sencilla. SPIRE se integra con Envoy, Nginx y las principales mallas de servicios como fuente de certificados.

En implementaciones de mTLS de alta seguridad, las claves privadas deben residir en módulos de seguridad de hardware (HSM), en lugar de almacenes de claves de software. La biblioteca TLS (OpenSSL, BoringSSL) carga la clave privada mediante la interfaz PKCS#11, que redirige las operaciones de firma al HSM. La clave privada nunca sale de los límites del HSM en texto plano. Entre las opciones de HSM en la nube se incluyen AWS CloudHSM, Azure Dedicated HSM y Google Cloud HSM. Para el mTLS a nivel de dispositivo (IoT, portátiles empresariales), TPM 2.0 proporciona una función similar: la clave de cliente TLS está vinculada al TPM y la firma requiere autorización del TPM, lo que hace extremadamente difícil extraer la clave de un dispositivo comprometido.

Las pruebas de mTLS requieren herramientas compatibles con la presentación de certificados de cliente. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Para probar una malla de servicios, istioctl proxy-config secret pod/name muestra el certificado actual y su fecha de expiración. Ejecute kubectl exec en un pod y use curl con el endpoint de administración del sidecar (localhost:15000) para inspeccionar los listeners activos y su configuración de mTLS. Las pruebas automatizadas de rotación deben verificar que las conexiones permanezcan estables durante los eventos de rotación de certificados.

¿Qué paso adicional añade mTLS en comparación con TLS estándar?

mTLS añade la autenticación mediante certificados de cliente a TLS: ambas partes verifican los certificados de la otra. Los SPIFFE SVID proporcionan una identidad estandarizada para las cargas de trabajo mediante URI de SPIFFE en los SAN de los certificados. Istio implementa mTLS de forma transparente mediante sidecars de Envoy con los modos STRICT/PERMISSIVE. Los certificados de corta duración (24 h) eliminan la necesidad de revocación y limitan el intervalo de exposición en caso de compromiso. SPIRE automatiza la emisión y rotación de certificados mediante la Workload API. Las claves privadas de mTLS deben residir en HSM o TPM en implementaciones de alta seguridad. Entre los retos operativos se incluyen la protección de las claves de la CA, la compatibilidad con dispositivos intermedios y la rotación sin tiempo de inactividad.