Leer una captura de tráfico resumida: bien y mal

En una conversación cifrada con TLS, una captura no muestra el contenido. Muestra los metadatos: hacia qué destino fue, por qué puerto, con qué versión, cuánto pesó y a qué hora. Es información suficiente para verificar la política: si todos los destinos son del inventario, si negocian una versión aceptable y si el emisor del certificado es el esperado. Por eso una captura sana es aburrida y repetida, y cualquier fila que se salga del patrón merece una pregunta.

Una conversación sin cifrar es otra cosa: ahí sí se leen cabeceras y a veces el cuerpo, y por eso un solo flujo así vale más que cien flujos cifrados normales.

La captura tiene tres flujos por el puerto 80, es decir, sin TLS, hacia el servicio heredado. Los tres son tráfico en claro y los tres merecen una nota, pero no pesan igual. Uno de ellos lleva en sus cabeceras una credencial de sesión: cualquiera que esté en la ruta entre el dispositivo y el servidor puede leerla y reutilizarla. Es la fila que cambia la gravedad del hallazgo de «una dirección sin cifrar» a «una sesión expuesta».

Abre el archivo de cabeceras de los flujos sin cifrar y localiza el que lleva la cabecera de autorización.

Una de las filas dice «rechazado (pin)»: la app cerró la conexión porque el certificado que recibió no coincidía con lo que llevaba fijado. Antes de apuntarla como fallo de la app, hay que leer quién emitió ese certificado. Si el emisor no es el esperado para ese host, la app hizo su trabajo: detectó un certificado distinto del suyo y no siguió. La causa, según la nota de la revisión, está en la red donde se tomó la captura.

Lee la fila rechazada y anota el emisor del certificado que la app recibió.

Para dimensionar el hallazgo del tráfico en claro hay que ponerle un número. El volumen no cambia el diagnóstico, pero sí cómo se cuenta en el informe: no es lo mismo decir «hay tráfico sin cifrar» que decir cuántos bytes de la captura viajaron legibles. Se suman las filas del puerto 80, sin contar los flujos cifrados, aunque sean mucho más pesados.

Suma los bytes de los flujos que no usaron TLS y anota el total.

La captura tiene tres tipos de filas que llaman la atención: los flujos sin cifrar, el flujo con una versión de TLS retirada y el flujo rechazado por el pin. No todos son defectos de la app. El rechazo por el pin ocurre porque el firewall de la oficina abre y vuelve a cifrar el tráfico con su propia autoridad, y la app hizo lo que debía; se anota como una condición del entorno de la captura. La versión retirada es un hallazgo de nivel medio. El flujo sin cifrar con la credencial de sesión expone algo hoy, a cualquiera en la ruta.