Un handshake VPN fallit és realment un atac de downgrade?

Un handshake que acaba en error sembla un atac fins que mires el missatge, i la majoria de vegades és aritmètica: cap proposta compartida, un certificat caducat o un paquet que no va arribar mai. Un atac de downgrade és una cosa concreta: un adversari que empeny els dos extrems cap a un comportament més feble del que haurien triat, i deixa proves diferents. Tractar cada fallada com a malícia et porta a buscar una víctima que potser no existeix, mentre que tractar un downgrade real com un error de configuració deixa el resultat més feble al seu lloc. Els dos errors costen coses diferents, i només un és barat de corregir.

Què canvia realment un atac de downgrade

L'objectiu no és trencar el xifratge ni endevinar una clau. És influir en la negociació perquè les dues bandes es quedin amb una versió més antiga o un algorisme més feble que l'atacant pugui manejar, o fer que una banda cregui que l'altra només admet això.

El que canvia és l'acord, no l'autenticació. Si l'atacant pot alterar l'oferta sense ser detectat, els parells encara poden completar un handshake i encara poden autenticar-se mútuament, amb paràmetres que l'atacant prefereix. Per això la pregunta interessant és si la negociació mateixa està coberta per la protecció d'integritat.

Per què la negociació mateixa ha d'estar autenticada

TLS 1.3 fa explícita aquesta protecció. Un client que ha ofert la versió més nova pot detectar un servidor que ha retrocedit en silenci, perquè el valor aleatori del servidor porta un patró fix quan negocia 1.2 o inferior, i el client ha d'avortar en veure'l. La transcripció completa també està coberta pels missatges finals, així que qualsevol edició a la negociació falla més endavant en lloc de passar en silenci.

Les versions antigues del protocol tenien històries més febles, i és exactament per això que les regles de retrocés importen. Un extrem TLS 1.0 en la mateixa configuració no és un atac de downgrade; és un resultat permès que heu triat permetre. La distinció és si el resultat més feble ve d'una decisió protegida o d'un camí no protegit que un intermediari podria influir. Un cop ho planteges així, la majoria d'incidents es resolen en una qüestió de configuració.

IKEv2 es comporta diferent però descansa en la mateixa idea. La proposta viatja en un intercanvi que després autentica tots dos parells, així que un equip intermedi que reescriu els algorismes trenca l'autenticació en lloc de dirigir-la. El canal de control d'OpenVPN protegeix la seva negociació amb TLS i després fa servir aquest canal per acordar els xifratges del canal de dades, i per això la línia de registre del canal de control és la interessant.

La compatibilitat configurada no és un atac

Un administrador pot permetre deliberadament opcions antigues per donar suport a un client documentat, i aquesta decisió és visible a la configuració. Un atacant no pot crear aquesta configuració; només pot explotar un camí que li permeti influir en l'oferta.

La reparació perillosa és la que elimina l'evidència de la diferència. Habilitar totes les opcions heretades, desactivar la verificació de certificats o acceptar qualsevol xifratge per fer desaparèixer un error amplia el que l'extrem acceptarà, i elimina les comprovacions que haurien informat del resultat més feble.

Si has de mantenir una opció antiga, anomena el motiu i el client al comentari de configuració, i després limita l'opció al perfil que la necessita. Una excepció de compatibilitat limitada a un sol oient és auditable; aplicada globalment només és un valor per defecte més feble que ningú recorda haver triat.

Llegeix la fallada abans de posar-li un nom a la causa

Conserva la cadena d'error exacta, les versions de client i servidor i l'hora abans de qualsevol canvi. Després classifica: els parells no es van posar d'acord sobre una proposta, el camí dels paquets va fallar o una banda va rebutjar un paràmetre que abans acceptava?

Un desajust de proposta sol nomenar les versions o els algorismes infractors i falla al mateix punt cada vegada. Un problema d'encaminament o d'MTU s'encalla o expira, i sovint varia segons la xarxa. Un certificat caducat produeix un error de verificació, no de negociació.

Res d'això no és prova d'un atacant. Assignar una causa maliciosa a la primera fallada és l'error, perquè amaga el defecte determinista que tornarà a fallar demà.

Confirma què s'ha seleccionat realment

Després de qualsevol correcció, llegeix el resultat negociat en lloc de confiar que la connexió s'ha aixecat. Una connexió que té èxit perquè s'ha eliminat la verificació és el resultat que volies evitar. Les dues ordres següents mostren la versió i el xifratge triats per a un extrem amb TLS al davant, més la línia del canal de control del registre d'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 resultat amb la configuració que volies, no amb el que ara es connecta. Si la versió seleccionada és més antiga que el mínim permès, el perfil o la llista de retrocés és on cal mirar, i la resposta és arreglar aquesta llista en lloc de declarar un atac i reconstruir-ho tot al seu voltant.