¿Es un handshake VPN fallido realmente un ataque de degradación?

Un handshake que termina en error parece un ataque hasta que miras el mensaje, y la mayoría de las veces es aritmética: ninguna propuesta compartida, un certificado caducado o un paquete que nunca llegó. Un ataque de degradación es algo concreto: un adversario que empuja ambos extremos hacia un comportamiento más débil del que habrían elegido, y deja pruebas distintas. Tratar cada fallo como malicia te manda a buscar una víctima que quizá no exista, mientras que tratar una degradación real como un error de configuración deja el resultado más débil en su sitio. Los dos errores cuestan cosas distintas, y solo uno es barato de corregir.

Qué cambia realmente un ataque de degradación

El objetivo no es romper el cifrado ni adivinar una clave. Es influir en la negociación para que ambos lados se queden con una versión anterior o un algoritmo más débil que el atacante pueda manejar, o hacer que un lado crea que el otro solo admite eso.

Lo que cambia es el acuerdo, no la autenticación. Si el atacante puede alterar la oferta sin ser detectado, los pares aún pueden completar un handshake y seguir autenticándose mutuamente, con parámetros que el atacante prefiere. Por eso la pregunta interesante es si la propia negociación está cubierta por la protección de integridad.

Por qué la propia negociación debe autenticarse

TLS 1.3 hace explícita esa protección. Un cliente que ofreció la versión más nueva puede detectar un servidor que retrocedió en silencio, porque el valor aleatorio del servidor lleva un patrón fijo cuando negocia 1.2 o inferior, y el cliente debe abortar al verlo. La transcripción completa también está cubierta por los mensajes finales, así que cualquier edición en la negociación falla más tarde en lugar de pasar en silencio.

Las versiones antiguas del protocolo tenían historias más débiles, y es justo por eso por lo que importan las reglas de retroceso. Un extremo TLS 1.0 en la misma configuración no es un ataque de degradación; es un resultado permitido que elegiste permitir. La distinción es si el resultado más débil vino de una decisión protegida o de una ruta no protegida que un intermediario podría influir. Una vez lo planteas así, la mayoría de los incidentes se resuelven en una cuestión de configuración.

IKEv2 se comporta distinto pero descansa en la misma idea. La propuesta viaja en un intercambio que después autentica a ambos pares, así que un equipo intermedio que reescribe los algoritmos rompe la autenticación en lugar de dirigirla. El canal de control de OpenVPN protege su negociación con TLS y luego usa ese canal para acordar los cifrados del canal de datos, y por eso la línea de registro del canal de control es la interesante.

La compatibilidad configurada no es un ataque

Un administrador puede permitir deliberadamente opciones antiguas para dar soporte a un cliente documentado, y esa decisión es visible en la configuración. Un atacante no puede crear esa configuración; solo puede explotar una ruta que le permita influir en la oferta.

La reparación peligrosa es la que elimina la evidencia de la diferencia. Habilitar todas las opciones heredadas, desactivar la verificación de certificados o aceptar cualquier cifrado para que desaparezca un error amplía lo que el extremo aceptará, y elimina las comprobaciones que habrían informado del resultado más débil.

Si debes conservar una opción antigua, nombra el motivo y el cliente en el comentario de configuración y luego limita la opción al perfil que la necesita. Una excepción de compatibilidad limitada a un solo listener es auditable; aplicada globalmente es solo un valor por defecto más débil que nadie recuerda haber elegido.

Lee el fallo antes de nombrar una causa

Conserva la cadena de error exacta, las versiones de cliente y servidor y la hora antes de cualquier cambio. Después clasifica: ¿los pares discreparon sobre una propuesta, falló la ruta de paquetes o un lado rechazó un parámetro que antes aceptaba?

Un desajuste de propuesta suele nombrar las versiones o los algoritmos culpables y falla en el mismo punto cada vez. Un problema de enrutamiento o de MTU se atasca o expira, y a menudo varía según la red. Un certificado caducado produce un error de verificación, no de negociación.

Nada de eso es prueba de un atacante. Asignar una causa maliciosa en el primer fallo es el error, porque oculta el fallo determinista que volverá a fallar mañana.

Confirma qué se seleccionó realmente

Después de cualquier corrección, lee el resultado negociado en lugar de confiar en que la conexión se levantó. Una conexión que tiene éxito porque se eliminó la verificación es el resultado que intentabas evitar. Los dos comandos siguientes muestran la versión y el cifrado elegidos para un extremo con TLS delante, más la línea del canal de control del registro de un servidor OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Compara el resultado con la configuración que pretendías, no con lo que ahora se conecta. Si la versión seleccionada es más antigua que el mínimo permitido, el perfil o la lista de retroceso es donde hay que mirar, y la respuesta es arreglar esa lista en lugar de declarar un ataque y reconstruirlo todo a su alrededor.