Är ett misslyckat VPN-handskak verkligen en downgrade-attack?

Ett handska k som slutar i ett fel känns som en attack tills man tittar på meddelandet, och oftast är det aritmetik: inget gemensamt tillbud, ett certifikat som gått ut eller ett paket som aldrig kom fram. En downgrade-attack är något bestämt: en motståndare som pressar båda ändar mot svagare beteende än de skulle ha valt, och den lämnar andra spår. Att behandla varje fel som ondska får dig att leta efter ett offer som kanske inte finns, medan att behandla en riktig downgrade som en konfigurationsbugg låter det svagare resultatet stå kvar. De två felen kostar olika, och bara ett av dem är billigt att rätta.

Vad en downgrade-attack egentligen ändrar

Målet är inte att bryta chiffret och inte att gissa en nyckel. Det är att påverka förhandlingen så att båda sidor landar på en äldre version eller en svagare algoritm som angriparen klarar av, eller att få en sida att tro att den andra bara stöder det.

Det som ändras är överenskommelsen, inte autentiseringen. Om angriparen kan ändra erbjudandet utan att upptäckas kan parterna fortfarande slutföra ett handska k och fortfarande autentisera varandra, men med parametrar som angriparen föredrar. Därför är den intressanta frågan om själva förhandlingen täcks av integritetsskydd.

Varför själva förhandlingen måste autentiseras

TLS 1.3 gör det skyddet explicit. En klient som erbjöd den nyare versionen kan upptäcka en server som tyst föll tillbaka, eftersom serverns slumpvärde bär ett fast mönster när den förhandlar 1.2 eller lägre, och klienten måste avbryta när den ser det. Hela transkriptet täcks också av de avslutande meddelandena, så en ändring var som helst i förhandlingen misslyckas senare i stället för att passera tyst.

Äldre protokollversioner hade svagare historier, och det är just därför fallback-reglerna spelar roll. En TLS 1.0-slutpunkt i samma konfiguration är inte en downgrade-attack; det är ett tillåtet utfall du själv valde att tillåta. Skillnaden är om det svagare resultatet kom från ett skyddat beslut eller från en oskyddad väg som en mellanhand kunde påverka. När man formulerar det så blir de flesta incidenter en konfigurationsfråga.

IKEv2 beter sig annorlunda men vilar på samma idé. Erbjudandet bärs i ett utbyte som senare autentiserar båda parter, så en mellanbox som skriver om algoritmerna bryter autentiseringen i stället för att styra den. OpenVPN:s kontrollkanal skyddar sin förhandling med TLS och använder sedan kanalen för att komma överens om datakanalens chiffer, och därför är loggraden för kontrollkanalen den intressanta.

Konfigurerad kompatibilitet är inte en attack

En administratör kan medvetet tillåta äldre val för att stödja en dokumenterad klient, och det beslutet syns i konfigurationen. En angripare kan inte skapa den konfigurationen; den kan bara utnyttja en väg som låter den påverka erbjudandet.

Den farliga reparationen är den som tar bort beviset för skillnaden. Att aktivera varje äldre alternativ, stänga av certifikatvalidering eller acceptera vilket chiffer som helst för att ett fel ska försvinna breddar vad slutpunkten kommer att acceptera, och tar bort de kontroller som skulle ha rapporterat det svagare resultatet.

Om du måste behålla ett gammalt alternativ, namnge orsaken och klienten i konfigurationskommentaren och begränsa sedan alternativet till profilen som behöver det. Ett kompatibilitetsundantag begränsat till en lyssnare kan granskas; ett som tillämpas globalt är bara en svagare standard som ingen minns att den valde.

Läs felet innan du namnger en orsak

Bevara den exakta felsträngen, klient- och serverversionerna och tiden före varje ändring. Klassificera sedan: var parterna oense om ett erbjudande, svek paketvägen, eller avvisade en sida en parameter som den en gång accepterade?

Ett tillbudsmismatch namnger oftast de felaktiga versionerna eller algoritmerna och misslyckas på samma punkt varje gång. Ett routing- eller MTU-problem stannar eller tar timeout, och det varierar ofta med nätverket. Ett utgånget certifikat ger ett valideringsfel i stället för ett förhandlingsfel.

Inget av det är bevis på en angripare. Att tilldela ondskefull orsak vid det första felet är felet, eftersom det döljer den deterministiska buggen som kommer att misslyckas igen i morgon.

Bekräfta vad som faktiskt valdes

Efter varje korrigering, läs det förhandlade resultatet i stället för att lita på att anslutningen kom upp. En anslutning som lyckas eftersom valideringen togs bort är det utfall du försökte undvika. De två kommandona nedan visar vald version och chiffer för en TLS-frontad slutpunkt, plus kontrollkanallinjen från 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

Jämför resultatet med konfigurationen du avsåg, inte med vad som nu ansluter. Om den valda versionen är äldre än det tillåtna minimumet är profilen eller fallback-listan stället att titta på, och svaret är att rätta den listan i stället för att utlysa en attack och bygga om allt runt den.