Közös DH-csoport, friss titkok: miért lesz olcsóbb a támadás

A csoport paraméterei tervezés szerint nyilvánosak, és éppen ez a nyilvánosság teszi őket könnyen figyelmen kívül hagyhatóvá. A véges test feletti Diffie-Hellmanban a modulus és a generátor közös, a privát kitevők és a belőlük származó munkamenet-kulcsok viszont nem. A számtest-szita támadás drága szakasza a csoporttól függ, nem egyetlen cserétől, ezért egy mindenhol használt gyenge csoport közös teherré válik. A paramétereket nyilvánosnak nevezni pontos és a lényegtelen oldal, mert az újrafelhasznált költség éppen annak a csoportnak a megtámadásának költsége.

A nyilvános fél nem a sebezhető fél, és itt van a csapda

A szokásos félig-érv azt mondja, hogy a paraméterek egy szabványban megjelentek, tehát a támadó már ismeri őket, és elrejtésük semmin sem változtatna. Mindkét állítás igaz, és egyik sem következik a másikból. A mellékelt alapértelmezett csoport nyilvános, és az a privát csoport, amelyet múlt héten generált, szintén látható mindenkinek, aki befejezi a kézfogást. A titoktartás soha nem volt a kontroll; az erő és az érvényesítés az.

Ami változik, az az, hány hely osztozik ugyanazon a gyengeségen. Egy szervezet, amely saját 2048 bites csoportot generál, a saját támadási költségét fizeti, míg egy több millió által választott protokoll-alapérték egyetlen költséget amortizál mindannyiukra. Ebben az értelemben egy szokatlan csoport nem jobb automatikusan. Egy túl kicsi szokatlan csoport csak egy kisebb közös titok, amelyre kevesebb szem figyel.

Az érvényesítés legalább olyan fontos, mint a méret. Egy partner, amely kis tényezőjű modulust küld, vagy olyat, amely nem a protokoll által elvárt alakú, akkor is szivárogtathat információt a privát kitevőről, ha a bitben mért hossz tiszteletet parancsolónak tűnik. Azok a könyvtárak, amelyek már a bemenetnél elutasítják a hibás paramétereket, valódi munkát végeznek, ezért a kézzel írt paraméterfeldolgozás rossz hely az erőfeszítés megtakarítására.

Mit nyújt valójában az előszámítás a támadónak

A számtest-szitának van egy szakasza, amely csak a prímszámtól függ, és a kimenete újra felhasználható minden olyan csere ellen, amely azt a prímszámot használja. Ez a teljes mechanizmus a történelmi aggodalom mögött: a drága rész egyszer fizetendő, és minden további munkamenet határköltsége csökken. A friss kitevők továbbra is védik az egyes cseréket egy passzív megfigyelővel szemben, amíg a csoport elég nagy ahhoz, hogy a szitálás kivitelezhetetlen legyen. A két állítás összeegyeztethető, és a témáról szóló viták többsége abból származik, hogy az egyiket választják és a másikat eldobják.

A 2015-es Logjam-dolgozat bemutatta az exportminőségű, 512 bites Diffie-Hellmanra való lefokozást, és becsülte, mennyibe kerülne a nagyobb, széles körben újrafelhasznált csoportok megtámadása jelentős erőforrásokkal. A bemutatás konkrét volt, a becslések becslések voltak, és egyik sem volt bizonyíték arra, hogy egy adott VPN-munkamenetet megfejtettek.

A dolgozatot a mechanizmus és a bemutatott lefokozás miatt idézd, ne a saját telepítésed méréseként. A régi statisztikák arról, hány szerver osztott meg egy alapértelmezett csoportot, annak az évnek az internetjét írják le, nem egy hálózatot, amelyet ma megvizsgálhatsz. Ami hasznosan átvihető, az a kérdés: tárgyalnak-e az eszközeid még mindig egy kicsi vagy gyengén érvényesített csoportról?

A szabványosított nem ugyanaz, mint a gyenge

Az RFC 7919 megnevezett véges test feletti csoportokat definiál, hogy mindkét vég azonosító alapján állapodjon meg egy csoportban, és konzisztens szabályzatot alkalmazzon. A szabványosítottság előny, mert megszünteti a tárgyalás kétértelműségét, és lehetővé teszi, hogy egy megvalósítás elutasítsa a nem támogatott méreteket. Egy megnevezett csoport csak akkor gyenge, ha a mérete az általad állított szabályzat alatt van, nem azért, mert egy dokumentumban szerepel. Ugyanez a logika vonatkozik az elliptikus görbék csoportjaira, amelyek szerkezete és hibaformái eltérőek.

Tartsd külön a konstrukciókat, amikor róluk gondolkodsz. A véges test feletti Diffie-Hellmanról szóló következtetés semmit nem mond az X25519-ről, és az 1024 bites MODP-csoportról szóló következtetés semmit nem mond a 3072 bitesről. Az erőszabályzat mechanizmusonként, méretenként és protokollverziónként érvényes, ezért az erős kriptográfia kifejezés nem felülvizsgálható állítás.

A hitelesítés a másik fél, és nem helyettesít. Egy erős csoport partner-ellenőrzés nélkül támadót hagy középen, és egy érvényes tanúsítvány nem ment meg egy 768 bites cserét. Két független vonalként vizsgáld őket, majd igazold, hogy mindkettő valóban tárgyalásra kerül.

Olvasd ki a megtárgyalt csoportot egy valódi kapcsolaton

A megtárgyalt csoportot az eszközből olvasd ki, ne a konfigurációs sablonból. A sablonok szándékot írnak le, és az érdekes érték az, amelyben mindkét fél az utolsó kézfogás során megegyezett. Egy IPsec-végponton az állapotkimenet általában kinyomtatja a választott javaslatot, beleértve a MODP-csoportot.

Rögzítsd ezt a sort a szabályzatváltozás előtt és után, és mindkettőt tartsd a változási rekordban. Az összehasonlítás a bizonyíték.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Ha a változás után az állapot még mindig a régi csoportot mutatja, a kapcsolat nem tárgyalt újra, és a konfiguráció szerkesztése semmit nem bizonyított. Indítsd újra a partnert, vagy töröld a biztonsági társítást, majd olvasd ki újra az állapotot. A csak új kapcsolatokra érvényesített szabályzat a hosszú életű alagutakat a régi paramétereken hagyja, ameddig csak fennállnak.

Ellenőrizd a csoportot és a partner személyazonosságát külön

Válaszd szét, hogy mit véd a csoport, és hogy ki van a másik oldalon. Rögzítsd a kulcscsere módját, a csoport méretét és a hitelesítési módot három mezőként, mert ezek egymástól függetlenül hibáznak. Az az alagút, amely 3072 bites csoportot tárgyalt meg, de bármilyen tanúsítványt elfogad, nem ugyanaz a kockázat, mint az, amely rögzít egy partnert, és 2048 bites csoportot használ.

Írd le az elfogadási kritériumokat a vizsgálat kezdete előtt, hogy az eredmény összehasonlítás legyen, ne vélemény. A protokollverziónkénti minimális csoportméret, a megnevezett csoportok engedélyezési listája és a kötelező partner-ellenőrzés elég ahhoz, hogy a döntés mechanikussá váljon. A lista kétértelműsége az, ami a vizsgálatot vitává változtatja, a vitákat pedig nem orvosolják. Ekkor a kimenet azon végpontok listája, amelyek megsértenek egy kimondott szabályt.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Zárd le a kört azzal, hogy a helyreállítás után újra kiolvasod a megtárgyalt értékeket. Egy megfelelő konfigurációs fájl nem bizonyíték arra, hogy egy alagút átvette. Az állapotkimenet és egy friss kézfogás a bizonyíték, és ezek összegyűjtése kevesebb időt vesz igénybe, mint a megbeszélés arról, hogy szükség van-e rájuk.