TLS

TLS asegura una conexión de tres formas a la vez: cifra los datos para que quien observe no los pueda leer, autentica al servidor (y opcionalmente al cliente) mediante certificados emitidos bajo una infraestructura de clave pública, y protege la integridad para que la manipulación se detecte. Un handshake negocia la versión y la suite de cifrado, establece las claves y valida la cadena de certificados antes de que fluya ningún dato de aplicación. TLS 1.3 simplificó todo esto: retiró las opciones antiguas y débiles, hizo el handshake más rápido, y da secreto hacia delante por defecto, de modo que grabar el tráfico de hoy no permite descifrarlo después aunque se comprometa una clave de larga duración. Es el mecanismo que hay detrás del cifrado en tránsito de la web y de mucho más.

El hallazgo es casi siempre la versión y la configuración, no el protocolo. Los parques mantienen TLS 1.0 y 1.1 activados por un cliente antiguo que nadie quiere romper, dejan negociables suites de cifrado débiles, o sirven certificados caducados, autofirmados donde no deberían, o validados a la ligera por el cliente. Desde el lado del atacante, una bajada a una versión obsoleta o a una suite débil vuelve a abrir ataques que el protocolo actual cerró, y a un cliente que no valida bien el certificado se le puede interceptar por moderno que sea el servidor. Que el protocolo sea fuerte no ayuda si el despliegue ofrece un camino débil.

Revisamos TLS por lo que el endpoint negocia de verdad: qué versiones y suites acepta, si se siguen ofreciendo versiones obsoletas, la cadena de certificados y su validez, y si hay secreto hacia delante. Del lado cliente comprobamos que los certificados se validan, lo que para las conexiones de más valor se extiende a mTLS y al certificate pinning. Nombramos la versión en cada hallazgo, porque la versión es el detalle accionable. Esto forma parte de cómo revisamos tu configuración de TLS.