VPN TLS frente a IPsec: los cinco campos que merecen revisión

Clasificar las VPN TLS frente a las VPN IPsec por familia de protocolos responde a una pregunta que nadie hizo, y suele citar una construcción que ambas familias dejaron de usar hace años. Lo que un revisor puede evaluar de verdad es la protección negociada, la identidad del par, el modelo de cliente y el servicio expuesto. Esas cuatro cosas son visibles en un despliegue, y ninguna se deduce de la etiqueta del producto. Pida cinco campos y la conversación se vuelve concreta.

Cinco campos, y la etiqueta no es uno de ellos

El primer campo es la versión de software compatible, porque una descripción de protocolo sin versión es un folleto. El segundo es la versión de protocolo negociada, que decide qué construcciones están siquiera disponibles. El tercero es la suite de protección, el cuarto el método de autenticación tanto del par como del usuario, y el quinto el alcance de acceso que el producto concede tras la admisión.

Una etiqueta VPN SSL cubre al menos tres productos distintos: un cliente de red completo, un proxy de aplicaciones y un portal heredado basado en navegador. Exponen servicios diferentes y fallan de forma distinta, así que la etiqueta no puede sustituir el campo de alcance.

Qué cambia realmente el cifrado autenticado

TLS 1.3 exige cifrado autenticado, lo que elimina del protocolo la construcción MAC-then-encrypt más antigua en lugar de dejarla opcional. IPsec ESP ha tenido suites de cifrado autenticado desde hace el mismo tiempo, con AES-GCM definido en su propia RFC. En ambas familias la garantía proviene de la suite negociada y no del nombre de la familia, y por eso la lista de campos empieza por una versión. Un revisor que no puede nombrar la suite no tiene nada que evaluar.

Por eso la comparación histórica es engañosa. Un despliegue fijado a una versión antigua de TLS con una suite CBC y otro que ejecuta TLS 1.3 con una suite AEAD no tienen la misma postura de seguridad, aunque ambos sean VPN TLS. La misma división existe en el lado IPsec entre una suite ESP moderna y una combinación heredada.

Lea los valores negociados en lugar de la configuración que pretendía. Los comandos de abajo muestran en qué coincidieron realmente un extremo activo y un túnel activo.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Si el extremo no quiere negociar TLS 1.3, es un hallazgo y no una preferencia. Si el túnel enumera una suite que no esperaba, la configuración que importa es la que eligieron los pares, no la de la plantilla.

La identidad del par es una cuestión aparte

El cifrado sin un par verificado protege el tráfico de los observadores y lo entrega a quien haya respondido a la conexión. La autenticación del par pregunta qué identidad se espera, qué material de confianza la valida y cómo se comporta el cliente cuando la respuesta no coincide. Una cadena de certificados, una clave fijada y un secreto precompartido son tres respuestas distintas con tres costes operativos distintos.

Luego haga las mismas preguntas sobre el usuario o el dispositivo. Una pasarela que autentica la máquina y admite a cualquier usuario, o lo contrario, tiene una postura concreta que debería escribirse en lugar de suponerse. Los permisos de recursos aplicados tras la admisión forman parte del mismo campo, porque la autenticación no es la autorización.

Conservar las comprobaciones de nombre de host y certificado importa más que la familiaridad de la ventana de inicio de sesión. Un cliente configurado para ignorar la verificación ha eliminado el único paso que distingue su pasarela de una imitación convincente.

El límite que expone el producto

Un portal sin cliente hace de proxy de operaciones de aplicación seleccionadas a través de la pasarela, así que el usuario llega a una interfaz en lugar de a una red. Un cliente de túnel completo transporta lo que seleccionan sus rutas y su política de filtrado, que es una superficie mucho mayor. Comparar los dos por la fuerza del protocolo pasa por alto la diferencia en lo que un atacante puede alcanzar a través de ellos. Uno expone una interfaz de aplicación, el otro expone una red enrutada, y los dos exigen revisiones distintas.

Pregunte qué servicio está expuesto, qué operaciones están autorizadas y en qué escucha la propia pasarela. Una interfaz de administración accesible desde la misma dirección que el portal de usuario es un hallazgo de despliegue, y ninguna elección de protocolo lo compensa.

El alcance por aplicación reduce aún más la superficie, y también cambia el comportamiento de fallo cuando cae el túnel. Un diseño que supone cobertura de túnel completo falla de maneras que un diseño por aplicación no conoce, y la carga de soporte le sigue.

Decida el resultado de fallo y el ciclo de vida

Lo que ocurre cuando la autenticación o la protección no están disponibles es una decisión de política que pertenece a la revisión. Un resultado bloqueado y un repliegue directo no anunciado tienen consecuencias distintas, y la diferencia es invisible en una lista de funciones. Indique el comportamiento previsto junto al recurso que protege.

Incluya el ciclo de vida de parches y soporte de la pasarela, sus funciones externas habilitadas y la ruta de actualización de los clientes. Una elección de protocolo correcta no hace seguro un servicio mal desplegado, y la mayoría de los incidentes viven en esa brecha y no en la suite.

Escriba los cinco campos, la política de fallo y el responsable del ciclo de vida en una página. Esa página es una revisión; una comparación de familias de protocolos es una opinión.