Beschermt een VPN tegen KRACK? Wat de patch repareert

Als u een VPN koopt omdat een kop zei dat KRACK de Wi-Fi-versleuteling breekt, repareert u de verkeerde laag. Die onthulling uit 2017 beschreef een familie aanvallen met sleutelherinstallatie op de vierweg-handshake van WPA2, en de reparatie kwam als updates van het besturingssysteem, patches voor draadloze stuurprogramma's en routerfirmware. Een tunnel kan uw verkeer voor het lokale netwerk verbergen, maar hij kan een handshake die eronder eindigt niet repareren. Dus de eerste vraag is niet welke VPN u koopt; het is welke van uw apparaten nog een ongepatchte draadloze stack draait.

Dezelfde tweedeling beantwoordt de budgetzorg. Wie geen abonnement kan betalen, is nooit buitengesloten van de echte oplossing, want de oplossing was een gratis update. Geld kost het vervangen van hardware die er geen meer krijgt.

Wat de aanval werkelijk manipuleerde

WPA2 leidt bij associatie een nieuwe paarsleutel af via een vierweg-handshake. Het toegangspunt stuurt een nonce, de client antwoordt met de zijne, beide kanten berekenen de paarsgewijze tijdelijke sleutel, en het toegangspunt bevestigt met een bericht dat de client erkent. Een aanval met sleutelherinstallatie verstoort die reeks in plaats van de wachtwoordzin te raden, en dwingt een client een sleutel te installeren die hij al had geïnstalleerd. Elke herinstallatie kan de verzend-nonce en de ontvangst-teller voor herhaling die aan die sleutel vastzitten terugzetten.

Zodra die tellers achteruitgaan, wordt een deel van het verkeer dat geweigerd had moeten worden weer aanvaardbaar. Afhankelijk van de variant en de implementatie kon een aanvaller binnen radiobereik frames opnieuw afspelen, ontsleutelen of injecteren. De groeps-sleutelhandshake en de handshake voor snelle overgang hadden hun eigen varianten, en daarom noemde de waarschuwing meerdere aanvalsnamen in plaats van één.

Android 6.0 en later was het slechtste geval. De wpa_supplicant-versies konden worden gedwongen een sleutel van alle nullen te installeren, wat ontsleuteling veel makkelijker maakte dan op platforms waar herinstallatie alleen tellers terugzette. Dat detail scheidde een theoretische zwakte van een praktische op het destijds meest voorkomende telefoonplatform.

De reparatie zit in de draadloze stack

De correctie van bovenaf droeg supplicants en toegangspunten op een opnieuw verzonden handshakebericht te negeren zodra de sleutel al was geïnstalleerd. Gepatchte builds van wpa_supplicant en hostapd droegen die, en distributies portten hem terug naar oudere takken, dus de tekenreeks die wpa_supplicant -v afdrukt is een vertrekpunt en geen vonnis. Lees de beveiligingswaarschuwing van de distributie en bevestig de specifieke patch, niet alleen het versienummer. Een build die een oude versie meldt, kan toch gerepareerd zijn, en een build met een nieuwe versie kan toch een backport van de fabrikant missen.

Beide uiteinden van de verbinding vragen aandacht. Een gerepareerde router patcht de laptop niet die ermee verbindt, en een gerepareerde laptop patcht de router niet. Fabrikanten publiceerden waarschuwingen per product, en routerreparaties liepen vaak achter op telefoonupdates omdat elk model zijn eigen firmwarebuild nodig heeft. Als de laatste release van een apparaat vóór de waarschuwing ligt, behandel het dan als ongepatcht tot de fabrikant anders zegt.

Voor apparatuur die u niet kunt bijwerken zijn de opties smal en weinig glansrijk. Neem hem uit gebruik, houd hem weg van netwerken met gevoelig verkeer, of beperk hem tot een segment waar zijn enige gelijken even goed gemist kunnen worden. Geen van die opties vereist een abonnement, en geen ervan wordt beter door een andere tunnelprovider te kiezen.

Wat een tunnel wel dekt

Een VPN verschuift de grens. Uw apparaat versleutelt elk pakket en stuurt het naar een VPN-server, die het ontsleutelt en doorstuurt. Wie de Wi-Fi-verbinding manipuleert, ziet buitenste tunnelpakketten, niet de lading erin, dus een herinstallatieaanval die frames van de linklaag blootlegt, legt niet automatisch de inhoud van de getunnelde verbinding bloot. Die bescherming houdt stand terwijl de draadloze stack eronder kwetsbaar blijft, en dat is precies waarom de twee maatregelen worden verward.

De voorwaarde is "getunneld". Split-tunneling, een omzeilingslijst of een uitzondering voor een captive portal sturen een deel van het verkeer buiten de tunnel, en dat verkeer heeft er geen voordeel van. Hetzelfde geldt voor verkeer van andere apparaten op hetzelfde netwerk die de client nooit hebben geïnstalleerd. Een tunnel is een beslissing per apparaat en per route, geen eigenschap van de kamer, en een VPN op routerniveau dekt alleen wat werkelijk via de router loopt.

Wat de tunnel niet kan, is het stuurprogramma repareren, een deauthenticatievloed stoppen of een aanvaller verhinderen het kanaal te storen. Hij kan ook geen verbinding beschermen die er nooit in komt. Dat zijn beschikbaarheids- en linklaagproblemen, en ze blijven bij de draadloze stack, hoe sterk de ciphersuite op de tunnel ook is.

HTTPS en de tunnel beschermen verschillende sprongen

Eén paginalading kan drie aparte beschermingen omvatten: de Wi-Fi-verbinding, de tunnel naar de VPN-server en de TLS-sessie naar de website. Elk daarvan wordt onafhankelijk onderhandeld. TLS met een geldig certificaat en een moderne protocolversie geeft u geauthenticeerde versleuteling tussen browser en site, zelfs wanneer de eerste sprong vijandig is, omdat de certificaatcontrole voorkomt dat een bedrieger zijn eigen sleutel invoegt.

Die controle heeft zwakke plekken aan de randen. Een omleiding van HTTPS naar HTTP, een pagina die scripts via gewone HTTP laadt, of een gebruiker die door een certificaatwaarschuwing klikt, verplaatsen allemaal verkeer buiten de beschermde sessie. HSTS en de tussenpagina's van de browser bestaan omdat die fouten vaak voorkomen, niet omdat TLS breekbaar is.

HTTPS en een tunnel aanhouden maakt de draadloze implementatie niet onkwetsbaar. De frames worden nog steeds ontsleuteld door een gebrekkig stuurprogramma; het verschil is wat de aanvaller erin aantreft en of die inhoud al door iets anders was beschermd.

Reparatievolgorde voor een gemengd netwerk

Begin bij het toegangspunt, want dat is het apparaat dat u beheert en waarvan elke client afhangt. Loop daarna de besturingssystemen van clients door, de oudste eerst, want platforms die geen updates meer krijgen zijn degene die nooit gepatcht worden. Pas als die inventaris klaar is, heeft een VPN-beslissing zin, en het is een beslissing over blootstelling, niet over reparatie. Het in de andere volgorde doen, eerst tunnel en later firmware, laat het werkelijke defect op zijn plaats zolang het abonnement duurt.

Schrijf op wat u hebt geverifieerd, inclusief de firmwareversie en de datum. "Bijgewerkt" is geen toestand die iemand later kan auditen.

Drie controles dekken het grootste deel van het werk, en ze gaan in deze volgorde. Sla de derde niet over alleen omdat de eerste twee schoon terugkwamen.

• Routerfirmware: vergelijk de geïnstalleerde versie met de waarschuwingspagina van de fabrikant, niet met de updateknop.
• Client-OS: bevestig het patchniveau dat de draadloze correctie bevat voor elke telefoon, laptop en tablet.
• Restanten: lijst apparaten zonder patchpad op en beslis uitfaseren, isoleren of accepteren.

Als de restantenlijst lang is, koopt een gastnetwerk met clientisolatie tijd terwijl hardware wordt vervangen. Test dan één bekende client op elke band, noteer het resultaat en controleer opnieuw na de volgende firmwarerelease. De hardware-inventaris is wat de volgende waarschuwing snel maakt; de tunnel is wat de kloof ondertussen dekt.