OpenVPN vs IKEv2 vs PPTP vs L2TP/IPSec vs SSTP – végső útmutató a VPN titkosításhoz

a virtuális magánhálózat (VPN) titkosítja az összes adatot, amikor a számítógép és a VPN szerver között halad. Ebben a teljes VPN titkosítási útmutatóban részletesen megvizsgáljuk, hogy mi a Titkosítás, és hogyan használják a VPN-kapcsolatokban.

talán a legfontosabb, hogy elmagyarázzuk a VPN-szolgáltatások által használt titkosítási kifejezések tömbjét. Reméljük, hogy az útmutató elolvasása után jobban megérti ezt az összetett témát, és jobban képes lesz felmérni a VPN-szolgáltatók biztonsági állításait.

előzmények

ha nem biztos abban, hogy mi a VPN, és mit tehet az Ön számára, kérjük, olvassa el a VPN-eket a kezdők útmutatójához.

célunk, hogy a VPN titkosítás legfontosabb jellemzőit a lehető legegyszerűbb módon mutassuk be. Bár nincs megúszás, attól a ténytől, hogy a titkosítás összetett téma.

ha még a titkosítás kifejezés miatt a szeme elkezd üvegezni, de mégis szeretné tudni, mire kell figyelnie egy jó VPN-szolgáltatásban, akkor a Tartalomjegyzék segítségével egyenesen az összefoglalókhoz ugorhat.

Mi A Titkosítás?

“kezdd az elején,” mondta a király nagyon komolyan”, és menj tovább, amíg el nem érsz a végéig: akkor hagyd abba.”

Lewis Carroll, Alice Csodaországban

a legegyszerűbb analógia az, hogy a titkosítás zár. Ha a megfelelő kulcs van, akkor a zár könnyen kinyitható. Ha valaki nem rendelkezik a megfelelő kulccsal, de hozzá akar férni a zár által védett strongbox (vagyis az Ön adatai) tartalmához, akkor megpróbálhatja megtörni a zárat.

ugyanúgy, ahogy a banki széfet rögzítő zár erősebb, mint a bőröndöt biztosító zár, bizonyos titkosítás erősebb, mint más titkosítás.

ha a legerősebb titkosítással rendelkező VPN-t szeretne, nézze meg a legbiztonságosabb VPN-ek listáját további információkért.

az alapok

amikor gyerek voltál, játszottál valaha azt a játékot, amelyben “titkos üzenetet” hoztál létre úgy, hogy az üzenet egyik betűjét egy másikkal helyettesítetted? A helyettesítés az Ön által választott képlet szerint történt.

lehet, hogy például az eredeti üzenet minden betűjét egy három betűvel helyettesítette az ábécében. Ha valaki más tudta, mi ez a képlet, vagy képes volt kidolgozni, akkor képesek lennének elolvasni a ” titkos üzenetet.”

a kriptográfiai zsargonban az üzenetet (adatokat) egy nagyon egyszerű matematikai algoritmus szerint “titkosította”. A kriptográfusok ezt a képletet “rejtjelnek” nevezik.”A dekódoláshoz szüksége van a kulcsra. Ez egy változó paraméter, amely meghatározza a titkosítás végső kimenetét. E paraméter nélkül lehetetlen visszafejteni a titkosítást.

ha valaki titkosított üzenetet akar olvasni, de nincs kulcsa, akkor meg kell próbálnia “feltörni” a rejtjelet. Amikor a titkosítás egyszerű betűhelyettesítő titkosítást használ, a repedés egyszerű. A titkosítás biztonságosabbá tehető, azonban a matematikai algoritmus (a rejtjel) összetettebbé tételével.

például az üzenet minden harmadik betűjét helyettesítheti a betűnek megfelelő számmal.

titkosítási kulcs hossza

a Modern számítógépes Rejtjelek nagyon összetett algoritmusok. Még a szuperszámítógépek segítségével is nagyon nehéz feltörni, ha nem is lehetetlen minden gyakorlati célra. A rejtjel erősségének mérésének legdurvább módja a létrehozásához használt algoritmus összetettsége.

minél összetettebb az algoritmus, annál nehezebb feltörni a rejtjelet az úgynevezett brute force támadással.

brute force támadás ha a támadás nagyon primitív formája (más néven kimerítő kulcskeresés), amely alapvetően magában foglalja a számok minden lehetséges kombinációjának kipróbálását, amíg meg nem találja a megfelelő kulcsot.

a számítógépek minden számítást bináris számokkal végeznek: nullákkal és egyesekkel. A rejtjel összetettsége a kulcs bitben kifejezett méretétől függ – az algoritmus kifejezéséhez szükséges egyes és nullák nyers számától, ahol minden nullát vagy egyet egyetlen bit képvisel.

ez az úgynevezett kulcs hossza, és azt is jelenti, a gyakorlati megvalósíthatóságát sikeresen teljesítő brute force támadás bármely adott rejtjel.

a lehetséges kombinációk száma (és ezért a nyers erő nehézsége) exponenciálisan növekszik a kulcs méretével. Az AES rejtjel használata (lásd később):

hogy ezt a perspektíva:

• 2011-ben a szó leggyorsabb szuperszámítógépe a Fujitsu K. Ez 10,51 petaflops Rmax csúcssebességre volt képes. Ezen adat alapján a Fujitsu K 1, 02 x 10^18 – körülbelül egymilliárd milliárd (egy kvintillió) évbe telik, hogy erővel feltörje a 128 bites AES (Advanced Encryption Standard) kulcsot. Ez régebbi, mint az univerzum kora (13,75 milliárd év).
• a világ legerősebb szuperszámítógépe (2017) A Sunway Taihulight Kínában. Ez a fenevad 93,02 petaflops csúcssebességre képes. Ez azt jelenti, hogy a világ legerősebb számítógépének még mindig körülbelül 885 kvadrillió évbe telik egy 128 bites AES kulcs brutális kényszerítése.
• a 256 bites rejtjel nyers kényszerítéséhez szükséges műveletek száma 3,31 x 10^56. Ez nagyjából megegyezik az atomok számával az univerzumban!

számítógépes Rejtjelek

míg a titkosítási kulcs hossza az érintett nyers számok mennyiségére utal, a titkosítás a matematika – a tényleges képletek vagy algoritmusok – a titkosítás végrehajtásához. Mint láttuk, a modern számítógépes Rejtjelek brutális kényszerítése vadul kivitelezhetetlen.

ezekben a titkosítási algoritmusokban a gyengeségek (néha szándékosan) vezethetnek a titkosítás megszakadásához. Ez azért van, mert a (rosszul megtervezett) titkosítás kimenete még mindig felfedhet valamilyen struktúrát az eredeti információból a titkosítás előtt. Ez csökkentett számú lehetséges kombinációt hoz létre, ami valójában csökkenti a kulcs tényleges hosszát.

a Blowfish rejtjel például sebezhető egy olyan támadással szemben, amely kihasználja a születésnapi probléma mögött rejlő matematikát a valószínűségszámításban. A kriptográfiai algoritmusok gyengeségeinek vizsgálata kriptoanalízis néven ismert.

a hosszabb kulcshossz kompenzálja az ilyen gyengeségeket, mivel ezek nagymértékben növelik a lehetséges eredmények számát.

ahelyett, hogy megtámadná magát a rejtjelet, az ellenfél megtámadhatja magát a kulcsot. Ez hatással lehet egy adott webhelyre vagy bizonyos szoftvertermékre. De a titkosítási algoritmus biztonsága még mindig sértetlen, és más rendszereket, amelyek ugyanazt az algoritmust használják, de biztonságos kulcsgenerációval rendelkeznek, a szünet nem érinti.

Rejtjelkulcs hossza

a rejtjel erőssége mind a rejtjel matematikájától, mind a bitekben kifejezett kulcshosszától függ. Emiatt a rejtjeleket általában a használt kulcshosszal együtt írják le.

tehát az AES-256 (a 256 bites kulcshosszúságú AES rejtjel) általában erősebbnek tekinthető, mint az AES-128. Ne feledje, hogy általában azért mondom, mert itt nagyon összetett matematikával van dolgunk (lásd később az AES-re vonatkozó megjegyzéseimet).

fontos megjegyezni, hogy a kulcs hossza önmagában nem jó mutatója a rejtjel erejét. A kulcshossz és a rejtjel kombinációja számít. Az aszimmetrikus titkosításhoz használt titkosítók például sokkal hosszabb kulcsméreteket használnak, mint a szimmetrikus titkosításhoz használt kulcsok, hogy egyenértékű védelmet nyújtsanak.

ez a táblázat kissé elavult, mivel nem veszi figyelembe az RSA-n felfedezett újabb támadásokat. Érdemes megjegyezni, hogy az elliptikus görbe és az RSA Diffie-Hellman változatai sokkal erősebbek, mint a hagyományosak. De remélhetőleg, megkapja az ötletet.

egy dolgot meg kell jegyezni, hogy minél nagyobb a kulcs hossza, annál nagyobb a számítás, így minél több feldolgozási teljesítmény szükséges. Ez befolyásolja az adatok titkosításának és visszafejtésének sebességét. A VPN-szolgáltatóknak és hasonló szolgáltatóknak ezért el kell dönteniük, hogyan lehet a legjobban egyensúlyba hozni a biztonságot a gyakorlati használhatósággal szemben a titkosítási sémák kiválasztásakor. Vannak olyan VPN-szolgáltatók, akiknek sikerült jól megtalálniuk ezt a finom egyensúlyt. További információkért tekintse meg a gyors VPN-ek útmutatónkat.

kicsit később tárgyaljuk a különféle VPN-protokollok által használt fő titkosításokat, de a leggyakoribb Rejtjelek, amelyekkel valószínűleg találkozni fog, a Blowfish és az AES. Ezen felül az RSA-t a rejtjel kulcsainak titkosítására és visszafejtésére használják, az SHA-1 vagy az SHA-2 pedig hash függvényként szolgál az adatok hitelesítéséhez.

aszimmetrikus titkosítás

tökéletes előre titoktartás

tökéletes előre titoktartás (PFS) is nevezik a múlandó titkosítási kulcsok, vagy csak előre titoktartás (FS) azok számára kényelmetlen a “tökéletes.”

a legtöbb modern biztonságos online kommunikáció SSL/TLS-re támaszkodik. Ezt a HTTPS weboldalak és az OpenVPN protokoll használja. A TLS (Transport Layer Security) egy aszimmetrikus titkosítási protokoll. Az aszimmetrikus rejtjel használata azt jelenti, hogy az adatokat nyilvános kulccsal védik, amelyet mindenki számára elérhetővé tesznek. Ezt azonban csak egy címzett tudja visszafejteni, aki a megfelelő privát kulccsal rendelkezik.

ezt a privát kulcsot titokban kell tartani. Ha egy ellenség ellopja vagy feltöri, akkor az ellenség könnyen elfoghatja és elolvashatja az általa biztosított kommunikációt.

sajnos gyakori, hogy a szerverek vagy akár egész vállalatok csak egy privát titkosítási kulcsot használnak az összes kommunikáció biztosításához. Miért? Mert könnyű. Ha azonban ez a kulcs veszélybe kerül, akkor a támadó hozzáférhet az összes vele titkosított kommunikációhoz.

ez a privát titkosítási kulcs tehát “mesterkulcs” lesz, amely felhasználható a szerverrel vagy céggel folytatott összes kommunikáció feloldására. Az NSA köztudottan kihasználta ezt a gyengeséget annak érdekében, hogy hatalmas mennyiségű állítólag biztonságos adatot gyűjtsön.

a megoldás tökéletes előre titoktartás. Ez egy olyan rendszer, amely minden munkamenethez új és egyedi privát titkosítási kulcsot generál. Ez egy egyszerű ötlet, még akkor is, ha a Diffie-Hellman csere matematika összetett. Ez azt jelenti, hogy minden TLS munkamenetnek saját kulcskészlete van. Ezért az “efemer kulcsok” kifejezés – egyszer használják, majd eltűnnek.

ezért nincs olyan” mesterkulcs”, amelyet ki lehetne használni. Még akkor is, ha egy munkamenet veszélybe kerül, csak az a munkamenet sérül – nem az összes többi munkamenet, amelyet bárki az adott szerverrel vagy céggel folytat!

bár nem gyakori, még a PFS kulcsok frissítése is lehetséges egy munkameneten belül (például óránként). Ez tovább korlátozza az ellenség által elfogható adatok mennyiségét, még akkor is, ha egy privát kulcs veszélybe kerül.

amikor néhány évvel ezelőtt írtam ezt a cikket a témáról, a tökéletes továbbítási titoktartás használata mind a HTTPS webhelyek, mind az OpenVPN kapcsolatok számára siralmasan ritka volt. Szerencsére ez a helyzet némileg megváltozott. Bár korántsem univerzális, az efemer kulcsok használata későn jelentősen megnőtt.

VPN titkosítási protokollok

a VPN protokoll az utasítások (mechanizmus) összessége, amelyet két számítógép közötti biztonságos titkosított kapcsolat megtárgyalására használnak. Számos ilyen VPN protokollt általában támogatnak a kereskedelmi VPN szolgáltatások. Ezek közül a legjelentősebbek a PPTP, az L2TP/IPSec, az OpenVPN, az SSTP és az IKEv2.

az alábbiakban mindegyiket megnézem, de az OpenVPN ma már az ipari szabvány VPN protokoll, amelyet a kereskedelmi VPN – szolgáltatások használnak-jó okból. Nagyon biztonságos, és szinte minden VPN-képes eszközön használható. Ezért további digitális tintát fogok költeni az OpenVPN részletes megvitatására.

PPTP

PROS

• Client beépített szinte minden platformon
• nagyon könnyű beállítani

CONS

• nagyon bizonytalan
• határozottan kompromittálta a NSA
• könnyen blokkolható

mi a PPTP?

ez csak egy VPN protokoll, és különféle hitelesítési módszerekre támaszkodik a biztonság érdekében. A kereskedelmi VPN-szolgáltatók között ez szinte mindig az MS-CHAP v2. A PPTP által használt titkosítási protokoll (hasonlóan a szokásos titkosításhoz) a Microsoft Point-to-Point Encryption (MPPE).

a point-to-Point Tunneling protokollt (PPTP) A Microsoft által alapított konzorcium fejlesztette ki VPN telefonos hálózatokon keresztül történő létrehozására. Mint ilyen, a PPTP már régóta a vállalati VPN-hálózatok szabványos protokollja.

a PPTP alapkivitelben szinte minden VPN-képes platformon és eszközön elérhető. Könnyen beállítható, további szoftver telepítése nélkül. Ez biztosítja, hogy a PPTP továbbra is népszerű választás mind az üzleti VPN-ek, mind a kereskedelmi VPN-szolgáltatások számára.

ennek az az előnye is, hogy alacsony számítási költségeket igényel a megvalósításhoz … tehát gyors!

sajnos a PPTP nem biztonságos. Egyáltalán. Bár manapság általában csak 128 bites titkosítási kulcsokat használnak, azokban az években, amikor először csomagolták a Windows 95 OSR2-hez 1999-ben, számos biztonsági rés derült fényre.

ezek közül a legsúlyosabb a nem kapszulázott MS-CHAP v2 hitelesítés lehetősége. Ezzel a kihasználással a PPTP-t két napon belül feltörték. A Microsoft javította a hibát, de maga is ajánlást adott ki az L2TP/IPsec vagy az SSTP használatára.

nem meglepő, hogy az NSA szinte biztosan dekódolja a PPTP titkosított kommunikációt. Még ennél is aggasztóbb, hogy az NSA hatalmas mennyiségű régebbi adatot gyűjtött, amelyeket titkosítottak, amikor a PPTP-t biztonságosnak tekintették. Szinte biztosan visszafejtheti ezeket a régi adatokat is.

a PPTP mind az 1723-as TCP portot, mind a GRE protokollt igényli. Ez könnyen tűzfal GRE, ami megkönnyíti, hogy blokkolja PPTP kapcsolatokat.

L2TP / IPsec

előnyök

• általában biztonságosnak tekinthető
• könnyen beállítható
• minden modern platformon elérhető
• gyorsabb, mint az OpenVPN (talán)

hátrányok

• az NSA veszélyeztetheti (nem bizonyított)
• valószínűleg szándékosan gyengíti az NSA (nem bizonyított)
• küzdhet a korlátozó tűzfalakkal
• gyakran rosszul hajtják végre

mi az L2TP és IPsec?

a Layer 2 Tunneling Protocol (L2TP) szinte minden modern operációs rendszerbe és VPN-képes eszközbe be van építve. Ezért ugyanolyan egyszerű és gyors a beállítás, mint a PPTP.

önmagában az L2TP nem nyújt titkosítást vagy titoktartást a rajta áthaladó forgalom számára, ezért általában az IPsec hitelesítési csomaggal (L2TP/IPsec) valósítják meg. Még akkor is, ha a Szolgáltató csak az L2TP-re vagy az IPsec-re hivatkozik (mint egyesek), ez szinte biztosan L2TP/IPSec-et jelent.

az L2TP/IPsec használhatja a 3DES vagy AES titkosítást. A 3DES sebezhető a Meet-in-the-middle és a Sweet32 ütközési támadásokkal szemben, így a gyakorlatban nem valószínű, hogy manapság találkozol vele.

problémák merülhetnek fel, mert az L2TP/IPSec protokoll csak korlátozott számú portot használ. Ez komplikációkat okozhat, ha a NAT tűzfalak mögött használják. Ez a rögzített portokra való támaszkodás a protokollt is meglehetősen könnyű blokkolni.

az L2TP/IPsec kétszer foglalja magába az adatokat, ami lelassítja a dolgokat. Ezt ellensúlyozza az a tény, hogy a titkosítás/dekódolás a kernelben történik, az L2TP/IPsec pedig lehetővé teszi a többszálú írást. Az OpenVPN nem. Az eredmény az, hogy az L2TP/IPsec elméletileg gyorsabb, mint az OpenVPN.

az AES titkosítást használó L2TP/IPsec-nek nincs jelentős ismert biztonsági rése, és ha megfelelően alkalmazzák, akkor is biztonságos lehet. Edward Snowden kinyilatkoztatásai azonban határozottan utaltak arra, hogy az NSA veszélyezteti a szabványt.

John Gilmore biztonsági szakértő és az Electronic Frontier Foundation alapító tagja. Elmagyarázza, valószínű, hogy az IPSec szándékosan gyengült a tervezési szakaszban.

vitathatatlanul sokkal nagyobb probléma az, hogy sok VPN-szolgáltatás rosszul hajtja végre az L2TP/IPsec-et. Pontosabban, előre megosztott kulcsokat (PSK-ket) használnak, amelyek szabadon letölthetők a webhelyeikről.

ezek a PSK-k csak a kapcsolat hitelesítésére szolgálnak, így még akkor is, ha veszélybe kerülnek, az adatok biztonságosan titkosítva maradnak az AES segítségével. A támadó azonban az előre megosztott kulcs segítségével megszemélyesítheti a VPN-kiszolgálót. Ezután lehallgathatja a titkosított forgalmat, vagy akár rosszindulatú adatokat is bejuttathat a kapcsolatba.

Összegzés

néhány nagyrészt elméleti kérdés ellenére az L2TP/IPsec általában biztonságosnak tekinthető, ha nyíltan közzétett előre megosztott kulcsokat nem használnak. A beépített kompatibilitás sok eszközzel Nagyon jó választás lehet.

SSTP

előnyök

• nagyon biztonságos
• teljesen integrált Windows
• Microsoft támogatás
• képes megkerülni a legtöbb tűzfalat

hátrányok

• a Microsoft tulajdonában lévő saját szabvány

mi az SSTP?

az SSTP egy olyan típusú titkosítás, amely SSL 3.0-t használ, és hasonló előnyöket kínál, mint az OpenVPN. Ez magában foglalja a 443-as TCP port használatának lehetőségét a cenzúra elkerülésére. A Windows-szal való szoros integráció megkönnyítheti a használatát és stabilabb, mint az OpenVPN ezen a platformon.

az OpenVPN-től eltérően azonban az SSTP a Microsoft tulajdonában lévő saját szabvány. Ez azt jelenti, hogy a Kódex nem nyilvános ellenőrzés. A Microsoft NSA-val való együttműködésének története, valamint a Windows operációs rendszerbe beépített lehetséges hátsó ajtókkal kapcsolatos spekulációk nem keltenek bizalmat a szabványban.

a Secure Socket Tunneling Protocol (SSTP) protokollt a Microsoft vezette be a Windows Vista SP1 szervizcsomagban. Bár már elérhető a Linux VPN-ekhez, sőt a Mac OS X-hez is, továbbra is elsősorban csak Windows platform.

egy másik probléma az, hogy az SSL v3.0 sebezhető az uszkár támadásnak, ezért most nem ajánlott. Nem világos, hogy ez a kérdés az SSTP-t is érinti-e, de ismét alig inspirálja a bizalmat.

Összegzés

papíron az SSTP az OpenVPN számos előnyét kínálja. A Microsoft saját szabványa azonban súlyosan aláássa hitelességét.

IKEv2

előnyök

• gyors
• stabil-különösen akkor, ha hálózati kapcsolást vagy újracsatlakozást követően Elveszett internetkapcsolat
• biztonságos (ha AES-t használnak)
• könnyen beállítható (legalább a felhasználó végén!)
• protokoll támogatja a Blackberry készülékek

CONS

• nem támogatott sok platformon
• végrehajtási IKEv2 a szerver végén trükkös, ami valami, ami potenciálisan eredményezhet problémák fejlesztése
• csak a bizalom nyílt forráskódú megvalósítások

mi az IKEv2?

az Internet Key Exchange 2-es verzióját (IKEv2) a Microsoft és a Cisco közösen fejlesztette ki. Natív módon támogatja a Windows 7+, a Blackberry és az iOS eszközök. Ez az oka annak, hogy sok iOS VPN szolgáltatás az IKEv2-t használja az OpenVPN helyett.

az IKEv2 független fejlesztésű kompatibilis verzióit Linux és más operációs rendszerek számára fejlesztették ki. Ezen iterációk közül sok nyílt forráskódú. Mint mindig, azt javaslom, hogy vigyázzon a Microsoft által kifejlesztett dolgokra. Az IKEv2 nyílt forráskódú verzióinak azonban nem lehetnek problémái.

az IKEv2 az IPsec protokollcsomag része. Biztosítja a forgalom biztonságát azáltal, hogy átadja az SA (Security Association) attribútumot az IPsec-en belül, és sok szempontból javítja az IKEv1-et. IKEv2 így néha nevezik IKEv2 / IPsec. Az IKEv1-et viszont gyakran egyszerűen IPsec-nek nevezik.

a Microsoft által VPN Connect-nek nevezett IKEv2 különösen jó a VPN-kapcsolat automatikus helyreállításában, amikor a felhasználók ideiglenesen elveszítik internetkapcsolatukat. Például, amikor belép vagy elhagyja a vonat alagútját.

a mobility and Multihoming (MOBIKE) protokoll támogatása miatt az IKEv2 rendkívül rugalmas a változó hálózatokkal szemben. Ez teszi az IKEv2-t nagyszerű választássá azoknak a mobiltelefon-használóknak, akik rendszeresen váltanak az otthoni WiFi és a mobil kapcsolatok között, vagy akik rendszeresen mozognak a hotspotok között.

az IKEv2 nem olyan gyakori, mint az L2TP/IPSec, mivel sokkal kevesebb platformon támogatott (bár ez a helyzet gyorsan változik). Ez azonban legalább olyan jó, ha nem jobb, mint az L2TP/IPsec a biztonság, a teljesítmény (sebesség), a stabilitás és a kapcsolat létrehozásának (és helyreállításának) képessége szempontjából.

OpenVPN

előnyök

• nagyon biztonságos (ha PFS-t használnak)
• jól konfigurálható
• nyílt forráskódú
• képes megkerülni a tűzfalakat
• harmadik féltől származó szoftverre van szüksége

mi az OpenVPN?

az OpenVPN egy nyílt forráskódú technológia, amely az OpenSSL könyvtárat és a TLS protokollokat használja, valamint más technológiák ötvözetét, hogy erős és megbízható VPN megoldást biztosítson. Ez most az ipari szabvány VPN protokoll, amelyet a kereskedelmi VPN-szolgáltatások használnak-jó okból.

az OpenVPN egyik fő erőssége, hogy nagyon konfigurálható. Natív módon egyetlen platform sem támogatja, de a legtöbb platformon harmadik féltől származó szoftveren keresztül érhető el. Az egyedi OpenVPN kliensek és alkalmazások gyakran elérhetők az egyes VPN-szolgáltatóktól, de az alapvető nyílt forráskódot az OpenVPN projekt fejlesztette ki.

az OpenVPN projekt számos fejlesztője és közreműködője az OpenVPN Technologies Inc. – nek is dolgozik., amely felügyeli a projektet.

az OpenVPN UDP porton fut a legjobban, de beállítható úgy, hogy bármely porton fusson (lásd a későbbi megjegyzéseket). Ez magában foglalja a 443-as TCP portot, amelyet a rendszeres HTTPS forgalom használ. Az OpenVPN futtatása a 443-as TCP porton keresztül megnehezíti a VPN-kapcsolatok megkülönböztetését a bankok, az e-mail szolgáltatások és az online kiskereskedők által használt biztonságos kapcsolatoktól. Ez nagyon megnehezíti az OpenVPN blokkolását.

az OpenVPN másik előnye, hogy a titkosításhoz használt OpenSSL könyvtár számos titkosítást támogat. A gyakorlatban azonban csak a Blowfish-t és az AES-t használják általában a kereskedelmi VPN-szolgáltatások. Ezeket az alábbiakban tárgyalom.

az Edward Snowdentől kapott információk fényében úgy tűnik, hogy amíg a Perfect Forward titoktartást használják, addig az OpenVPN-t az NSA nem veszélyeztette vagy gyengítette.

az OpenVPN nemrégiben végzett tömeges ellenőrzése befejeződött, csakúgy, mint egy másik, a privát Internet-hozzáféréssel finanszírozott audit. Nem fedeztek fel olyan súlyos sebezhetőségeket, amelyek befolyásolják a felhasználók magánéletét. Néhány sebezhetőséget fedeztek fel, amelyek miatt az OpenVPN szerverek potenciálisan nyitottak a szolgáltatásmegtagadási (dos) támadásokra, de ezeket az OpenVPN 2.4.2-ben javították.

az OpenVPN-t általában az elérhető legbiztonságosabb VPN-protokollnak tekintik, és széles körben támogatott a VPN-iparban. Ezért az alábbiakban részletesen megvitatom az OpenVPN titkosítást.

OpenVPN titkosítás

az OpenVPN titkosítás két részből áll – adatcsatorna titkosítás és vezérlőcsatorna titkosítás. Az adatcsatorna titkosítását az adatok védelmére használják. A vezérlőcsatorna-titkosítás biztosítja a kapcsolatot a számítógép és a VPN-kiszolgáló között.

bármely védelem csak annyira erős, mint a leggyengébb pontja, ezért sajnálatos, hogy egyes VPN-szolgáltatók sokkal erősebb titkosítást használnak az egyik csatornán, mint a másikon (általában erősebb a vezérlőcsatornán).

nem ritka például, hogy egy VPN-szolgáltatást AES-256 titkosítással, RSA-4096 kézfogás titkosítással és SHA-512 hash hitelesítéssel hirdetnek. Ez nagyon lenyűgözően hangzik, amíg rájössz, hogy csak a vezérlőcsatorna titkosítására vonatkozik, nem pedig az adatcsatornára, amelyet pusztán Blowfish-128 titkosít SHA1 hash hitelesítéssel. Ez csak marketing okokból történik.

ha eltérő titkosítást használunk az adat-és vezérlőcsatornákon, akkor az OpenVPN kapcsolat valódi erősségét a gyengébb titkosítási csomag méri.

a maximális biztonság érdekében mind az adat -, mind a vezérlőcsatorna-titkosításnak a lehető legerősebbnek kell lennie. Minél erősebb a használt titkosítás, annál lassabb lesz a kapcsolat, ezért egyes szolgáltatók az adatcsatorna-titkosítással foglalkoznak.

a vezérlőcsatorna-titkosítást TLS-titkosításnak is nevezik, mivel a TLS az a technológia, amelyet a számítógép és a VPN-kiszolgáló közötti kapcsolat biztonságos egyeztetésére használnak. Ez ugyanaz a technológia, amelyet a böngésző használ a HTTPS-titkosított webhelyhez való kapcsolat biztonságos tárgyalására.

• a vezérlőcsatorna-titkosítás titkosításból, kézfogás-titkosításból és hash-hitelesítésből áll.
• az adatcsatorna-titkosítás titkosításból és hash-hitelesítésből áll.

a VPN-szolgáltatók gyakran ugyanazt a titkosítási szintet használják mind a vezérlési, mind az adatcsatornákhoz. Áttekintéseinkben és a” közlekedési lámpa ” táblázatokban csak külön soroljuk fel őket, ha minden csatornához különböző értékeket használunk.

ha kijelentjük, hogy egy szolgáltató AES-256 rejtjelet használ, ez azt jelenti, hogy az AES-256 rejtjelet használják mind a vezérlő, mind az adatcsatornákhoz.*

(*legalább ennek kell lennie. Egyes régebbi felülvizsgálatok nem felelnek meg a jelenlegi Irányelveinknek, de ezeket időben meg kell szüntetni).

Rejtjelek

az OpenVPN számos szimmetrikus kulcsú rejtjelet használhat az adatok védelme érdekében mind a vezérlő, mind az adatcsatornákon. A gyakorlatban a kereskedelmi VPN-szolgáltatók csak a Blowfish, az AES és (nagyon ritkán) Camellia használják.

Blowfish

a Blowfish-128 az OpenVPN által használt alapértelmezett titkosítás. A kulcsméretek elméletileg 32 bittől 448 bitig terjedhetnek, de a Blowfish-128 az egyetlen verzió, amellyel valószínűleg találkozni fog a vadonban.

a Gömbhalat gyakran elég biztonságosnak tekintik alkalmi célokra, de ismert gyengeségei vannak. A híres kriptográfus, Bruce Schneier hozta létre, aki 2007-ben azt mondta: “ezen a ponton azonban csodálkozom, hogy még mindig használják.”

véleményünk szerint a Blowfish-128 használata elfogadható második védelmi vonalként az OpenVPN adatcsatornán. Nem szabad azonban biztonságosnak tekinteni, ha a vezérlőcsatornán használják.

AES

az AES az egész iparágra kiterjedő “arany standard” szimmetrikus kulcsú titkosítássá vált. Az AES NIST-tanúsítvánnyal rendelkezik, és szinte egyetemesen nagyon biztonságosnak tekinthető. Az AES-256-ot az Egyesült Államok kormánya használja a “biztonságos” adatok védelmére.

az a tény, hogy 128 bites blokkmérettel rendelkezik, nem pedig a Blowfish 64 bites blokkméretével, azt is jelenti, hogy nagyobb (4 GB feletti) fájlokat képes jobban kezelni, mint a Blowfish. Ezen felül az AES utasításkészlet előnye a beépített hardveres gyorsítás a legtöbb platformon.

az AES általában 128 bites és 256 bites kulcsméretekben érhető el (192 bites AES is létezik). Az AES-128 továbbra is biztonságos, amennyire bárki tudja. Tekintettel arra, amit most tudunk az NSA titkosítási szabványok elleni támadásának mértékéről, a legtöbb szakértő egyetért abban, hogy az AES-256 magasabb biztonsági mozgásteret biztosít.

csak annak biztosítása érdekében, hogy soha senki ne találja ezt a témát túl könnyűnek, bár van némi vita ebben a kérdésben. Az AES-128 erősebb kulcsfontosságú ütemezéssel rendelkezik, mint az AES-256, ami néhány nagyon kiemelkedő szakértőt arra késztet, hogy az AES-128 valójában erősebb, mint az AES-256.

az általános konszenzus azonban az, hogy az AES-256 erősebb.

Camellia

Camellia egy modern biztonságos rejtjel, és legalább olyan biztonságos és gyors, mint az AES. 128, 192 és 256 bites kulcsméretekben kapható. A NIST tanúsításnak és az amerikai kormány általi használatának köszönhetően azonban az AES-t szinte mindig a Camellia helyett használják.

de ahogy az alábbiakban tárgyalom, vannak okok arra, hogy ne bízzunk a NIST által tanúsított titkosításokban. Az a tény, hogy a Camellia nem NIST rejtjel, a fő oka annak, hogy az AES helyett válasszuk. Ez a lehetőség azonban csak ritkán áll rendelkezésre.

azt is érdemes megjegyezni, hogy a Camellia közel sem olyan jól tesztelt gyengeség, mint az AES.

kézfogás titkosítás

annak érdekében, hogy biztonságosan tárgyaljon a készülék és a VPN-kiszolgáló közötti kapcsolatról, az OpenVPN TLS kézfogást használ. Ez lehetővé teszi az OpenVPN kliens és a VPN szerver számára, hogy létrehozzák a titkos kulcsokat, amelyekkel kommunikálnak.

a kézfogás védelme érdekében a TLS általában az RSA nyilvános kulcsú kriptorendszert használja. Ez egy titkosítási és digitális aláírási algoritmus, amelyet a TLS/SSL tanúsítványok azonosítására használnak. Használhat azonban Diffie-Hellman vagy ECDH kulcscserét is.

RSA

az RSA aszimmetrikus titkosítási rendszer – nyilvános kulcsot használnak az adatok titkosításához, de egy másik privát kulcsot használnak az adatok visszafejtéséhez. Ez volt az alapja a biztonság az interneten az elmúlt 20 évben, vagy úgy.

most már jól megalapozott, hogy az 1024 bites (RSA-1024) vagy annál kisebb kulcshosszúságú RSA nem biztonságos, és az NSA szinte biztosan feltörte. Következésképpen összehangolt lépés történt az internetes vállalatok között az RSA-1024-ről való áttérés érdekében.

sajnos még mindig találunk néhány VPN szolgáltatást, amelyek továbbra is az RSA-1024-et használják a kézfogások védelmére. Ez nem jó.

az RSA-2048 vagy újabb még mindig biztonságosnak tekinthető. Az RSA önmagában nem nyújt tökéletes előre titoktartást (PFS). Ez azonban megvalósítható egy Diffie-Hellman (DH) vagy elliptikus görbe beillesztésével Diffie-Hellman (ECDH) KULCSCSERE rejtjelkészletében.

ebben az esetben a DH vagy ECDH kulcs erőssége nem számít, mivel csak a tökéletes továbbítási titoktartás biztosítására használják. A kapcsolat RSA segítségével biztosított.

mivel zavart okozhat, azt is megjegyzem, hogy az RSA kriptorendszernek semmi köze nincs a szégyenteljes amerikai technológiai céghez, az RSA Security LLC-hez. Ez a vállalat szándékosan gyengítette zászlóshajóját, a BSAFE titkosítási termékeket, miután az NSA 10 millió dollárt megvesztegetett.

Diffie-Hellman and ECDH

az OpenVPN által néha használt alternatív (rivális) kézfogás titkosítás a Diffie-Hellman (DH) kriptográfiai KULCSCSERE. Ennek kulcshossza általában 2048 bit vagy 4096 bit. Ne feledje, hogy a DH-2048-nál kevesebbet el kell kerülni a logjam támadásra való hajlam miatt.

a Diffie-Hellman kézfogás fő előnye az RSA-val szemben, hogy natív módon tökéletes előre titoktartást biztosít. Mint már említettük, azonban, ha egyszerűen hozzáadunk egy DH kulcscserét egy RSA kézfogáshoz, hasonló véget ér.

a Diffie-Hellman hatalmas vitát váltott ki a korlátozott prímszámok újrafelhasználása miatt. Ez sebezhetővé teszi, hogy egy hatalmas ellenfél, például az NSA feltörje. A Diffie-Hellman önmagában tehát nem teszi lehetővé a biztonságos kézfogás titkosítást. Ez rendben van, azonban, ha részeként használják egy RSA titkosító suite.

elliptikus görbe a Diffie-Hellman (ECDH) a kriptográfia újabb formája, amely nem érzékeny erre a támadásra. Ennek oka az, hogy a kapcsolatok titkosításához nagy prímszámok helyett egy adott típusú algebrai görbe tulajdonságait használja.

az ECDH az RSA kézfogás részeként használható a tökéletes továbbítási titoktartás érdekében, vagy biztonságosan titkosíthatja a kézfogást önmagában (ECDSA aláírással). Ez PFS-t is biztosít.

az ECDH kulcs hossza 384 bitnél kezdődik. Ezt biztonságosnak tekintik, de ha önmagában használják a TLS kézfogás biztosítására, annál hosszabb, annál jobb (a biztonság szempontjából egyébként).

SHA Hash hitelesítés

ezt adathitelesítésnek vagy hash üzenet hitelesítési kódnak (HMAC) is nevezik.

a Secure Hash Algorithm (Sha) egy kriptográfiai hash függvény, amelyet (többek között) az adatok és az SSL/TLS kapcsolatok hitelesítésére használnak. Ez magában foglalja az OpenVPN kapcsolatokat.

létrehoz egy érvényes TLS tanúsítvány egyedi ujjlenyomatát, amelyet bármely OpenVPN kliens érvényesíthet. Még a legkisebb változás is kimutatható. Ha a tanúsítványt meghamisítják, akkor ez azonnal észlelhető, és a kapcsolat elutasításra kerül.

ez fontos egy MITM (Man-in-the-middle) támadás megelőzésében, amikor egy ellenfél megpróbálja átirányítani az OpenVPN kapcsolatot az egyik saját szerverére a VPN szolgáltató helyett. Ezt megteheti például az útválasztó feltörésével.

ha egy ellenfél feltörheti a Szolgáltató eredeti TLS-tanúsítványának kivonatát, megfordíthatja a kivonatot, hogy hamis tanúsítványt hozzon létre. Az Open VPN szoftver ezután hitelesíti a kapcsolatot valódiként.

az SHA biztonságos?

ha HTTPS-webhelyek védelmére használják, az SHA-1 hibás. Ez már ismert egy ideje. Az SHA-1 weboldalak továbbra is megtalálhatók, de fokozatosan megszűnnek. A legtöbb böngésző most figyelmeztetést ad ki, amikor megpróbál csatlakozni egy SHA-1-gyel védett webhelyhez.

az SHA-2 és az SHA-3 hash funkciók most ajánlottak, és biztonságosak. Az SHA-2 magában foglalja az SHA-256-ot, az SHA-384-et és az SHA-512-t. Azonban …

az OpenVPN csak az SHA-t használja a HMAC-hez. Nem hiszem, hogy hasznos itt túl sok részletbe belemenni, de az SHA hash hitelesítés a HMAC algoritmus része. Az SHA-1-be ágyazott HMAC megtámadása sokkal nehezebb, mint maga az SHA-1 hash funkció megtámadása.

más szavakkal, az OpenVPN által használt HMAC SHA-1 biztonságosnak tekinthető, és ennek matematikai bizonyítéka van. Természetesen a HMAC SHA-2 és a HMAC SHA-3 még biztonságosabbak! Valójában a legutóbbi OpenVPN audit elismeri, hogy a HMAC SHA-1 biztonságos, de inkább a HMAC SHA-2-re vagy a HMAC SHA-3-ra való áttérést javasolja.

Megjegyzések

NIST

az AES-t, az RSA-t, az SHA-1-et és az SHA-2-t az Egyesült Államok Nemzeti Szabványügyi és technológiai Intézete (NIST) fejlesztette ki és/vagy hitelesítette. Ez egy olyan testület, amely saját bevallása szerint szorosan együttműködik az NSA-val A Rejtjelek fejlesztésében.

tekintettel arra, amit most tudunk az NSA szisztematikus erőfeszítéseiről, hogy gyengítse vagy beépítse a hátsó ajtókat a nemzetközi titkosítási szabványokba, minden okunk megkérdőjelezni a NIST algoritmusok integritását.

a NIST természetesen határozottan cáfolja az ilyen állításokat:

“a NIST szándékosan nem gyengítené a kriptográfiai szabványt.”

azt is felkérte a nyilvánosság részvételét számos közelgő javasolt titkosítási szabványok, a lépés célja, hogy erősítse a közbizalmat.

a New York Times azonban azzal vádolta az NSA-t, hogy megkerülte a NIST által jóváhagyott titkosítási szabványokat azáltal, hogy észrevehetetlen hátsó ajtókat vezetett be, vagy felforgatta a nyilvános fejlesztési folyamatot az algoritmusok gyengítése érdekében.

ezt a bizalmatlanságot tovább erősítette, amikor az RSA Security (az EMC egyik részlege) magántulajdonban azt mondta az ügyfeleknek, hogy hagyják abba a titkosítási algoritmus használatát, amely állítólag az NSA által tervezett hibát tartalmaz. Ezt az algoritmust a NIST is jóváhagyta.

továbbá, Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) egy titkosítási szabvány által tervezett NIST. Évek óta ismert, hogy bizonytalan.

2006-ban a hollandiai Eindhoveni Műszaki Egyetem megjegyezte, hogy az ellene irányuló támadást elég könnyű elindítani “egy közönséges számítógépen.”A Microsoft mérnökei egy feltételezett hátsó ajtót is megjelöltek az algoritmusban.

ezen aggodalmak ellenére, ahol a NIST vezet, az ipar követi. A Microsoft, a Cisco, a Symantec és az RSA egyaránt tartalmazza az algoritmust a termékük kriptográfiai könyvtáraiban. Ez nagyrészt azért van, mert a NIST szabványoknak való megfelelés előfeltétele az amerikai kormányzati szerződések megszerzésének.

a NIST által tanúsított kriptográfiai szabványok világszerte szinte mindenütt jelen vannak, az ipar és az üzleti élet minden területén, amelyek a magánéletre támaszkodnak. Ez az egész helyzetet meglehetősen hűvössé teszi.

talán éppen azért, mert annyira támaszkodik ezekre a szabványokra, a kriptográfiai szakértők nem voltak hajlandók szembenézni a problémával.

AES-CBC vs AES-GCM

a közelmúltig az egyetlen AES titkosítás, amellyel valószínűleg találkozott a VPN-világban, az AES-CBC (Cipher Block Chaining) volt. Ez a blokk titkosítási módra utal, egy összetett témára, amelybe nem igazán érdemes belemenni. Bár a CBC-nek elméletileg lehetnek bizonyos sebezhetőségei, az általános konszenzus az, hogy a CBC biztonságos. A CBC valóban ajánlott az OpenVPN kézikönyvben.

OpenVPN most is támogatja az AES-GCM (Galios/Counter mód).

• a GCM hitelesítést biztosít, így nincs szükség HMAC SHA hash funkcióra.
• szintén valamivel gyorsabb, mint a CBC, mert hardveres gyorsítást használ (több processzormagba történő befűzéssel).

az AES-CBC továbbra is a leggyakoribb mód az általános használatban, de most kezdünk találkozni AES-GCM “a vadonban.”Tekintettel a GCM előnyeire, ez a tendencia valószínűleg csak folytatódni fog. Kriptográfiai szempontból a tho9ugh, mind az AES-CBC, mind az AES-GCM nagyon biztonságos.

OpenVPN UDP vs.OpenVPN TCP

az OpenVPN futtatható TCP-n (Transmission Control Protocol) vagy UDP-n (User Datagram Protocol) keresztül.

• TCP = megbízható. Amikor egy számítógép hálózati csomagot küld a TCP használatával, a következő csomag elküldése előtt megvárja annak megerősítését, hogy a csomag megérkezett. Ha nem érkezik megerősítés, akkor újra elküldi a csomagot. Ezt nevezik hibajavításnak. Minden adat “garantált kézbesítése” van, de elég lassú lehet.
• UDP = gyors. Az UDP használatával nem történik ilyen hibajavítás. A csomagokat egyszerűen elküldik és fogadják nyugtázás vagy újrapróbálkozás nélkül. Ez az UDP-t sokkal gyorsabbá teszi, mint a TCP, de kevésbé megbízható.

ha megadják a választást, javaslom a gyorsabb UDP protokoll használatát, hacsak nem tapasztal csatlakozási problémákat. Ez a legtöbb VPN-szolgáltató által elfogadott alapértelmezett stratégia.

győzd le a cenzúrát az OpenVPN-nel A 443-as TCP porton

az OpenVPN egyik nagy előnye, hogy bármilyen porton futtatható, beleértve a 443-as TCP portot is. Ezt a portot használja a HTTPS, a titkosított protokoll, amely biztosítja az összes biztonságos webhelyet.

HTTPS nélkül az online kereskedelem semmilyen formája, például vásárlás vagy banki tevékenység nem lenne lehetséges. Ezért nagyon ritka, hogy ezt a portot blokkolják.

bónuszként a 443-as TCP porton lévő VPN-forgalom a TLS titkosításon belül ugyanúgy irányítható, mint a HTTPS. Ez sokkal nehezebbé teszi a fejlett mély Csomagellenőrzési technikák használatát. A 443-as TCP-port tehát a VPN-blokkok elkerülésének kedvelt portja.

számos VPN-szolgáltató lehetővé teszi az OpenVPN által használt portszám megváltoztatását az egyedi szoftverük segítségével.

még ha a tiéd nem is, sok VPN-szolgáltató valóban támogatja az OpenVPN-t a 443-as TCP port használatával szerver szinten. Válthat rá egy egyszerű szerkesztéssel az OpenVPN konfigurációjára (.ovpn) fájl. Ezért érdemes erről megkérdezni a VPN szolgáltatót.

érdemes megjegyezni, hogy a hálózati mérnökök nem szeretik ezt a taktikát, mivel a TCP a TCP felett nagyon nem hatékony. A cenzúra legyőzésekor azonban gyakran működik.

az SSTP alapértelmezés szerint a 443-as TCP portot használja.

összefoglalók

VPN protokollok

• a PPTP nagyon bizonytalan, ezért kerülni kell. Míg a könnyű telepítés és a platformok közötti kompatibilitás vonzó, az L2TP / IPsec ugyanolyan előnyökkel rendelkezik, és sokkal biztonságosabb.
• az L2TP/IPsec egy jó VPN megoldás nem kritikus használatra. Ez különösen igaz azokra a régi eszközökre, amelyek nem támogatják az OpenVPN-t. Ezt azonban az NSA súlyosan veszélyeztette.
• az SSTP az OpenVPN legtöbb előnyét kínálja, de elsősorban csak egy Windows protokoll. Ez azt jelenti, hogy jobban integrálódik az operációs rendszerbe, de ennek a korlátozásnak köszönhetően a VPN-szolgáltatók rosszul támogatják. Ezen túlmenően a tulajdonosi jellege és az a tény, hogy a Microsoft hozta létre, azt jelenti, hogy én, az egyik, nem bízom benne.
• az IKEv2 egy nagyon jó (biztonságos és gyors) protokoll. Különösen a mobil felhasználók előnyben részesíthetik az OpenVPN-t, mivel javult az újracsatlakozás képessége, amikor az internetkapcsolat megszakad. A Blackberry felhasználók számára ez nagyjából az egyetlen elérhető lehetőség. Használjon nyílt forráskódú verziókat, ahol lehetséges.
• az OpenVPN az ajánlott VPN protokoll a legtöbb esetben. Gyors, megbízható, biztonságos és nyílt forráskódú. Nincs igazi hátránya, önmagában., de ahhoz, hogy valóban biztonságos legyen, fontos, hogy jól megvalósítsák. Ez azt jelenti, erős titkosítás tökéletes előre titoktartás.

OpenVPN titkosítás

amikor a titkosításról van szó, az ördög a részletekben rejlik. Gyakori, hogy a VPN-szolgáltatók azt mondják, hogy “rendkívül erős 256 bites” AES OpenVPN titkosítást használnak, de ez a valóságban nem sokat mond nekünk. Az AES-256 valóban erős titkosítás, de ha a használt titkosítási csomag más szempontjai gyengék, akkor az adatok nem lesznek biztonságosak.

• Cipher – ez védi a tényleges adatokat. Az AES-256 ma már az ipari szabvány, ezért ajánlott.
• kézfogás – ez biztosítja a kapcsolatot a VPN-kiszolgálóval. Az RSA-2048+ vagy az ECDH-384 + biztonságos. Fontos, hogy az RSA – 1024 és a Diffie-Hellman kézfogások nem.
• Hash hitelesítés – létrehoz egy egyedi ujjlenyomatot, amelyet az adatok és a TLS-tanúsítványok érvényesítésére használnak (vagyis annak ellenőrzésére, hogy a kiszolgáló, amelyhez csatlakozik, valóban az, amelyhez úgy gondolja, hogy csatlakozik). A HMAC SHA-1 teljesen rendben van, de a HMAC SHA-2 (SHA-256, SHA-384 és SHA-512) és a HMAC SHA-3 még biztonságosabbak! Vegye figyelembe, hogy a hash hitelesítés nem szükséges, ha az AES-GCM rejtjelet használják.
• Perfect Forward Secrecy (PFS) – ez biztosítja, hogy minden munkamenethez új titkosítási kulcsok jöjjenek létre. Az OpenVPN csak akkor tekinthető biztonságosnak, ha a PFS implementálva van. Ez megtehető úgy, hogy egy Diffie-Hellman vagy ECDH kulcscserét RSA kézfogásba, vagy DH vagy ECDH kézfogásba foglal.
• a Titkosítás csak annyira biztonságos, mint a leggyengébb pontja. Ez azt jelenti, hogy a titkosítási beállításoknak erősnek kell lenniük mind az adat -, mind a vezérlőcsatornákon.
• a nagyobb bithossz használata rejtjelekhez és kulcsokhoz szinte mindig biztonságosabb, de ennek ára van a sebességben.

az OpenVPN a kliens és a szerver közötti titkosításokat tetszés szerint tárgyalja. Hacsak nagyon specifikus paramétereket nem határozunk meg, az OpenVPN alapértelmezés szerint gyenge beállításokat adhat meg. Legalább az OpenVPN alapértelmezés szerint Blowfish-128 cipher, RSA-1024 kézfogás PFS nélkül, és HMAC SHA-1 hash hitelesítés.

következtetés

remélhetőleg most már jobban megérti, mi teszi a biztonságos VPN-kapcsolatot. A VPN megfelelő konfigurálásakor azonban a titkosítás csak a történet fele. A másik fele biztosítja, hogy a VPN-kapcsolaton kívül ne kerüljön forgalom a számítógépbe vagy hagyja el.

ha többet szeretne megtudni erről, kérjük, olvassa el az IP-szivárgások teljes útmutatóját.