Séta agóniában vagy a forgalom titkosítása a Direct Connectben, 3. rész

És senki sem tölt új bort régi tömlőkbe; különben az újbor szétrepeszti a héjakat és magától kifolyik, és a héjak elvesznek; de az új bort új tömlőkbe kell tölteni; akkor mindkettő meg lesz mentve. RENDBEN. 5:37,38

Idén áprilisban a világ legnagyobb DC hubjának adminisztrációja bejelentette a biztonságos kapcsolatok támogatásának megkezdését. Lássuk, mi lett belőle.

Angolra fordít

Lelkiismereti szabadság

Mert minden, amit erről gondoltam, már elmondtam korábban, a cikk ezen részének egyáltalán nem kellett volna léteznie.

Ha biztonságra van szüksége, válassza a modern klienst és ADC hub. Pont.

De mi van, ha továbbra is az NMDC hubot használod, azaz a szokásos? Ebben az esetben meg kell küzdenie a régi, nagyon régi, új vagy egyszerűen konfigurálatlan DC kliensek összeférhetetlenségével. De ez megtörtént, és a problémák nem vártak sokáig.

Maffia

Először is biztonságos kliens-ügyfél kapcsolatok jönnek létre, függetlenül az ügyfél-központ titkosítás meglététől.

Másodszor, lehetetlen vizuálisan meghatározni azt a hubot, amely biztonságos kapcsolatokra vonatkozó kéréseket sugároz vagy nem.

Harmadszor, ma szinte minden DC kliensben alapértelmezés szerint engedélyezve van a kapcsolattitkosítás.

Emlékszel? Most pedig menjünk jelölje be TLS beállításokat a felhasználói oldalon, csatlakozzon a hubhoz, és óvatosan próbálja meg az ügyfeleket összekapcsolni egymással.

NMDC-központ

Séta agóniában vagy a forgalom titkosítása a Direct Connectben, 3. rész

A DC++ kategorikusan elutasítja a biztonságos kapcsolatokat az NMDC-elosztókon, de teljes mértékben támogatja a hagyományosakat. A fejlesztők nem egyszer hangoztatták az okot – nincs értelme ugyanazt a régi gereblyét követni!

A StrongDC++ csak a TLS v.1.0-t ismeri, a modern kliensek pedig egyáltalán nem csatlakoznak hozzá. A GreylinkDC++-nál még rosszabb.

A FlylinkDC++ szívesen kompatibilitási módba kerül a régebbi kliensekkel. Mennyi ideig tart és szükséges-e egyáltalán?

Az EiskaltDC++ kevésbé szívesen teszi ugyanezt, csak a saját igényeire.

ADC hub(ok)

Séta agóniában vagy a forgalom titkosítása a Direct Connectben, 3. rész

Minden pontosan ugyanaz, de a DC++ aktívan benne van a játékban.

Úgy tűnik, hogy az EiskaltDC++ nem tesz különbséget az NMDC és az ADC hubok között, mindkettővel szigorú.

Mi a teendő, ha kiszűri a régi klienseket úgy, hogy a bemeneten beállítja a TLS v.1.2 támogatásának kötelező követelményét?

ADC-központ(ok)

Séta agóniában vagy a forgalom titkosítása a Direct Connectben, 3. rész

Remek, nem?

Álláspontja

Az olvasó azt gondolhatja, hogy a legjobb a FlylinkDC++ használata, és nem lesz probléma, de elfelejti, hogy ez a kliens problematikus magamtól. Az egyik legutolsó incidens, amelyről tudok, az az, hogy sok felhasználó nem jelölte be azokat a négyzeteket, amelyek támogatják a biztonságos kapcsolatokat távoli konfigurációval, és ezek virtuális hiányát az összes korábbi verzióban.

Összefoglalva, számos történelmi és politikai ok miatt az NMDC-központok használata a kliensek közötti biztonságos kapcsolatok alapjaként nehéz, sőt lehetetlen. Egy NMDCs hub használatával garantáltan elveszíti a kapcsolatot egyes felhasználókkal, és cserébe biztonságot kap – de garanciák nélkül.

Ajánlások

Kezdje el használni az ADC hubokat, legalábbis előre. Hagyja vissza az elavult klienseket, és ha Ön DC hub adminisztrátor, tiltsa le az Erős és Szürkét. Mert

Minden önmagával meghasonlott királyság puszta; és minden önmagával meghasonlott város vagy ház ki nem állhat. Matt. 12:25

Forrás: will.com

Hozzászólás