Er et mislykket VPN-handshake virkelig et downgrade-angreb?

Et handshake, der ender i en fejl, føles som et angreb, indtil man ser på meddelelsen, og for det meste er det aritmetik: intet fælles tilbud, et certifikat der er udløbet, eller en pakke der aldrig nåede frem. Et downgrade-angreb er en bestemt ting: en modstander, der skubber begge ender mod svagere adfærd, end de ville have valgt, og det efterlader andre spor. Behandler man hver fejl som ondskab, leder man efter et offer, der måske ikke findes, mens man ved at behandle et rigtigt downgrade som en konfigurationsfejl lader det svagere resultat blive stående. De to fejl koster forskellige ting, og kun den ene er billig at rette.

Hvad et downgrade-angreb egentlig ændrer

Målet er ikke at bryde chifferen og ikke at gætte en nøgle. Det er at påvirke forhandlingen, så begge sider lander på en ældre version eller en svagere algoritme, som angriberen kan håndtere, eller at få den ene side til at tro, at den anden kun understøtter det.

Det, der ændres, er aftalen, ikke autentificeringen. Hvis angriberen kan ændre tilbuddet uden at blive opdaget, kan parterne stadig gennemføre et handshake og stadig autentificere hinanden, blot med parametre som angriberen foretrækker. Derfor er det interessante spørgsmål, om selve forhandlingen er dækket af integritetsbeskyttelse.

Hvorfor selve forhandlingen skal autentificeres

TLS 1.3 gør den beskyttelse eksplicit. En klient, der har tilbudt den nyere version, kan opdage en server, der stille er faldet tilbage, fordi serverens tilfældige værdi bærer et fast mønster, når den forhandler 1.2 eller lavere, og klienten skal afbryde, når den ser det. Hele transskriptionen er også dækket af de afsluttende meddelelser, så en ændring hvor som helst i forhandlingen fejler senere i stedet for at passere ubemærket.

Ældre protokolversioner havde svagere historier, og det er netop derfor fallback-reglerne betyder noget. Et TLS 1.0-endepunkt i samme konfiguration er ikke et downgrade-angreb; det er et tilladt udfald, som du selv valgte at tillade. Forskellen er, om det svagere resultat kom fra en beskyttet beslutning eller fra en ubeskyttet vej, som en mellemled kunne påvirke. Når man formulerer det sådan, bliver de fleste hændelser et konfigurationsspørgsmål.

IKEv2 opfører sig anderledes, men hviler på samme idé. Tilbuddet bæres i en udveksling, der senere autentificerer begge parter, så en mellemboks, der omskriver algoritmerne, bryder autentificeringen i stedet for at styre den. OpenVPNs kontrolkanal beskytter sin forhandling med TLS og bruger derefter kanalen til at aftale datakanalens chiffere, og derfor er kontrolkanalens loglinje den interessante.

Konfigureret kompatibilitet er ikke et angreb

En administrator kan bevidst tillade ældre valg for at understøtte en dokumenteret klient, og den beslutning er synlig i konfigurationen. En angriber kan ikke skabe den konfiguration; de kan kun udnytte en vej, der lader dem påvirke tilbuddet.

Den farlige reparation er den, der fjerner beviset for forskellen. At aktivere alle ældre valgmuligheder, deaktivere certifikatvalidering eller acceptere enhver chiffer for at få en fejl til at forsvinde udvider, hvad endepunktet vil acceptere, og fjerner de kontroller, der ville have rapporteret det svagere resultat.

Hvis du skal beholde én gammel mulighed, så angiv årsagen og klienten i konfigurationskommentaren, og begræns derefter muligheden til den profil, der har brug for den. En kompatibilitetsundtagelse afgrænset til én lytter kan revideres; en der anvendes globalt er bare en svagere standard, som ingen husker at have valgt.

Læs fejlen, før du navngiver en årsag

Bevar den præcise fejlstreng, klient- og serverversionerne og tidspunktet, før du ændrer noget. Klassificér derefter: var parterne uenige om et tilbud, svigtede pakkevejen, eller afviste den ene side en parameter, som den engang accepterede?

Et tilbudsmismatch navngiver normalt de krænkende versioner eller algoritmer og fejler samme sted hver gang. Et routing- eller MTU-problem stopper eller timer ud, og det varierer ofte med netværket. Et udløbet certifikat giver en valideringsfejl i stedet for en forhandlingsfejl.

Intet af det er bevis på en angriber. At tildele ondsindet årsag ved den første fejl er fejlen, fordi det skjuler den deterministiske fejl, der fejler igen i morgen.

Bekræft, hvad der faktisk blev valgt

Efter enhver rettelse skal du læse det forhandlede resultat i stedet for at stole på, at forbindelsen kom op. En forbindelse, der lykkes, fordi valideringen blev fjernet, er det udfald, du prøvede at undgå. De to kommandoer nedenfor viser den valgte version og chiffer for et TLS-frontet endepunkt plus kontrolkanallinjen fra en OpenVPN serverlog.

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

Sammenlign resultatet med den konfiguration, du havde til hensigt, ikke med hvad der nu forbinder. Hvis den valgte version er ældre end det tilladte minimum, er profilen eller fallback-listen stedet at kigge, og svaret er at rette den liste i stedet for at erklære et angreb og genopbygge alt omkring det.