Er en mislykket VPN-handshake virkelig et downgrade-angrep?

En handshake som ender i en feil føles som et angrep til man ser på meldingen, og som oftest er det aritmetikk: ingen felles tilbud, et sertifikat som har utløpt, eller en pakke som aldri kom frem. Et downgrade-angrep er noe bestemt: en motstander som presser begge ender mot svakere atferd enn de ville ha valgt, og det etterlater andre spor. Behandler man hver feil som ondskap, leter man etter et offer som kanskje ikke finnes, mens man ved å behandle en ekte downgrade som en konfigurasjonsfeil lar det svakere resultatet bli stående. De to feilene koster forskjellig, og bare én av dem er billig å rette.

Hva et downgrade-angrep egentlig endrer

Målet er ikke å bryte chifferen og ikke å gjette en nøkkel. Det er å påvirke forhandlingen slik at begge sider lander på en eldre versjon eller en svakere algoritme som angriperen kan håndtere, eller å få den ene siden til å tro at den andre bare støtter det.

Det som endres, er avtalen, ikke autentiseringen. Hvis angriperen kan endre tilbudet uten å bli oppdaget, kan partene fortsatt fullføre en handshake og fortsatt autentisere hverandre, med parametere angriperen foretrekker. Derfor er det interessante spørsmålet om selve forhandlingen er dekket av integritetsbeskyttelse.

Hvorfor selve forhandlingen må autentiseres

TLS 1.3 gjør den beskyttelsen eksplisitt. En klient som tilbød den nyere versjonen, kan oppdage en server som stille falt tilbake, fordi serverens tilfeldige verdi bærer et fast mønster når den forhandler 1.2 eller lavere, og klienten må avbryte når den ser det. Hele transkriptet er også dekket av de avsluttende meldingene, så en endring hvor som helst i forhandlingen feiler senere i stedet for å passere ubemerket.

Eldre protokollversjoner hadde svakere historier, og det er nettopp derfor fallback-reglene betyr noe. Et TLS 1.0-endepunkt i samme konfigurasjon er ikke et downgrade-angrep; det er et tillatt utfall du selv valgte å tillate. Forskjellen er om det svakere resultatet kom fra en beskyttet beslutning eller fra en ubeskyttet vei en mellommann kunne påvirke. Når man formulerer det slik, blir de fleste hendelser et konfigurasjonsspørsmål.

IKEv2 oppfører seg annerledes, men hviler på samme idé. Tilbudet bæres i en utveksling som senere autentiserer begge parter, så en mellomliggende boks som skriver om algoritmene, bryter autentiseringen i stedet for å styre den. OpenVPNs kontrollkanal beskytter forhandlingen sin med TLS og bruker deretter kanalen til å bli enige om datakanalens chiffere, og derfor er logglinjen for kontrollkanalen den interessante.

Konfigurert kompatibilitet er ikke et angrep

En administrator kan bevisst tillate eldre valg for å støtte en dokumentert klient, og den beslutningen er synlig i konfigurasjonen. En angriper kan ikke lage den konfigurasjonen; de kan bare utnytte en vei som lar dem påvirke tilbudet.

Den farlige reparasjonen er den som fjerner beviset for forskjellen. Å aktivere alle eldre valg, slå av sertifikatvalidering eller godta hvilken som helst chiffer for å få en feil til å forsvinne utvider hva endepunktet vil godta, og fjerner kontrollene som ville ha rapportert det svakere resultatet.

Hvis du må beholde ett gammelt valg, navngi årsaken og klienten i konfigurasjonskommentaren, og begrens deretter valget til profilen som trenger det. Et kompatibilitetsunntak begrenset til én lytter kan revideres; ett som brukes globalt er bare en svakere standard som ingen husker å ha valgt.

Les feilen før du navngir en årsak

Ta vare på den nøyaktige feilstrengen, klient- og serverversjonene og tidspunktet før noen endring. Klassifiser deretter: var partene uenige om et tilbud, sviktet pakkeveien, eller avviste den ene siden en parameter den en gang godtok?

En tilbudsmismatch navngir vanligvis de gjeldende versjonene eller algoritmene og feiler på samme punkt hver gang. Et ruting- eller MTU-problem stopper eller timer ut, og det varierer ofte med nettverket. Et utløpt sertifikat gir en valideringsfeil i stedet for en forhandlingsfeil.

Ingenting av dette er bevis på en angriper. Å tildele ondsinnet årsak ved den første feilen er feilen, fordi det skjuler den deterministiske feilen som vil feile igjen i morgen.

Bekreft hva som faktisk ble valgt

Etter enhver korreksjon, les det forhandlede resultatet i stedet for å stole på at forbindelsen kom opp. En forbindelse som lykkes fordi valideringen ble fjernet, er utfallet du prøvde å unngå. De to kommandoene nedenfor viser valgt versjon og chiffer for et TLS-frontet endepunkt, pluss kontrollkanallinjen fra en OpenVPN serverlogg.

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 konfigurasjonen du hadde til hensikt, ikke med hva som nå kobler til. Hvis den valgte versjonen er eldre enn tillatt minimum, er profilen eller fallback-listen stedet å se, og svaret er å rette den listen i stedet for å erklære et angrep og bygge alt rundt det på nytt.