Is 'n mislukte VPN-handskud werklik 'n downgrade-aanval?

'n Handskud wat in 'n fout eindig, voel soos 'n aanval totdat jy na die boodskap kyk, en meestal is dit rekenkunde: geen gedeelde voorstel nie, 'n sertifikaat wat verval het, of 'n pakket wat nooit opgedaag het nie. 'n Downgrade-aanval is 'n spesifieke ding: 'n aanvaller wat beide kante na swakker gedrag druk as wat hulle sou gekies het, en dit laat ander bewyse. Om elke mislukking as kwaadwilligheid te behandel, stuur jou op soek na 'n slagoffer wat dalk nie bestaan nie, terwyl om 'n werklike downgrade as 'n konfigurasiefout te behandel die swakker resultaat in plek laat. Die twee foute kos verskillende dinge, en net een van hulle is goedkoop om reg te maak.

Wat 'n downgrade-aanval werklik verander

Die doel is nie om die syfer te breek en nie om 'n sleutel te raai nie. Dit is om die onderhandeling so te beïnvloed dat beide kante op 'n ouer weergawe of 'n swakker algoritme beland wat die aanvaller kan hanteer, of om een kant te laat glo dat die ander net dit ondersteun.

Wat verander, is die ooreenkoms, nie die verifikasie nie. As die aanvaller die aanbod kan wysig sonder om opgemerk te word, kan die eweknieë steeds 'n handskud voltooi en mekaar steeds verifieer, met parameters wat die aanvaller verkies. Daarom is die interessante vraag of die onderhandeling self deur integriteitsbeskerming gedek word.

Waarom die onderhandeling self geverifieer moet word

TLS 1.3 maak daardie beskerming eksplisiet. 'n Kliënt wat die nuwer weergawe aangebied het, kan 'n bediener opspoor wat stilweg teruggeval het, want die bediener se ewekansige waarde dra 'n vaste patroon wanneer dit 1.2 of laer onderhandel, en die kliënt moet afbreek wanneer hy dit sien. Die volledige transkripsie word ook deur die voltooide boodskappe gedek, so 'n wysiging ergens in die onderhandeling misluk later eerder as om stilweg deur te gaan.

Ouer protokolweergawes het swakker stories gehad, en dit is juis waarom die terugvalreëls saak maak. 'n TLS 1.0-eindpunt in dieselfde konfigurasie is nie 'n downgrade-aanval nie; dit is 'n toegelate uitkoms wat jy gekies het om toe te laat. Die onderskeid is of die swakker resultaat van 'n beskermde beslissing of van 'n onbeskermde pad gekom het wat 'n tussenparty kon beïnvloed. Sodra jy dit so stel, los die meeste voorvalle op in 'n konfigurasievraag.

IKEv2 werk anders maar berus op dieselfde idee. Die voorstel word in 'n uitruiling gedra wat later beide eweknieë verifieer, so 'n middelkas wat die algoritmes herskryf, breek die verifikasie eerder as om dit te stuur. OpenVPN se beheerkanaal beskerm sy onderhandeling met TLS en gebruik dan daardie kanaal om die datakanaal-syfers ooreen te kom, en daarom is die beheerkanaal-logreël die interessante een.

Gekonfigureerde versoenbaarheid is nie 'n aanval nie

'n Administrateur kan doelbewus ouer keuses toelaat om 'n gedokumenteerde kliënt te ondersteun, en daardie beslissing is in die konfigurasie sigbaar. 'n Aanvaller kan nie daardie konfigurasie skep nie; hulle kan net 'n pad uitbuit wat hulle toelaat om die aanbod te beïnvloed.

Die gevaarlike herstel is die een wat bewyse van die verskil verwyder. Om elke nalatenskap-opsie te aktiveer, sertifikaatverifikasie te deaktiveer of enige syfer te aanvaar om 'n fout te laat verdwyn, verbreed wat die eindpunt sal aanvaar, en dit verwyder die kontroles wat die swakker resultaat sou rapporteer.

As jy een ou opsie moet behou, noem die rede en die kliënt in die konfigurasiekommentaar, en beperk dan die opsie tot die profiel wat dit nodig het. 'n Versoenbaarheidsuitsondering wat op een luisteraar gerig is, is ouditeerbaar; een wat globaal toegepas word, is net 'n swakker verstek wat niemand onthou hulle het dit gekies nie.

Lees die fout voordat jy 'n oorsaak noem

Bewaar die presiese foutstring, die kliënt- en bedienerweergawes en die tyd voordat jy enigiets verander. Klassifiseer dan: het die eweknieë oor 'n voorstel verskil, het die pakketpad misluk, of het een kant 'n parameter verwerp wat dit eens aanvaar het?

'n Voorstel-wanpassing noem gewoonlik die oortredende weergawes of algoritmes en misluk elke keer op dieselfde punt. 'n Roete- of MTU-probleem stagneer of time-out, en dit wissel dikwels met die netwerk. 'n Vervalle sertifikaat lewer 'n verifikasiefout eerder as 'n onderhandelingsfout.

Niks daarvan is bewyse van 'n aanvaller nie. Om kwaadwillige oorsaak by die eerste mislukking toe te ken, is die fout, want dit verberg die deterministiese fout wat môre weer sal misluk.

Bevestig wat werklik gekies is

Lees na enige regstelling die onderhandelde resultaat in plaas daarvan om te vertrou dat die verbinding opgekom het. 'n Verbinding wat slaag omdat verifikasie verwyder is, is die uitkoms wat jy wou vermy. Die twee opdragte wat volg, wys die gekose weergawe en syfer vir 'n TLS-eindpunt, plus die beheerkanaal-reël uit 'n OpenVPN bedienerlog.

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

Vergelyk die resultaat met die konfigurasie wat jy bedoel het, nie met wat nou ook al konekteer nie. As die gekose weergawe ouer is as die toegelate minimum, is die profiel of die terugval-lys waar om te kyk, en die antwoord is om daardie lys reg te maak eerder as om 'n aanval te verklaar en alles daaromheen te herbou.