Mindkét beállítás közös kulcsfájlt használ, és mindkettő nehezebbé teszi a kézfogás forgalmának hamisítását, ezért ugyanazon funkció két neveként kezelik őket. Nem azok. Az egyik aláírja a vezérlőcsomagokat, a másik titkosítja is őket, és egyiknek semmi köze ahhoz a titkosításhoz, amely az adatait védi.

Ez a különbség számít, amikor egy profil nem tud csatlakozni, amikor egy biztonsági vizsgálat azt kérdezi, mit véd a kulcs, és amikor valaki azt feltételezi, hogy a plusz fájl valamilyen meghatározatlan módon titkosítja az alagutat.

Mit véd valójában a közös kulcs

A beállítások által használt kulcs a vezérlőcsatornához tartozik: ahhoz a cseréhez, amely megtárgyalja a paramétereket, igazolja az identitásokat és levezeti az adatkulcsokat. Ez egy előre megosztott titok, amellyel mindkét végpontnak rendelkeznie kell, mielőtt a kézfogás folytatódhat. Mivel az identitásellenőrzések előtt áll, egy rossz kulcs hamarabb leállítja a beszélgetést, mint egy rossz jelszó tenné. Ez a sorrend magyarázza, miért olyan csendes a hibaállapot.

tls-auth ezt a titkot használja arra, hogy HMAC-ot számítson a vezérlőcsomagokra. Az érvényes aláírás nélküli csomagot még a drágább TLS-feldolgozás előtt eldobja a rendszer, ezért írják le gyakran első szűrőként és nem a TLS helyettesítőjeként.

tls-crypt tovább megy: a védett vezérlőforgalmat nemcsak hitelesíti, hanem titkosítja is. A tanúsítványok tartalma, a megtárgyalt titkosításnevek és más kézfogási részletek már nem láthatók a hálózaton, és a kulcs nélküli megfigyelő még azt sem látja, melyik TLS-verziót próbálják. Egy olyan telepítésnél, amely tart a VPN-ujjlenyomatának felfedésétől, ez a tulajdonság a fő ok a választására. Ez azonban továbbra is csoporttitok, nem felhasználónkénti hitelesítő adat.

Egyik mechanizmus sem ad ki identitásokat. A közös kulcs csoporttitok, és bárki, aki birtokolja, teljesítheti az ellenőrzésnek ezt a rétegét.

Miben különbözik a két beállítás

A megfigyelhető különbség az, amit egy megfigyelő lát. tls-auth esetén a kézfogás látható, de kulcs nélkül nem ellenőrizhető. tls-crypt esetén a kézfogás átláthatatlan mindenki számára, aki nem birtokolja a kulcsot.

A konfiguráció is különbözik. A tls-auth irányértékkel használatos, így az egyik oldal a kulcsanyag egyik felét, a másik oldal a másik felét használja. A tls-crypt egyetlen kulcsot használ mindkét irányban, ezért az irányra vonatkozó utasítás nem része az elrendezésének.

A modern kiadásokban a két beállítás kölcsönösen kizárja egymást. A profilnak egyet kell tartalmaznia, nem mindkettőt, és a kiszolgálónak meg a kliensnek meg kell egyeznie abban, melyiket, azonos kulcsanyaggal. Egy régi utasítás megtartása egy új mellett gyakori átállási maradvány. Távolítsa el az inaktívat, hogy a következő olvasó tudja, melyik réteg van valóban érvényben.

Egy újabb változat, a tls-crypt-v2, minden klienst a saját becsomagolt kulcsához köt, így egy kliens visszavonása nem igényli a csoportkulcs újrakibocsátását. Érdemes ismerni, de ez más beállítás, és nem szinonimája az itteni kettő egyikének sem.

Miért tűnik úgy az eltérés, mintha semmi sem történne

Amikor a közös anyag nem egyezik, a másik fél eldobja a csomagokat anélkül, hogy megmondaná a küldőnek, miért. Nincs olvasható hitelesítési hiba, mert a csomag soha nem érte el azt a réteget, amely létrehozná.

A kliens újra próbálkozik, a kiszolgáló nem szól semmit, és a tünet hálózati problémának látszik. Aztán az emberek újraindítják a szolgáltatást, újra beírják a fiók jelszavát, vagy eltávolítják a védelmi utasítást, hogy «teszteljék», ami megváltoztatja a telepítést ahelyett, hogy diagnosztizálná.

A kiszolgálónaplóban az első csomagszintű panaszt olvassa, ne az utolsó újrapróbálkozási sort. Erősítse meg, hogy mindkét oldal ugyanazt a beállítást hordozza azonos kulcsanyaggal, és hogy a kulcsfájl nem csak az egyik oldalon generálódott újra.

Az utasítás eltávolítása nem biztonságos javítás. Kikapcsol egy védelmi réteget minden kliens számára, és egy utána működő alagút csak azt bizonyítja, hogy az a réteg volt az eltérés.

Mit kell még külön beállítani

Ezek a beállítások nem ellenőrzik, ki a másik fél. A tanúsítvány-ellenőrzés, a bizalmi horgony és az elvárt kiszolgálónév továbbra is külön követelmény, és egyik sem válik opcionálissá attól, hogy jelen van egy közös kulcs.

Az adattitkosítást sem választják ki. Az külön tárgyalás, amelyet mindkét fél adatcsatorna-beállításai vezérelnek, és egy tls-crypt-tal védett alagút továbbra is használhat olyan titkosítást, amelyet nem szándékolt.

Végül maga a közös kulcs is kezelést igényel. Kezelje titokként, ossza ki jóváhagyott csatornán, és cserélje le, amikor bárki, aki birtokolta, távozik. Mivel közös, a felfedése minden őt használó végpont felfedése.

Kapcsolódó cikkek