A është vërtet një sulm downgrade një handshake VPN i dështuar?

Një handshake që përfundon me gabim duket si sulm derisa të shikosh mesazhin, dhe shumicën e herëve është aritmetikë: asnjë propozim i përbashkët, një certifikatë e skaduar ose një paketë që nuk mbërriti kurrë. Një sulm downgrade është diçka e veçantë: një kundërshtar që i shtyn të dy skajet drejt një sjelljeje më të dobët nga ajo që do të kishin zgjedhur, dhe lë prova të ndryshme. Trajtimi i çdo dështimi si keqdashje të dërgon të kërkosh një viktimë që mund të mos ekzistojë, ndërsa trajtimi i një downgrade të vërtetë si gabim konfigurimi e lë rezultatin më të dobët në vend. Dy gabimet kushtojnë ndryshe, dhe vetëm njëri është i lirë për t'u korrigjuar.

Çfarë ndryshon në të vërtetë një sulm downgrade

Qëllimi nuk është të thyejë shifrën dhe as të hamendësojë një çelës. Është të ndikojë në negociatë që të dy palët të ndalen në një version më të vjetër ose një algoritëm më të dobët që sulmuesi mund ta përballojë, ose të bëjë njërën palë të besojë se tjetra mbështet vetëm atë.

Ajo që ndryshon është marrëveshja, jo autentikimi. Nëse sulmuesi mund ta ndryshojë ofertën pa u zbuluar, palët mund të përfundojnë ende një handshake dhe të autentikojnë ende njëra-tjetrën, por me parametra që sulmuesi preferon. Prandaj pyetja interesante është nëse vetë negociata mbulohet nga mbrojtja e integritetit.

Pse vetë negociata duhet të autentikohet

TLS 1.3 e bën atë mbrojtje të qartë. Një klient që ofroi versionin më të ri mund të zbulojë një server që u tërhoq në heshtje, sepse vlera e rastësishme e serverit mbart një model fiks kur negocion për 1.2 ose më poshtë, dhe klienti duhet të ndërpresë kur e sheh. Transkripti i plotë mbulohet gjithashtu nga mesazhet përfundimtare, kështu që një ndryshim kudo në negociatë dështon më vonë në vend që të kalojë në heshtje.

Versionet më të vjetra të protokollit kishin histori më të dobëta, dhe pikërisht për këtë rëndësi kanë rregullat e kthimit. Një pikë fundore TLS 1.0 në të njëjtin konfigurim nuk është sulm downgrade; është një rezultat i lejuar që ju zgjodhët ta lejoni. Dallimi është nëse rezultati më i dobët erdhi nga një vendim i mbrojtur apo nga një rrugë e pambrojtur që një ndërmjetës mund të ndikonte. Sapo e formuloni kështu, shumica e incidenteve kthehen në një pyetje konfigurimi.

IKEv2 sillet ndryshe por mbështetet në të njëjtën ide. Propozimi transportohet në një shkëmbim që më vonë autentikon të dy palët, kështu që një pajisje e ndërmjetme që rishkruan algoritmet e thyen autentikimin në vend që ta drejtojë. Kanali i kontrollit i OpenVPN mbron negociatën e vet me TLS dhe pastaj përdor atë kanal për të rënë dakord për shifrat e kanalit të të dhënave, dhe për këtë rreshti i regjistrit të kanalit të kontrollit është ai interesanti.

Përputhshmëria e konfiguruar nuk është sulm

Një administrator mund të lejojë qëllimisht zgjedhje më të vjetra për të mbështetur një klient të dokumentuar, dhe ai vendim është i dukshëm në konfigurim. Një sulmues nuk mund ta krijojë atë konfigurim; ai mund vetëm të shfrytëzojë një rrugë që i lejon të ndikojë në ofertë.

Rregullimi i rrezikshëm është ai që heq provën e dallimit. Aktivizimi i çdo opsioni të vjetër, çaktivizimi i verifikimit të certifikatës ose pranimi i çdo shifre për të zhdukur një gabim zgjeron atë me të cilën pikë fundore do të pajtohet, dhe heq kontrollet që do të kishin raportuar rezultatin më të dobët.

Nëse duhet të mbani një opsion të vjetër, emërtoni arsyen dhe klientin në komentin e konfigurimit, pastaj kufizoni opsionin në profilin që ka nevojë për të. Një përjashtim përputhshmërie i kufizuar në një dëgjues është i auditueshëm; ai i aplikuar globalisht është thjesht një parazgjedhje më e dobët që askush nuk mban mend se e ka zgjedhur.

Lexoni dështimin para se të emërtoni një shkak

Ruani vargun e saktë të gabimit, versionet e klientit dhe serverit dhe kohën përpara çdo ndryshimi. Pastaj klasifikoni: palët nuk u dakordësuan për një propozim, rruga e paketave dështoi, apo njëra palë refuzoi një parametër që dikur e pranonte?

Një mospërputhje propozimi zakonisht emërton versionet ose algoritmet fajtore dhe dështon në të njëjtën pikë çdo herë. Një problem rrugëtimi ose MTU ngec ose skadon në kohë, dhe shpesh ndryshon sipas rrjetit. Një certifikatë e skaduar prodhon një gabim verifikimi, jo negociatë.

Asnjë prej tyre nuk është provë e një sulmuesi. T'i atribuosh shkak dashakeq në dështimin e parë është gabimi, sepse fsheh cilin e përcaktuar që do të dështojë përsëri nesër.

Konfirmoni çfarë u zgjodh në të vërtetë

Pas çdo korrigjimi, lexoni rezultatin e negociuar në vend që të besoni se lidhja u ngrit. Një lidhje që ka sukses sepse verifikimi u hoq është rezultati që po përpiqeshit të shmangnit. Dy komandat e mëposhtme tregojnë versionin dhe shifrën e zgjedhur për një pikë fundore me TLS përpara, plus rreshtin e kanalit të kontrollit nga regjistri i një serveri OpenVPN.

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

Krahasoni rezultatin me konfigurimin që kishit ndërmend, jo me atë që lidhet tani. Nëse versioni i zgjedhur është më i vjetër se minimumi i lejuar, profili ose lista e kthimit është vendi ku duhet shikuar, dhe përgjigjja është të rregullohet ajo listë, jo të shpallet sulm dhe të rindërtohet gjithçka rreth tij.