É realmente un ataque de degradación un handshake VPN fallido?

Un handshake que remata nun erro parece un ataque ata que miras a mensaxe, e a maioría das veces é aritmética: ningunha proposta compartida, un certificado caducado ou un paquete que nunca chegou. Un ataque de degradación é algo concreto: un adversario que empurra os dous extremos cara a un comportamento máis feble do que terían elixido, e deixa probas distintas. Tratar cada fallo como malicia mándate buscar unha vítima que quizais non exista, mentres que tratar unha degradación real como un erro de configuración deixa o resultado máis feble no seu sitio. Os dous erros custan cousas distintas, e só un é barato de corrixir.

Que cambia realmente un ataque de degradación

O obxectivo non é romper o cifrado nin adiviñar unha clave. É influír na negociación para que ambos os lados queden cunha versión anterior ou un algoritmo máis feble que o atacante poida manexar, ou facer que un lado crea que o outro só admite iso.

O que cambia é o acordo, non a autenticación. Se o atacante pode alterar a oferta sen ser detectado, os pares aínda poden completar un handshake e seguir autenticándose mutuamente, con parámetros que o atacante prefire. Por iso a pregunta interesante é se a propia negociación está cuberta pola protección de integridade.

Por que a propia negociación debe autenticarse

TLS 1.3 fai explícita esa protección. Un cliente que ofreceu a versión máis nova pode detectar un servidor que retrocedeu en silencio, porque o valor aleatorio do servidor leva un patrón fixo cando negocia 1.2 ou inferior, e o cliente debe abortar ao velo. A transcrición completa tamén está cuberta polas mensaxes finais, así que calquera edición na negociación falla máis tarde en vez de pasar en silencio.

As versións antigas do protocolo tiñan historias máis febles, e é xusto por iso que importan as regras de retroceso. Un extremo TLS 1.0 na mesma configuración non é un ataque de degradación; é un resultado permitido que elixiches permitir. A distinción é se o resultado máis feble veu dunha decisión protexida ou dunha ruta non protexida que un intermediario podería influír. Unha vez o expoñes así, a maioría dos incidentes resólvense nunha cuestión de configuración.

IKEv2 compórtase distinto pero descansa na mesma idea. A proposta viaxa nun intercambio que despois autentica ambos os pares, así que un equipo intermedio que reescribe os algoritmos rompe a autenticación en vez de dirixila. A canle de control de OpenVPN protexe a súa negociación con TLS e despois usa esa canle para acordar os cifrados da canle de datos, e por iso a liña de rexistro da canle de control é a interesante.

A compatibilidade configurada non é un ataque

Un administrador pode permitir deliberadamente opcións antigas para dar soporte a un cliente documentado, e esa decisión é visible na configuración. Un atacante non pode crear esa configuración; só pode explotar unha ruta que lle permita influír na oferta.

A reparación perigosa é a que elimina a evidencia da diferenza. Habilitar todas as opcións herdadas, desactivar a verificación de certificados ou aceptar calquera cifrado para que desapareza un erro amplía o que o extremo aceptará, e elimina as comprobacións que informarían do resultado máis feble.

Se debes conservar unha opción antiga, nomea o motivo e o cliente no comentario de configuración e despois limita a opción ao perfil que a necesita. Unha excepción de compatibilidade limitada a un só listener é auditable; aplicada globalmente é só un valor por defecto máis feble que ninguén recorda ter elixido.

Le o fallo antes de nomear unha causa

Conserva a cadea de erro exacta, as versións de cliente e servidor e a hora antes de calquera cambio. Despois clasifica: os pares discreparon sobre unha proposta, fallou a ruta de paquetes ou un lado rexeitou un parámetro que antes aceptaba?

Un desaxuste de proposta adoita nomear as versións ou os algoritmos culpables e falla no mesmo punto cada vez. Un problema de encamiñamento ou de MTU atascase ou expira, e a miúdo varía segundo a rede. Un certificado caducado produce un erro de verificación, non de negociación.

Nada diso é proba dun atacante. Asignar unha causa maliciosa no primeiro fallo é o erro, porque oculta o fallo determinista que volverá fallar mañá.

Confirma que se seleccionou realmente

Despois de calquera corrección, le o resultado negociado en vez de confiar en que a conexión se levantou. Unha conexión que ten éxito porque se eliminou a verificación é o resultado que intentabas evitar. Os dous comandos seguintes mostran a versión e o cifrado elixidos para un extremo con TLS diante, máis a liña da canle de control do rexistro dun 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 o resultado coa configuración que pretendías, non co que agora se conecta. Se a versión seleccionada é máis antiga que o mínimo permitido, o perfil ou a lista de retroceso é onde hai que mirar, e a resposta é arranxar esa lista en vez de declarar un ataque e reconstruír todo ao seu redor.