mTLS

En el TLS corriente el servidor demuestra quién es y el cliente se queda anónimo en la capa de transporte. El navegador comprueba el certificado del servidor contra una autoridad de confianza y contra el nombre de máquina, y lo que autentica al usuario ocurre después, dentro del canal cifrado, normalmente con una contraseña o con un token.

mTLS añade el sentido contrario. Durante el handshake, el servidor le pide al cliente un certificado, el cliente presenta uno y firma con la clave privada correspondiente, y el servidor lo verifica contra las autoridades en las que confía. Los dos extremos tienen ya una identidad criptográfica establecida antes de intercambiar ningún dato de aplicación.

La propiedad que lo hace valioso entre servicios es que la identidad va ligada a una clave y no a un secreto compartido. Un token al portador o una clave de API valen para quien los tenga, así que se pueden copiar de un fichero de configuración, de un registro, de una variable de entorno o de un repositorio, y reutilizarse en cualquier sitio. Una clave privada que no sale nunca de la carga de trabajo no se puede reproducir presentando un valor capturado, y eso elimina una categoría entera de robo de credenciales.

En la práctica se despliega como infraestructura y no dentro del código de la aplicación. Una malla de servicios, una capa de entrada o un sidecar se ocupan de la emisión, la rotación y la verificación, y las cargas de trabajo reciben certificados de corta duración de forma automática. Esa automatización es lo que lo hace viable: mTLS tenía fama de doloroso porque la gestión manual de certificados a escala lo es de verdad.

El fallo que más veces encontramos es mTLS terminado en el borde y olvidado de ahí para dentro. Un balanceador o una pasarela verifican el certificado de cliente y después reenvían la petición por HTTP plano a un back end que acepta cualquier cosa que le llegue. Desde dentro de la red, que es donde está el atacante cuando esto importa, la autenticación fuerte no está en el camino en absoluto.

El segundo es el almacén de confianza. Un servidor que verifica certificados contra un conjunto amplio de autoridades públicas aceptará un certificado emitido por cualquiera de ellas, a cualquiera. La autenticación mutua interna necesita una infraestructura de clave pública privada, y el conjunto de confianza tiene que contener solo lo que deba poder llamar a este servicio.

El tercero es verificar el certificado y no la identidad que lleva dentro. Una configuración que comprueba la cadena y se para ahí acepta a todas las cargas de trabajo del parque, porque todas tienen certificados válidos de la misma autoridad interna. La autenticación tuvo éxito; la autorización no llegó a preguntarse. En una malla con cien servicios, esa es la diferencia entre un sistema de identidad y una capa de cifrado cara.

El cuarto es la cabecera de identidad reenviada. Cuando el borde termina el mTLS y pasa la identidad del cliente hacia dentro en una cabecera, esa cabecera es una afirmación. Si cualquier componente puede llegar directamente al back end, puede fijar la cabecera él mismo, y la cadena entera se reduce a quien pueda hacer una petición interna. Lo buscamos expresamente, y se empareja directamente con el SSRF, donde una petición interna falsificada es exactamente lo que obtiene el atacante.

Y luego está la revocación, donde la mayoría de los despliegues se apoyan calladamente en la esperanza. Comprobar la revocación añade latencia y una dependencia, así que muchas configuraciones no lo hacen, y un certificado comprometido sigue siendo válido hasta que caduca. La respuesta práctica son vidas muy cortas y no una revocación fiable.

La comparación que todo el mundo pide, y la respuesta es más estrecha de lo que se espera: mTLS cambia a quién se autentica, no cómo funciona el cifrado.

El cifrado es idéntico. Lo que cambia es que el servidor sabe qué carga de trabajo le está llamando antes de procesar nada, y eso es lo que lo convierte en una pieza de zero trust: la identidad sustituye a la posición en la red como base de la decisión.

Terminar en el borde y confiar en el interior. El salto interno es donde está el intruso.

Confiar en autoridades de certificación públicas para clientes internos. Usa una autoridad privada con un almacén de confianza muy acotado.

Verificar la cadena y no el sujeto. Todas las cargas de trabajo de la malla tienen un certificado válido. La autorización sigue teniendo que comprobar cuál.

Certificados de cliente de larga duración. Sin una revocación fiable, la vida del certificado es tu único control. Horas o días, emitidos de forma automática, no años.

Fiarse de una cabecera de identidad reenviada sin restringir quién puede fijarla. Si un back end acepta la cabecera de cualquier cosa que le llegue, la comprobación del borde es decorativa.

Automatiza la emisión y la rotación antes de ampliar la cobertura. Un sistema de identidad de carga de trabajo que emita certificados de corta duración al arrancar quita la objeción operativa y quita la tentación de usar vidas largas. La gestión manual de certificados no escala más allá de un puñado de servicios y produce caídas que se le acaban achacando al mTLS.

Verifica el sujeto, no solo la cadena, y escribe explícitamente qué llamantes se permiten por servicio. Esa lista es la política de control de acceso de verdad, y tenerla en configuración donde se pueda revisar vale más que los propios certificados.

Mantén el mTLS de extremo a extremo donde el tráfico sea sensible, en vez de terminarlo una vez. Cuando terminar en un borde sea inevitable, restringe qué componentes pueden llegar siquiera al back end, para que una petición interna falsificada no pueda saltarse la comprobación.

Mantén el almacén de confianza mínimo e inventariado. Cada autoridad en la que confías es una vía de entrada, y las autoridades internas se acumulan con las fusiones, los pilotos y los aparatos de proveedores.

Para la detección, registra en cada conexión la identidad del cliente que sale del certificado. Ese solo campo convierte el tráfico interno de anónimo en atribuible, lo que vale más para investigar que el propio cifrado, y permite alertar cuando un servicio llama a un par al que no ha llamado nunca.

En un informe de API o de cloud, el mTLS se examina como control de autenticación y los hallazgos van sobre qué se verificó, no sobre si está activado. Registramos dónde termina la conexión, en qué autoridades se confía, si se comprueba el sujeto, si la identidad se reenvía y quién puede fijar esa cabecera, y cuáles son las vidas de los certificados.

La evidencia es una petición que hicimos y que fue aceptada, y la identidad con la que se aceptó. Un hallazgo aquí se demuestra normalmente llamando directamente a un back end, desde una posición que un atacante tendría de forma plausible, y enseñando que el control del borde no estaba en el camino.

La severidad depende de a qué llega la vía sin autenticar. Un back end que acepta peticiones internas sin autenticar pero no expone nada sensible es un hallazgo moderado. La misma configuración en un servicio que devuelve datos de clientes, en un parque donde existe un SSRF, es crítica, y escribimos los dos hallazgos juntos porque por separado ninguno se lee como urgente.

Comprobar que la autenticación entre servicios aguanta allí donde se afirma que existe forma parte de probar una API y los servicios que tiene detrás.

¿Cuál es la diferencia entre TLS y mTLS? En TLS solo el servidor presenta certificado. En mTLS lo presentan los dos, así que el servidor sabe qué cliente le está llamando antes de procesar ningún dato de aplicación. El cifrado es el mismo; la diferencia es a quién se autentica.

¿mTLS sustituye a las claves de API y a los tokens? Para la autenticación entre servicios puede hacerlo, y es más fuerte porque la credencial es una clave privada y no un valor que se pueda copiar de un registro o de un repositorio. La autorización sigue teniendo que decidirse aparte, a partir de la identidad que establece el certificado.

¿mTLS es difícil de operar? Es difícil a mano y manejable automatizado. Una malla o un sistema de identidad de carga de trabajo que emita y rote certificados de corta duración quita casi todo el coste, y los fallos que le dieron mala fama fueron casi todos por caducidades.

¿Cómo revocamos un certificado de cliente? La comprobación de revocación muchas veces no se implementa por la latencia y la dependencia que añade. El enfoque práctico son vidas cortas, para que un certificado comprometido caduque en horas, más la posibilidad de sacar al cliente de la lista de permitidos del servicio de inmediato.