A teljes kezdő útmutató az SSL titkosításhoz

HTTPS kép
A hackelés, az adathalász, a rosszindulatú programok, a vírusok és az egyéb piszkos ügyek minden formája az interneten lépést tartani nagy üzlet. A kiberbiztonsági ipar 2020-ra várhatóan eléri a 170 milliárd dollárt. A növekedés nagyjából a lépcsőzetesen növekszik a számítástechnikai bűncselekmények számának növekedésével. Ez egy olyan iparág, amely önmagában felelős az évi 450 milliárd dolláros veszteségért. Hogyan tud biztonságban maradni az átlagos internetfelhasználó és az alkalmi böngésző a „csősorozat” között? Az egyik hatékony módszer a biztonságos Socket Layer (SSL) titkosítással rendelkező webhelyek megértése és aktív felhasználása.

SSL kevesebb, mint 100 szóban

A Secure Socket Layer titkosítás magas szintű titkosítási szabvány, amely aszimmetrikus és szimmetrikus kulcs algoritmusok kombinációját használja fel. Ez azt jelenti, hogy az aszimmetrikus nyilvános kulcs mellett az alkalmazott kriptográfiai kulcsok egyediak is, amikor két gép között kapcsolat létesül. Az SSL-tanúsítványok aszimmetrikus nyilvános kulcsot (webhelykiszolgáló) és egy privát kulcsot (a felhasználó böngészője) használnak, amelyek együtt működnek az adatok hitelesítésében és biztonságában. A kezdeti kézfogás kialakítása után az SSL összekapcsolja a két gépet egy titkosítással, amely folyamatosan titkosítja és figyeli az adatátvitelt, ellenőrizve, hogy az adatok biztonságosak és változatlanok-e.

Rövid primer a titkosításhoz (biztonságos zöldhornokhoz)

Ha inkább profi vagy, nyugodtan mozoghat tovább. Ha azonban az SSL-ről és a hálózati biztonságról szóló összes ilyen beszélgetés kissé meghaladja a fejed, bontjuk le néhányat, amiről beszélünk, így kissé kevésbé zavarodva érzi magát.

Minden információ adat

Ezt már tudhatja. A legalapvetőbb szinten minden, amit online küld és fogad, alapvető szinten kódolt adat. A böngésző még a jelenleg az oldalon olvasott szavakat is lefordítja olvasható, vizuálisan vonzóbb formátumba. Valójában nem szeretné megpróbálni elolvasni, hogy az adatok hogyan néznek ki, mivel nem másnak látná őket, mint egy csomó betűt és számot, amelyeknek nincs értelme fordítani.

Íme például egy pillanatkép a Miami University-től arról, hogy az e-mail címe hogyan nézhet ki tiszta adat formájában:

U Miami SSL kód

Aligha tudná megérteni az adatokat a közepes átviteli állapotban. De a böngésző lefordítja ezeket az adatokat olvasható formába - ebben az esetben e-mail címbe.

Adatcsomagok

A legtöbb számítógép ugyanazokat a nyelveket beszéli. Tehát, ha két számítógép hálózaton keresztül kapcsolódik egymáshoz, és elkezdi az adatok továbbítását a fent említett kódolt nyelven, vagy sok más kódnyelv egyikén, akkor ezeket a nyelveket olvashatóbb formátumba fordíthatják a felhasználó számára kézhezvételük után. Ezek az adatok azonban nem egy folyamatos adatfolyamként kerülnek felhasználásra, hanem kisebb, gyorsan elküldött csomagokra bonthatók. Az adatcsomagok általában a következő formában léteznek:

  • Fejléc információkat tartalmaz, például a feladó IP és a fogadó IP címeit, a hálózati protokoll számát és egyéb hasznos információkat
  • A hasznos teher, amely a tényleges adatcsomag, amelyet meg kell kapni és le kell fordítani
  • A pótkocsi, amely azt jelzi, hogy a csomag véget ért, és segít kiküszöbölni a küldési folyamat során esetlegesen felmerülő hibákat

A legtöbb hálózat valójában korlátozza azt, hogy az egyes csomagok mennyi adatot tartalmazhatnak. Ez azt jelenti, hogy a hasznos teher összege változhat, ami befolyásolja az adatok küldésének idejét is. Mivel az adatokat útközben elfoghatják vagy ellophatják, mindaddig, amíg valakinek van számítógépe, amely képes lefordítani a csomagokban lévő adatokat (szinte bárki, valóban), az adatokat titkosítani kell az elküldés előtt, majd dekódolni kell, miután megkapták őket.

Adat titkosítás

Mivel bármely számítógép képes a hálózatokon átjutott adatok lefordítására, és a nem védett hálózatok sérülékenységének köszönhetően van titkosítás annak biztosítására, hogy az adatcsomagok valóban lehetetlen lefordítani. Így működik ez a titkosítás.

Az összes titkosítás a kriptográfia alapján származik, amely a kódolt üzenetekben történő üzenetek küldésének hátterét vizsgálja. A kriptográfia a történelem számos részén híresen alkalmazott az elmúlt néhány évtizedben, leginkább a második világháborúban, amikor mind a szövetségesek, mind a tengely hatalma felgyorsította erőfeszítéseit üzenetek küldésére és kódolására a nyilvános hullámokon keresztül..

A mai időkben a kriptográfia gyakoribb a hálózati titkosítás. Titkosítással az adatok átkódolódnak, mielőtt átjutnának a hálózaton és a fogadó félnek. Bárki, aki szimatol, az egyszer fordított adatok csak ostobaságnak tűnnek.

Kriptográfiai hash-funkciók

Tehát hogy van az, hogy az adatok összekeverednek? Kriptográfiai hash-függvényeken futó komplex algoritmusok. Ezek a funkciók alapvetően bármilyen méretű adatot vesznek, és egy előre meghatározott méretű kódolt függvénygé konvertálják. Íme egy példa arra, hogyan nézhet ki:

Hash funkciók

Az adatok bekerülnek a hash-függvénybe, amely aztán a fenti ábra szerint bitszintgé alakítja. Mint láthatja, a különféle bemenetek mindegyike ugyanolyan méretű bit karakterláncba fordul, függetlenül a bemeneti adatoktól. Ennek célja a brute-force támadások (azok, amelyekben valaki megpróbálja kitalálni a becsapott adatokat az összes lehetséges megoldás kitalálásával) megnehezítésére. Az SSL és más modern titkosítási szabványok esetén a nagyszámú lehetőség miatt a nagy erő nem lehetséges. Ami a következő témához vezet.

Titkosítási bitméret

Amikor az adatok titkosítva vannak, az előre meghatározott bit karakterlánc méret a legfontosabb tényező a brutális erő támadásainak megelőzésében. Minél hosszabb a bit karakterlánc mérete, annál nehezebb kitalálni a karakterlánc dekódolásának minden lehetséges kombinációját. Összességében az emésztett adatokat „kulcsnak” nevezzük, és a kulcs erősségét részben meghatározzuk, hogy hány bitet tartalmaz.

Akkor miért nem hoz létre csak egy kulcsot, amely mondjuk egy millió bittel rendelkezik? A válasz a feldolgozási teljesítmény és az idő. Minél nagyobb a bit kulcs, annál több időre és feldolgozási energiára van szüksége a számítógépnek, hogy ténylegesen visszafejtse az üzenetet a fogadó végén. Az SSL valójában különböző kulcsméreteket használ különféle célokra, és attól függően, hogy milyen frissített a gép.

A kezdeti kézfogásokhoz (vagyis annak ellenőrzéséhez, hogy a fogadó gép a megfelelő címzett) - egy sokkal nagyobb, 2048 bites RSA kulcsot használunk. A kulcsban szereplő adatok kicsik, de csak az adatok cseréjének ellenőrzésére használják fel. Miután a rendszerek ellenőrizték egymást, az SSL 128, 192 vagy 256 bites kulcsokra áll át.

Titkosítási bit kulcs mérete
Számít-e a kulcsméretek? Természetesen. Minél nagyobb a kulcs mérete, annál több lehetséges kombináció van. Ennek ellenére még a kisebb, 128 bites billentyűzet méretét is hihetetlenül nehéz megtörni brutális erőszakos támadással, tekintettel a potenciális kombinációk nagy számára. A jelenlegi számítási teljesítménynél lehetséges egy 128 bites kulcs eltörése, de ez egymillió évbe telik. Ennek ellenére a számítástechnika területén jelenleg a legnagyobb gond az, hogy a kvantumszámítás megkönnyíti az SSL-kulcsok törését, így szükség van a kulcsméret kibővítésére. De ez a technológia nem lesz széles körben elérhető a közeljövőben.

Titkosítás dióhéjban

Összegezve, a titkosítás a következők mindegyikét hajtja végre:

  • Átkódolja az adatokat, mielőtt azokat hálózaton keresztül továbbítja
  • Lezárja ezeket az adatokat egy szinte törhetetlen (egyelőre) kivonat-algoritmussal
  • Az adatokat biztonságosan továbbítja az átvitel során, megakadályozva a szimatolást
  • Csak azt teszi lehetővé, hogy az adatokat egy biztonságos fél fogadja, és a kézhezvételkor visszafejtje azokat

Milyen előnyei vannak az SSL-nek?

Az SSL titkosításnak két kulcsfontosságú előnye van:

  • Biztosítja a titkosítás révén a számítógép és a webhely szerverei közötti adatátvitelt
  • Ellenőrzi, hogy a weboldal frissített és hitelesített biztonsági tanúsítvánnyal rendelkezik-e.

Az adatbiztonság rendkívül fontos, különösen olyan webhelyek esetében, amelyek hitelkártya- és bankinformációkat, illetve jelszavakat és felhasználóneveket gyűjtenek. Minden webhelynek, amelyik ezen elemek bármelyikét végrehajtja, SSL-titkosítással kell rendelkeznie. Ellenkező esetben a webhely nyitva marad a hackelési támadásokkal, ahol az adatok útközben ellophatók.

Az SSL-tanúsítványok ellenőrzése rendkívül fontos. Az SSL tanúsítást nyújtó vállalatok listája hosszú, és ez nem mindig olcsó vagy egyszerű. A magas bizonyosságú SSL tanúsítást igénylő webhelyeknek a következőket kell biztosítaniuk:

  • A Whois rekord annak azonosítása, aki a domain nevet birtokolja
  • Egy teljes Tanúsítvány aláírási igény (CSR)
  • A weboldal és a tulajdonos cég független érvényesítése

Ez a folyamat költségekkel jár a webhelytulajdonosok számára is. Ez az oka annak, hogy az adathalász webhelyek soha nem használnak rendkívül biztonságos SSL tanúsítványokat. Soha nem lesznek képesek átadni az ellenőrzést, és a legtöbb pénzt lop, és nem fizet ki más társaságoknak.

A Tanúsító Hatóság társaságok valószínűleg nem adnak ki magas megbízhatóságú SSL tanúsítványokat egy nem jó hírű webhelyre. A CA-vállalatok többsége jól ismert név. A lista tartalmazza:

  • Symantec
  • Hajrá apu
  • DigiCert
  • Trustwave
  • GlobalSign
  • StartCom
  • SwissSign
  • Hálózati megoldások
  • Thawte
  • com
  • Titkosítsuk
  • GeoTrust
  • Megbíz
  • Comodo

Leginkább a CA szervezetek általában webgazda és kiberbiztonsági társaságok.

Hogyan állapítható meg, hogy egy webhely SSL-t használ-e?

Valójában meglehetősen könnyű meghatározni, hogy egy webhely SSL-titkosítást használ-e. Miután csatlakozik egy webhelyhez, a böngésző és a szerver közötti kezdeti kézfogás igazolja, hogy a webhely SSL titkosítást használ-e. Ezt kétféle módon mutatják be:

  • A webhely címe HTTPS-webhelyként jelenik meg (Hypertext Transfer Protocol Secure)
  • A zárolás szimbóluma közvetlenül a HTTPS bal oldalán vagy jobb oldalán jelenik meg

Ezenkívül egyes webhelyeknél a cég neve megjelenhet a zár szimbólummal. Azok a webhelyek, amelyek meghosszabbított SSL-igazolást vásároltak, a legmagasabb szintű, a cégnév megjelenik a címsor mellett.

Így néz ki ez az egész.

A Stack Exchange webhely számos oldalán nem használ SSL titkosítást. Mint ilyen, a webhely címe mellett nem jelenik meg HTTPS vagy zár szimbólum:

StackExchange Nem SSL
Az „i” -re kattintva kiderül, hogy a webhely valóban nem biztonságos:

StackExchange Nem SSL

Eközben a Google Docs rendelkezik SSL titkosítással, de nem a legmagasabb szinten:
Google Docs SSL

Míg az amerikai Capital One amerikai bank weboldala kiterjesztett verifikációt használ, minden díszítéssel:
Capital One SSL

Amikor az SSL fontos - és mikor nem

Az egyik kérdés, hogy vajon vajon van-e mindig szükség SSL titkosításra. Világosan fogalmazva: a válasz: nem. Az SSL titkosítás nem mindig szükséges. Azon webhelyeknek, amelyek ezt használják, eltérő igények vannak, hogy milyen típusú SSL-titkosítást végezzenek vagy kellene.

Az előző szakasz példáival ragaszkodva a StackExchange valójában nincs szüksége SSL titkosításra a webhelyének minden területén. Valójában a webhely valójában rendelkezik SSL titkosítással, de csak ott, ahol valójában szüksége van rá. Ha létrehoz egy fiókot, és bejelentkezik a weboldalra, nézd meg, mi történik:

Stachexchange ssl

Ennek oka az, hogy minden olyan webhelynek, ahol fiókot kell létrehoznia, és be kell jelentkeznie a szerverére, SSL titkosítással kell rendelkeznie, legalább a legalapvetőbb szinten. Az SSL titkosítás megakadályozza, hogy valaki ellopja az Ön fiókja bejelentkezési adatait, mivel ezek az adatok áthaladnak a számítógép és a webhely szervere között.

Általánosságban elmondható, hogy minél fontosabb az adatátvitel közted és a webhely szervere között, annál magasabb szintű biztonságot kell nyújtania a webhelynek. Ez az oka annak, hogy egy olyan bank, mint a Capital One, kiterjesztett verifikációval rendelkezik, míg egy olyan webhely, mint a StackExchange, rendelkezik szervezeti igazolással.

Azok a webhelyek, amelyek nem gyűjtenek semmilyen információt, vagy bejelentkezéshez szükségesek a weboldal egyes részeinek eléréséhez, minden bizonnyal SSL titkosítást használhatnak, de ez nem feltétlenül szükséges. Ennek ellenére mindig aggódik az a kérdés, hogy egy webhely fel van-e állítva és van-e, vagy hamis adathalász webhelyről van szó, amelyet adatok ellopására állítottak fel.

Az SSL-tanúsítványok beszerzéséhez szükséges intenzív ellenőrzés miatt az adathalász webhelyek nem rendelkeznek a legmagasabb szintű titkosítással, de lehet, hogy még mindig rendelkeznek HTTPS-címmel vagy akár zárolási szimbólummal. Soha nem fognak rendelkezni a cégnévvel ellátott zöld sávval, mivel ezt csak a magas szintű tanúsítvánnyal rendelkező webhelyek kapják. Ezenkívül egyes webhelyek lejártak vagy nem ellenőrzött SSL-tanúsítványok. Láthatja, hogy ez hogyan néz ki, ha ellátogat a badssl.com oldalra, egy egyszerű oktatási webhelyre, amely szilárd példákat kínál mindenféle SSL tanúsítvány-rendellenességre.

Például egy visszavont SSL-tanúsítvánnyal rendelkező webhely felbukkanhat egy Chrome böngésző munkamenetben:

Rossz SSL

Mindent egybevetve: egy webhelynek nincs szüksége SSL-titkosításra, de amikor egy olyan webhelyre látogat, amelyben bizonytalan, a legjobb, ha elkerül egy bejelentkezést az adott webhelyen, amíg először teljesen meg nem vizsgálja azt..

Különböző típusú SSL

Mivel az SSL a titkosítás és az ellenőrzés egyik formája, különféle típusok léteznek. Mindegyik típus valamivel eltérő célt szolgál. Fontos azonban megjegyezni, hogy a különféle típusú SSL-tanúsítványok nem azt jelentik, hogy a webhely többé-kevésbé biztonságot nyújt. A tanúsítványtípusok jelzik, hogy a webhely mennyire megbízható, mivel ezeknek a különféle típusoknak eltérő érvényesítési szinteket kell elérniük.

Domain érvényesített tanúsítványok

A DV tanúsítványok a legolcsóbb elérhető SSL tanúsítványok. Ezek a tanúsítványok nem sokkal többet tesznek, mint hogy ellenőrizzék a tartománynév-nyilvántartást a tanúsítvánnyal szemben. Ezeknek a tanúsítványoknak a megszerzéséhez általában nagyon alacsony a követelmény, vagyis sok adathalász webhely valójában meglehetősen könnyen megszerezheti azokat. Ezek a tanúsítványok nem igényelnek szigorúbb háttér- és érvényesítési ellenőrzéseket, amelyeket a többi tanúsítási szint megkövetel.

Mint ilyen, sok Tanúsító Hatóság valójában nem kínálja ezt a tanúsítványt, mivel a legtöbb úgy véli, hogy túl alacsony biztonságú, és nagyrészt nem biztonságos. A zárolás szimbóluma továbbra is megjelenik ezen webhelyeknél, ám ezek továbbra is bizonyos kockázatot jelentenek. Amikor ellenőrzi a webhely tanúsítványának adatait, az csak a domain névről és a hitelesítésszolgáltatóról tájékoztat.

Ez a fajta igazolás olyan webhelyeknél gyakori, amelyek biztonsági szempontból nagyon korlátozottak. A MyAnimeList.net Anime webhely az egyik ilyen webhely. Itt vannak a tanúsítvány részletei:

MAL ssl

Valójában a weboldal egyes részei nem biztonságosak, ezért a böngészőm blokkolta azokat:

MAL SSL blokk

Noha a DV tanúsítványok hasznosak lehetnek, az a webhely, amely általában ezeket használja, nem engedélyezi az egyedi felhasználói fiókokat, és ezért nem gyűjt felhasználóneveket és jelszavakat.

Szervezet által érvényesített tanúsítványok

Ezeknek az SSL-tanúsítványoknak a beszerzéséhez szigorúbb érvényesítési folyamat szükséges, ezért ezek szintén drágábbak. A DV-tanúsítvánnyal ellentétben az OV-tanúsítványok megfelelnek az Internet Engineering Task Force (IETF) és az Internet Society (ISOC) által előírt megjegyzés-kérési (RFC) szabványoknak. A webhelyeknek kicserélniük kell érvényesítési információkat, és a hitelesítésszolgáltató közvetlenül kapcsolatba léphet a vállalatgal az információk ellenőrzése céljából.

Amikor ellenőrzi a tanúsítvány adatait, látni fogja a webhely nevét és azt, hogy ki hitelesítette. A tulajdonos adatait azonban nem kapja meg.

A Wikipedia egy olyan webhely példája, amely OV tanúsítványt használ:

Wikipedia SSL

Bővített érvényesítési tanúsítvány

Az EV tanúsítvány a legmagasabb szintű, amely a legtöbb bizonyosságot és validációt nyújtja. Az EV tanúsítvány megszerzéséhez szükséges eljárás kiterjedt és költséges. Csak az EV tanúsítvánnyal rendelkező webhelyek kapják meg a zöld sáv érvényesítését webhelyük neve alapján az Ön böngészőjében is. Sajnos nem minden böngésző képes megjeleníteni az EV zöld sávot. Csak a következő böngészők számára érhető el:

Google Chrome, Internet Explorer 7.0 vagy újabb, Firefox 3+, Safari 3.2 vagy újabb, Opera 9.5+

A régebbi böngészők nem jelenítik meg. Ez nem azt jelenti, hogy nincs ott. Ez egyszerűen azt jelenti, hogy a régebbi böngészőket használóknak ellenőrizniük kell a tanúsítvány adatait az érvényesítési szint ellenőrzéséhez.

A Capital One-val kapcsolatos részletesebb információk feltárása során kiderül, hogy a weboldal valóban EV SSL tanúsítványt használ:

Capital One SSL

Az EV tanúsítványok messze a legmegbízhatóbb és legbiztonságosabb, de nem minden webhelyhez szükségesek. A legtöbb weboldal valóban megszerezhető egy DV-vel vagy egy OV-vel. Ha azonban egy weboldal információkat gyűjt tőled, akkor nem bízhat benne, kivéve, ha rendelkezik OV tanúsítvánnyal vagy újabb.

Ennek ellenére egyes webhelyek kifizetésekkor egy külső webhelyre irányítják Önt. Ezek a webhelyek külső szolgáltatásokat is igénybe vehetnek fizetési rendszerükhöz, például a PayPal-hoz, amely magas szintű EV tanúsítvánnyal rendelkezik. Ilyen módon nem kell saját EV-t megvásárolniuk, hanem a külső szolgáltatásokra támaszkodva támaszkodnak a biztonsági és biztosítási rétegre.

Hiba a DV és az OV tanúsítvánnyal

Bár sok CA nem kínál DV-tanúsítványokat, néhányuk mégis. Mivel a CA-tanúsítványok nem igényelnek további háttér-ellenőrzést és érvényesítést, egyes adathalász webhelyek tulajdonosai megvásárolták ezeket a tanúsítványokat a rendszer játékához. Sajnos nincs közvetlen módja annak, hogy megkülönböztessük a DV és az OV webhelyeket anélkül, hogy a tanúsítvány adatait részletesebben megvizsgálnánk. Ez az oka annak, hogy sok webhely fordul EV (magas fokú bizonyosságú) tanúsítványokhoz. Mint az OV tanúsítványok, szélesebb körű érvényesítést igényelnek, de mellékelnek egy zöld sávot is, amely megadja a cég nevét, valamint a zár szimbólumát és a rendelkezésre álló sok információt.

A legtöbb böngészőben ellenőrizheti a tanúsítványt a zár szimbólumra kattintva, a „További információ”, majd a „Tanúsítvány megtekintése” gombra kattintva:

SSL tanúsítvány

Ez megjeleníti a weboldal tanúsítványában szereplő részletes információkat:
veremcsere ssl

Itt láthatjuk, hogy a Stack Exchange valóban a DigiCert által kiadott magas szintű EV tanúsítványt használja. Bízhatunk webhelyünkön, és nem kell aggódnunk, ha biztonságos jelszóval jelentkezünk be.

Van-e alternatíva az SSL-hez?

Noha az SSL a biztonságos internetes forgalom nagy részét elmenti, ennek a titkosítási módszernek néhány figyelemre méltó alternatívája van.

Szállító aljzat réteg

A TLS, vagy a Transport Socket Layer az SSL utódja. Valójában sok esetben az SSL-tanúsítványnak nevezett TLS-tanúsítvány lehet. Ez nem véletlen. A TLS, egy újabb szabvány, erősen az SSL-en alapul, olyan kicsi változtatásokkal, hogy sok ember, még az iparban közvetlenül is, továbbra is hivatkozni fog a TLS-re és az SSL-re (általában az „SSL / TLS” megjelöléssel). Az SSL és a TLS közötti fő különbségek a frissített rejtjelek és a TLS jobb biztonsága, ezért váltotta fel az SSL-t. Ennek ellenére a legtöbb ember még mindig hivatkozik a TLS-re SSL-ként, mivel a két protokoll rendkívül hasonló. Mivel mindkettő ugyanazokat a tanúsítványokat használja, a legtöbb weboldalon az átmenet meglehetősen egyszerű.

Biztonsági héj

A Secure Shell (SSH) közvetlenül versenytársa az SSL-nek, és sok szempontból ugyanolyan biztonságos. Az SSH azonban leginkább kétféleképpen különbözik. Először is, az SSH alapvetően szabadon megszerezhető. Az SSL-től eltérően az SSH nem használja a tanúsító hatóságokat a hitelesítés ellenőrzéséhez és megoldásához. Az SSL-rel ellentétben az SSH számos különféle segédprogramot is alkalmaz, amelyek a titkosítással működnek. Ez magában foglalhatja a hálózatba kapcsolt gépek távoli üzemeltetését és a bejelentkezési követelmények létrehozását egy biztonságos hálózaton keresztül. Az SSH népszerűbb a hálózati rendszergazdák körében. Az SSH kevésbé biztonságos, mint az SSL / TLS, az, hogy a kulcskezelés kevés felügyelettel rendelkezik, ellentétben az SSL-szel. Ez azt jelenti, hogy a titkosítási kulcsok elveszhetnek, ellophatók vagy nem megfelelő módon használhatók, megnehezítve a tulajdonjog ellenőrzését.

IPSec

Az Internet Protocol Security más megközelítést alkalmaz a hálózati biztonság és a titkosítás szempontjából. Míg az SSL / TLS alkalmazás szinten működik, az IPSec-t úgy tervezték, hogy pont-pont titkosításként szolgáljon egy teljes hálózat számára. Mint ilyen, az IPSec egy másik hálózati protokoll rétegen működik (az SSL az 1. rétegben működik, HTTP, míg az IPSec a 3. rétegben, IP). Ez az IPSec számára átfogóbb megközelítést ad a hálózati biztonság szempontjából. Az IPsec-t jobban tervezték két gép közötti állandó kapcsolatokhoz, míg az SSL-t tartós munkamenetekhez.

Az IPSec-et eredetileg az IPv6-ra bízták, mivel IP-hálózati biztonságot nyújt. Az IPsec-et eredetileg az IPv6 hálózati biztonsági módszerének fejlesztették ki. Az IPSec legnagyobb gyengesége azonban az, hogy nem nyújt individualizáltabb hitelesítést. Miután valaki hozzáférést kapott az IPSec által biztosított hálózathoz, szabadon hozzáférhetnek bármihez a hálózaton; mindaddig, amíg nincs más hitelesítés, nincs korlátozás a hozzáférésre.

Ezenkívül az IPSec sem kivételes a távoli elérés szempontjából. Úgy tervezték, hogy pont-pont összeköttetést biztosítson a hálózatok között, például egy nagyvállalat számára, amely biztonságos kapcsolatot létesít kiszolgálóival az összes üzleti helyére. A távoli felhasználók kapcsolódásának lehetővé tétele (például olyan munkavállalók, akik otthoni munkát vagy utazás közben akarnak dolgozni) nagyobb karbantartást igényel, külön alkalmazások igénylése esetén.

SSL kiterjesztések és VPN megoldások

Mivel az SSL elsősorban alkalmazás alapú titkosítási szabvány, megoldásokat fejlesztettek ki annak biztosítására, hogy az SSL különféle módon is alkalmazható legyen.

OpenSSL a VPN-en

Az OpenSSL egy SSL nyílt forráskódú verziója, amelyet számos nem böngésző alkalmazásban használnak. A legfigyelemreméltóbb az az elsődleges biztonsági módszer, amelyet az OpenVPN platformon működő VPN-k használnak. Az OpenSSL pontosan olyan, mint amilyennek hangzik: az SSL nyílt forráskódú verziója, amelyet szabadon lehet használni és játszani. Mint sok nyílt forrású kezdeményezés, az OpenSSL nagyon megbízható a közösség számára, amely folyamatosan frissíti. Ez némi csalódást eredményezett, mivel az OpenSSL nem annyira bizonyosságot nyújt, mint egy böngésző alapú SSL tanúsítvány, amelyet egy Tanúsító Hatóságon keresztül vásároltak meg. Figyelemre méltó sebezhetőségeket találtak, de az OpenSSL-t is gyakran frissítik a biztonsági rések ellensúlyozására.

Számos villa létezik ehhez a programhoz, beleértve a Google saját BoringSSL-jét. Pozitív szempontból az OpenSSL eszközkészlet lehetővé teszi a folyamatos fejlesztéseket, mivel nyílt forrású.

Biztonságos böngészés a HTTPS segítségével bárhol

HTTPS mindenhol

A HTTPS Everywhere egy ingyenes termék az Electronic Frontier Foundation-től, amely a Chrome, a Firefox és az Opera böngésző kiterjesztése, amely lehetővé teszi, hogy böngészője a HTTPS oldalakat lehetőleg választja. A HTTPS visur másfelől úgy működik, hogy segíti az adatok védelmét, miközben csatlakozik egy olyan webhelyhez, amely HTTPS-t használ egyes, de nem az összes oldalán. Mindaddig, amíg a webhely támogatja a HTTPS-t, a HTTPS Everywhere képes konvertálni az oldalakat HTTPS-re és titkosítani az adatokat. Amint arra az EFF GYIK oldala is utal, a kérdéses harmadik fél linkeire mutató webhelyeket, például képeket, a HTTPS nem tudja teljes mértékben biztosítani.

Azt is beállíthatja, hogy a HTTPS mindenhol blokkolja a nem biztonságos linkeket és az adathalász webhelyeket. Ez egy különálló biztonsági funkció, amely megakadályozza, hogy az internethasználók véletlenül megbotlik az adathalász webhelyeknél..
Christiaan Colen által készített „HTTPS” a CC BY 2.0 alapján engedélyezett

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *

88 − 82 =

Adblock
detector