TLS, qué negocia y qué falla

Antes de cifrar nada, TLS negocia: el cliente propone versiones y algoritmos, el servidor elige, se valida el certificado del servidor y se acuerda una clave simétrica de sesión que cifrará el resto de la conversación. Entender esto ordena los fallos: si el servidor admite versiones viejas, la negociación puede caer en una insegura; si el certificado no se valida bien, la autenticación falla; si la clave de sesión se acuerda mal, todo lo demás se cae. No hace falta saber la matemática del intercambio para auditar el uso: basta saber qué se decide en ese saludo y qué pasa si se decide mal.

Saber que TLS acuerda versión, algoritmos, identidad y clave de sesión es lo que permite leer dónde se rompe.

Un servicio de CifraLab sigue aceptando TLS 1.0 y 1.1, y conjuntos de algoritmos antiguos, «por compatibilidad». Esas versiones tienen debilidades conocidas, y admitirlas permite que un atacante en medio fuerce la negociación hacia la más débil que el servidor acepte. El arreglo es fijar un mínimo de TLS 1.2 —mejor 1.3— y retirar los algoritmos obsoletos de la lista aceptada. La compatibilidad con clientes antiguos casi nunca justifica dejar abierta una versión que se sabe rota; si algún cliente la necesita, ese es el problema a resolver, no la excusa para bajar el mínimo de todos.

El fallo no está en TLS: está en dejar viva una versión que el protocolo ya dejó atrás.

Entre dos microservicios de CifraLab, dentro de la misma red privada, el tráfico va sin cifrar: se cifra solo lo que sale a internet, porque «lo de dentro es de fiar». Esa suposición es la que aprovecha un atacante que ya entró: una vez dentro de la red, escucha el tráfico este-oeste en claro y cosecha datos y credenciales que viajan entre servicios. El arreglo es cifrar también dentro —TLS entre servicios, o TLS mutuo (mTLS) donde además cada extremo se autentica—. La red interna no es un perímetro de confianza; es solo otra red donde alguien puede estar.

El fallo de uso es asumir que «interno» equivale a «seguro», y dejar sin cifrar justo donde un intruso ya está.

En CifraLab el balanceador termina TLS —descifra ahí— y reenvía la petición al servidor de aplicación por HTTP en claro, dentro de la red de la nube, dándolo por seguro. Terminar TLS en el borde es normal; dejar el tramo del balanceador al backend sin cifrar es el hueco: en ese salto el dato viaja legible, y cualquiera con visibilidad de esa red lo lee. El arreglo es re-cifrar del balanceador al backend —TLS de extremo a extremo— o, como mínimo, garantizar que ese tramo va cifrado. «Dentro de la nube» no es lo mismo que «cifrado».

Es el mismo error que el tráfico interno, disfrazado de detalle de infraestructura: un tramo que se supone seguro y viaja en claro.

Leíste la política de versiones, el tráfico interno en claro y el tramo del balanceador al backend. Abre el laboratorio, recorre esas tres configuraciones de TLS y lee el código que la auditoría anotó al cerrar la sala.