Előretekintő titoktartás VPN-hez: mit nyithat ki egy ellopott kulcs
Az előretekintő titoktartás korlátozza, mit árul el egy később ellopott identitáskulcs a rögzített munkamenetekről. Nem védi a kompromittált eszközön lévő élő nyílt szöveget.
Rögzítsen ma egy titkosított alagutat, lopja el jövőre a kiszolgáló hosszú távú privát kulcsát, és próbálja megfejteni a felvételt. Az előretekintő titoktartás az a tulajdonság, amely szerint az ellopott kulcs önmagában nem lesz elég. Ez állítás a rögzített munkamenetekről és bizonyos titkokról, nem általános ígéret arról, hogy az alagút biztonságos volt. A hatókör helyes meghatározása teszi hasznossá a fogalmat.
A kérdés egy felvételről szól, nem az élő munkamenetről
A hosszú távú kulcs azonosítja a végpontot és aláírja a kézfogást. A munkamenetkulcsok titkosítják a tényleges forgalmat, és az előretekintő titoktartású kialakításban friss kulcscsere-anyagból származnak, amelyet mindkét fél előállít, majd később eldob. Az a támadó, aki csak a hosszú távú kulccsal rendelkezik, nem tudja rekonstruálni ezeket az eldobott értékeket. Az élő munkamenet-állapottal rendelkező támadó még mindig képes rá, ezért a garancia a múltról szól, nem a jelenről.
Az állítás feltételes: csak akkor érvényes, ha az efemer titkokat valóban megsemmisítették, és a protokoll az, amelyet gondol. Egy vegyes telepítés megfelelhet neki az egyik alagúton, és elbukhat a másikon.
Egy titok nem építheti újra a többit
Ellenőrizze a kialkudott módot, ne a marketingoldalt. A kézfogás kimenete megnevezi a kulcscserét és a protokoll verzióját.
openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sasAz s_client összegzése mutatja a TLS verziót és a kulcscsere-csoportot, az efemer csoport pedig az előretekintő titoktartású kulcsmegállapodás látható jele. A swanctl listája az IKE és CHILD társításokat mutatja a kulcsfrissítési időzítőikkel, így láthatja, frissíti-e a telepítés a kulcsokat ütemterv szerint. A statikus RSA kulcscsere vagy egy régi kompatibilitási mód elveszíti ezt a tulajdonságot a titkosítás nevétől függetlenül. Jegyezze fel a megfigyelt módot, ne azt, amelyet a szállító hirdetett.
A kulcsfrissítés nem automatikusan előretekintő titoktartás
Az, hogy milyen gyakran frissíti a kulcsokat egy alagút, külön kérdés attól, hogyan származik az egyes kulcs. Az a kialakítás, amely hosszú távú titokból újragenerálja a kulcsokat, percenként frissíthet, és mégis megbukhat a teszten, mert egy későbbi kompromittálódás mindet rekonstruálja. Fordítva, egy ritka frissítésű protokoll továbbra is lehet előretekintő titoktartású, ha minden csere független. A származtatást olvassa, ne az intervallumot, és ne keverje össze a rövid újracsatlakozási időzítőt a kriptográfiai garanciával.
Ugyanez a zavar jelenik meg a titkosításneveknél: egy modern titkosítás semmit sem mond arról, hogyan érkezett a kulcsa.
Mi marad látható a garancia után
Az előretekintő titoktartás védi a rögzített munkamenetek nyílt szövegét egy jövőbeli kulcskompromittálódástól, és semmit sem tesz egy olyan támadó ellen, aki élő forgalmat olvas egy kompromittált végponton. Nem távolítja el a felvételből a célcímeket, az időzítést vagy a mennyiséget, és nem korlátozza, meddig őrzi az üzemeltető a kapcsolati naplókat. Az sem teszi megbízhatóvá a kompromittált klienst, mert a támadó már ott ül, ahol a tartalom nyíltan létezik.
Amikor egy szolgáltató előretekintő titoktartást állít, kérdezze meg, melyik hosszú távú titkot tekintik ellopottnak, és mely munkamenet-titkok maradnak elérhetetlenül. Ha erre a két kérdésre egyértelmű válaszok vannak, az állítás jelent valamit.