SSL / TLS 101 kezdőknek

Az internetes kapcsolatainkat biztosító titkosítás alapos áttekintése


Míg a Netscape eredetileg az 90-es évek közepén találta ki az SSL-t, addig nem volt kötelező minden webhely számára, hogy az SSL / TLS tanúsítványt 2018 nyaráig telepítse, amikor a Google elkezdett jelölni a titkosítatlan webhelyeket.Nem biztonságos.”

Noha a Google – keresőmotorjával, Chrome böngészőjével és Android operációs rendszerével – egyoldalúan újradefiniálhatja az internetet, ez nem volt egyedül ezen megbízás. Az Apple, a Microsoft, a Mozilla és a technológiai ipar többi fő érdekeltje együttesen döntést hozott az SSL / TLS tanúsítványok és a HTTPS engedélyezéséről..

Ennek oka egyszerű: SSL / TLS és a HTTPS-en keresztüli biztonságos csatlakozás lehetősége nélkül a webhelyek és a látogatók közötti kommunikáció egyszerű szöveges formában zajlik és egy harmadik fél által könnyen olvasható..

Az univerzális titkosítás e legutóbbi törekvése egyetlen hátránya, hogy új ügyfelek beáramlását egy ismeretlen piacra kényszerítette, amely nagyon kevés ahhoz, hogy kevésbé zavarja az átlagos webhelyet vagy az üzleti tulajdonosot..

Ez a cikk átfogó útmutatóként szolgál az összes SSL / TLS-re vonatkozóan; megalapozjuk az alapkoncepciókat, például a titkosítást, a HTTPS-t és az internetkapcsolatok jellegét..

Remélhetőleg a végén magabiztosan fogja érezni magát a TLS-igazolás kiválasztásában, megvásárlásában és végrehajtásában, és emlékszik arra, hogy bármilyen kérdése van, amelyet az alábbi megjegyzésekbe hagyhatsz..

Alapvető elemek

Kezdjük azzal, hogy megvitassuk azt a koncepciót, amely mindezek középpontjában áll: a titkosítás.

A titkosítás, a legegyszerűbb iterációban, nem sokkal több, mint az adatok rejtjelezése – egy előre meghatározott rejtjelet vagy kulcsot használva – úgy, hogy bárki számára olvashatatlanná tegyék, kivéve az azonos magánkulccsal rendelkező másik felet..

A történelem során a privát kulcsok titkosítása volt a leggyakoribb modell. A magánkulcs titkosításban mindkét félnek rendelkeznie kell vagy legalább meg kell cserélnie egy olyan privát kulcsot, amely felhasználható az információk titkosítására és visszafejtésére is..

Korábban a kriptoszisztémák alapját képező rejtjelek többsége primitív volt, egyszerű helyettesítésekre támaszkodva vagy a közös szavakat karakterekkel helyettesítve. De az idő múlásával a rejtjeleket egyre inkább befolyásolta a matematika, és komplexebbé váltak.

Például az 1600-as évek közepén, Franciaországban, XIV. Lajos király kriptográfia olyan rejtjelet hozott létre, amely annyira jól megtervezett volt, hogy csak 250 évvel később történt meg, és csak akkor részben. A francia levéltárban manapság több száz évnyi nyilvántartás található, amelyeket soha nem lehet megfejteni.

De bár a történelem során a titkosítás eszköz volt a rejtett vagy titkos megjelenés szempontjából, az internet megjelenése a koncepciót inkább befogadta. Az internet mindenütt jelen van, és számos kritikus funkcióval rendelkezik. Minden nap emberek milliárdjai használják érzékeny információk elérésére és küldésére, pénzügyeik kezelésére, üzletekkel történő tranzakciókra – nevezzük el.

A probléma az, hogy az internetet nem pusztán úgy fejlesztették ki, hogy méretezze azt, amire lett. Korán, azokban a napokban, amikor a tudományos élet és az Egyesült Államok kormánya először dolgozott ki hálózati protokollokat, az internetet csak a kormány és az akadémiai intézmények közötti szabad információcsere mechanizmusának tekintették. Ezen a ponton a kereskedelem online illegális volt. Az e-kereskedelem nem volt olyan szó, amelyet még fel is találtak. És a webhely inkább földrajzi fogalom volt.

Tehát, amikor a HTTP-t vagy a hipertext-átviteli protokollt 1991-ben vezették be először, az a tény, hogy az általa létrehozott kapcsolatok egyszerű szöveges adatcserét folytattak, nem jelentette problémát..

A dolgok ma sokban különböznek. Az online információcsere nem tudományos kutatás vagy szabadon elérhető információ, hanem személyesen azonosítható információ és érzékeny adatok, amelyek pénzbe kerülhetnek az embereknek, vagy akár bizonyos régiókban is az életük. Ez biztonságosabb megközelítést igényelt.

A válasz titkosítás volt.

A kulcscsere kérdése

Az egyik probléma, amely történelmileg sújtotta még a legjobb kriptoszisztémákat is, továbbra is fennáll a mai napig.

Amit korábban tárgyaltunk, és ami a hagyományosan a titkosítás standardja, a magánkulcs-titkosítás. Ezt szimmetrikus titkosításnak vagy kétirányú titkosításnak is hívják – a magánkulcsokkal a kommunikációhoz szükséges titkosítási és dekódolási funkciókat egyaránt kezelik..

A magánkulcs-titkosítás működéséhez a magánkulcsot át kell adni a felek között, vagy mindkét félnek rendelkeznie kell saját példányával. Akárhogy is, a magánkulcs biztonsága kritikus volt a kriptoszisztéma integritása szempontjából, és amint kétségtelenül feltételezhető, hogy a kulcscsere olyan régi probléma, mint maga a titkosítás..

Aztán az 1970-es években – technikailag két különböző időponttól, egész óceántól eltekintve – a titkosítás új formáját fogalmazták meg és életre keltették: a nyilvános kulcsú titkosítást.

Mivel a magánkulcsok titkosítása kétirányú, szimmetrikus funkció, mivel a magánkulcs képes mind az adatok titkosítására, mind a visszafejtésére, a nyilvános kulcsú titkosítás aszimmetrikus; egyirányú. Egy privát kulcs helyett létezik egy nyilvános-magán kulcspár is. A nyilvános kulcs a titkosítást kezeli, és amint a neve azt sugallja, nyilvánosan elérhető, míg a dekódolást kezelő magánkulcsot a tulajdonos titokban tartja. A nyilvános kulcs segítségével titkosíthat egy darab adatot, és elküldheti a kulcs tulajdonosának, ahol csak ők tudják megfejteni..

Nagyszerű, de mennyire hasznos??

Nos, az egyirányú titkosítás nem ideális az internetkapcsolatok titkosításához, nehéz kommunikálni, amikor az egyik fél csak titkosítani tudja, a másik pedig csak visszafejteni. Nem, egy internetkapcsolat titkosításához szimmetrikus, privát kulcsos titkosítást kell használnia.

De hogyan cserélsz kulcsokat? Különösen online?

Nyilvános kulcs titkosítása.

És az egész lényegére lebontva az SSL / TLS lényege: biztonságos kulcscsere.

Ezzel összekapcsoljuk ezeket a fogalmakat. Ha azt akarja, hogy a webhelyével folytatott kommunikáció privát legyen, akkor biztonságosan csatlakoznia kell ehhez. Ha biztonságosan szeretne csatlakozni az adott weboldalhoz, akkor szimmetrikus magánkulcsokat kell cserélnie, hogy kommunikálhassanak velük. Az SSL / TLS (és általában a PKI) csak egy fantasztikus mechanizmus a munkamenet-kulcs létrehozására és cseréjére.

Az SSL / TLS használatával hitelesítheti a kiszolgálót vagy szervezetet, amellyel kapcsolatba fog lépni, és biztosíthatja, hogy biztonságosan cserélje a magánkulcsokat, amelyeket a kívánt féllel folytatott kommunikáció titkosításához használ..

Sajnos az SSL / TLS és a PKI nagyon sok terminológiával és mozgó alkatrészekkel rendelkezik, amelyek könnyen megtéveszthetik az embereket, ám akik hiszik abban a tényben, hogy ha eltávolítják az összes matematikát és a műszaki zsargont, ez csak egy elegáns, modern technológiai megoldás egy kor számára régi probléma: kulcscsere.

Most mutassunk be néhány kulcsfontosságú kifejezést

Mielőtt továbbmennénk, mutassunk át néhány másik kulcsfogalmat. Már bevezettük a HTTP, hipertext átviteli protokollt, amely évtizedek óta az internet gerince. De amint megbeszéljük, az internet valami másképp fejlődött, mint amikor a HTTP-t 1991-ben adták ki.

Biztonságosabb protokollra volt szükség. Így a HTTPS.

A HTTPS, amelyet néha HTTP-n keresztül hivatkoznak a TLS-en keresztül, titkosítást használ annak érdekében, hogy a kapcsolat során kicserélendő adatok olvashatatlanná váljanak a címzett kivételével. Ez különösen akkor fontos, ha figyelembe vesszük a modern internetes kapcsolat természetét.

Míg az internet korai napjaiban a kapcsolat ésszerűen közvetlen volt, most már a kapcsolatok több tucat eszközön vezetik át, hogy végső rendeltetési helyükre menjenek. Ha ezt valaha is gyakorlatilag be kívánta mutatni, nyissa meg a parancssort az operációs rendszerén, és írja be a „tracert geekflare.com” parancsot.

Amit látni fogja, az az út vezet, amellyel kapcsolatod útján a rendeltetési helyére haladt. Akár 30 ugrás. Ez azt jelenti, hogy adatai ezen eszközök mindegyikén áthaladnak, mielőtt elérnék bármilyen webhelyet vagy alkalmazást, amelyhez csatlakoznak. És ha valakihez csomageszköz-szippantó vagy némelyik hallgató telepítve van ezen eszközök bármelyikére, ellophatják az átvitt adatokat, és bizonyos esetekben manipulálhatják a kapcsolatot..

Ezt úgy hívják, mint egy közép (MITM) támadás.

Ha meg szeretné tudni a MITM támadást, akkor nézd meg ezt az online tanfolyamot.

Sokkal több felületet kell lefedni a modern internetes kapcsolatokkal, mint az emberek túlnyomó többsége rájön, ezért kritikus fontosságú az adatok titkosítása. Fogalma sincs, ki hallgathatná meg, vagy milyen könnyű ezt megtenni.

A HTTP-kapcsolat a 80-as porton keresztül jön létre. Célunk, hogy a portokra olyan konstrukciókként gondoljunk, amelyek hálózati szolgáltatást vagy protokollt jelölnek. A szokásos HTTP-n keresztül kiszolgált webhely a 80-as portot használja. A HTTPS általában a 443. portot használja. Amikor egy webhely tanúsítványt telepít, a HTTP-oldalakat átirányíthatja a HTTPS-ekre, és a felhasználók böngészői megkísérlik biztonságosan csatlakozni a 443-as porton keresztül, a hitelesítésig..

Sajnos az SSL / TLS, a HTTPS, a PKI és a titkosítás kifejezések sokszor el vannak dobva, néha még felcserélhetően is használhatók, így a fennmaradó zavarok kiküszöbölése érdekében itt található egy rövid útmutató:

  • SSL – Secure Sockets Layer, a HTTPS-rel használt eredeti titkosítási protokoll
  • TLS – A Transport Layer Security, az újabb titkosítási protokoll, amely felváltotta az SSL-t
  • HTTPS – A HTTP biztonságos verziója, amelyet webhelyekkel való kapcsolatok létrehozására használnak
  • PKI – Nyilvános kulcsú infrastruktúra: a teljes bizalmi modell, amely megkönnyíti a nyilvános kulcs titkosítását

Az SSL / TLS együtt működik a HTTPS kapcsolatok engedélyezésében. És a PKI az egészre utal, amikor kicsinyít.

Megvan? Ne aggódj, meg fogod tenni.

Nyilvános kulcsú infrastruktúra kiépítése

Most, hogy lefektettük az alapot, kicsinyítsük és nézzük meg az SSL / TLS középpontjában a bizalmi modell által alkalmazott architektúrát..

Amikor megérkezik egy weboldalra, a böngészője elsőként ellenőrzi az SSL / TLS tanúsítvány hitelességét, amelyet a webhely bemutat. Megtudjuk, mi történik, miután ez a hitelesítés néhány szakaszban megtörtént, de azt kezdjük, hogy megbeszéljük a megbízhatósági modellt, amely mindezt lehetővé teszi.

Tehát azzal kezdjük, hogy felteszük a kérdést: honnan tudja a számítógépem, hogy megbízhat-e egy adott SSL / TLS tanúsítványt?

Ennek megválaszolásához meg kell vitatnunk a PKI-t és a különféle elemeket, amelyek működését lehetővé teszik. Kezdjük a tanúsító hatóságokkal és a root programokkal.

Tanúsító hatóságok

A Tanúsító Hatóság olyan szervezet, amely megfelel az előre meghatározott szabványoknak cserébe megbízható digitális tanúsítványok kibocsátásának képessége ellenében.

Több tucat CA van, mind ingyenes, mind pedig kereskedelmi, amelyek megbízható tanúsítványokat adhatnak ki.

Mindannyiuknak be kell tartania egy olyan szabványkészletet, amelyet a CA / Böngésző Fórumon keresztül vitattak meg és fogadtak el, amely a TLS iparág szabályozó testülete. Ezek a szabványok vázolják a következőket:

  • Műszaki biztosítékok, amelyeknek érvényben kell lenniük
  • Az érvényesítés bevált gyakorlata
  • Kiadási bevált gyakorlatok
  • Visszavonási eljárások és ütemtervek
  • Tanúsítványnaplózási követelmények

Ezeket az irányelveket a böngészők, a CA-kkal közösen állították elő. A böngészők egyedülálló szerepet játszanak a TLS ökoszisztémájában.

Senki sem juthat el bárhova az interneten webböngésző nélkül. Mint ilyen, a böngésző fogja fogadni és érvényesíteni a digitális TLS tanúsítványt, majd kulcsot cserél a szerverrel. Tehát, tekintettel kiemelkedő szerepükre, jelentős befolyást gyakorolnak.

Fontos szem előtt tartani, hogy a böngészőket úgy tervezték, hogy a lehető legszkeptikusabbak legyenek. Semmiben bízni. Ez a legjobb módszer a felhasználók biztonságának megőrzésére. Tehát, ha egy böngésző megbízni fog egy digitális tanúsítványt – amelyet potenciálisan visszaélhetnek a felhasználó kárával -, bizonyos biztosítékokra van szüksége, hogy bárki, aki kiadta ezt a tanúsítványt, megtette az átvilágítását.

Ez a tanúsító hatóságok szerepe és felelőssége. És a böngészők sem tartanak hibákat. Van egy volt temető a korábbi CA-k számára, amelyek elindultak a böngészőkben és legelőre kerültek.

Amikor egy tanúsító hatóság igazolja, hogy megfelel a CAB fórum alapkövetelményeinek, és elvégezte az összes szükséges ellenőrzést és áttekintést, petíciót nyújthat be a különféle gyökérprogramokhoz a Root tanúsítványok hozzáadása érdekében.

Gyökérprogramok

A gyökérprogram – a legfontosabb az Apple, a Microsoft, a Google és a Mozilla – üzemelteti azt az eszközt, amely felügyeli és megkönnyíti a gyökérraktárakat (néha megbízhatósági áruházaknak hívják azokat), amelyek a root rendszeren található Root CA tanúsítványok gyűjteményei. Ezek a gyökerek ismét hihetetlenül értékes és hihetetlenül veszélyesek – elvégre megbízható digitális tanúsítványokat adhatnak ki – tehát a biztonság legfontosabb aggodalomra ad okot..

Ez az oka annak, hogy a CA-k szinte soha nem adják ki közvetlenül a Root CA tanúsítványokat. Ehelyett köztes gyökér tanúsítványokat állítanak fel, és azokat használják végfelhasználói vagy levél tanúsítványok kiadására. Ezeket a gyökereket átadhatják az al-CA-knak is, amelyek tanúsító hatóságok, amelyeknek nincs megkülönböztetett gyökereik, de intermedierek útján továbbra is kölcsönösen aláírt igazolásokat adhatnak ki.

Tegyük össze ezt az egészet. Ha egy webhely TLS-tanúsítványt akar kiadni, akkor létrehoz egy valamit, amelyet igazolás-aláírási kérelemnek (CSR) hív fel a kiszolgálón, amelyen üzemelteti. Ez a kérelem tartalmazza azokat az összes adatot, amelyeket a weboldal szeretne szerepeltetni a tanúsítványon. Amint egy kicsit látni fogja, az információ mennyisége változhat a teljes üzleti részletektől az egyszerű kiszolgálóazonosságig, de a CSR kitöltése után elküldik az igazolási hatósághoz kiadás céljából..

A tanúsítvány kiadása előtt a CA-nak meg kell tennie a CA / Böngésző Fórum által felhatalmazott átvilágítást és ellenőriznie kell, hogy a CSR-ben szereplő információk pontosak-e. Miután ellenőriztük, aláírja a tanúsítványt a magánkulccsal, és visszaküldi a webhely tulajdonosához telepítéshez.

Tanúsítvány láncolása

A TLS tanúsítvány telepítése után bármikor, amikor valaki meglátogatja a webhelyet, az azt tároló szerver bemutatja a felhasználó böngészőjét a tanúsítvánnyal. A böngésző megvizsgálja a tanúsítványon szereplő digitális aláírást, amelyet a megbízható tanúsító hatóság készített, és amely arra utal, hogy a tanúsítványban szereplő összes információ pontos.

Ez az, ahol a tanúsítási láncolat kifejezés játszik szerepet.

A böngésző elolvassa a digitális aláírást, és feljebb mozgat egy linket a láncban – ezután ellenőrzi a közbenső tanúsítvány digitális aláírását, amelynek privát kulcsát használta a levél tanúsítvány aláírására. Folytatja az aláírások követését, amíg vagy a tanúsítványlánc a gyökértárban levő megbízható gyökerek egyikén nem ér véget, vagy amíg a lánc a gyökér elérése nélkül nem fejeződik be. Ebben az esetben megjelenik egy böngészőhiba, és a kapcsolat meghiúsul.

Ez az oka annak, hogy nem adhatja ki és nem írhatja alá saját igazolásait.

A böngészők csak azokba az SSL / TLS-tanúsítványokba fognak bízni, amelyeket vissza tudnak láncolni a gyökértárukba (azaz egy megbízható szervezet kiadta őket). A tanúsító hatóságoknak be kell tartaniuk a meghatározott szabványokat, hogy megőrizzék megbízhatóságukat, és még akkor is, ha a böngészők hajlandók bízni velük.

A böngészők nem rendelkeznek ilyen szavatossággal az önaláírt tanúsítványokkal kapcsolatban, ezért ezeket csak belső hálózatokon, tűzfalak mögött és tesztkörnyezetben szabad telepíteni..

SSL / TLS tanúsítványtípusok és funkcionalitás

Mielőtt mozgásban nézzük az SSL / TLS-t, beszéljünk a tanúsítványokról és a rendelkezésre álló különféle iterációkról. A TLS tanúsítványok megkönnyítik a TLS protokollt, és segítenek diktálni a webhely által titkosított HTTPS kapcsolatok feltételeit..

Korábban megemlítettük, hogy a TLS-tanúsítvány telepítése lehetővé teszi a webhely konfigurálását HTTPS-kapcsolatok létrehozására a 443-as porton keresztül. Ez egyfajta név jelvényként szolgál annak a webhelynek vagy kiszolgálónak, amellyel kapcsolatba lép. Visszatérve arra az ötletre, hogy a szívében az SSL / TLS és a PKI a biztonságos kulcscsere tökéletes formái, az SSL / TLS tanúsítvány segítséget nyújt a böngészőnek annak értesítésében, hogy ki küldi a munkamenet kulcsot – kinek a fél a másik végén. a kapcsolat van.

És ha lebontja az SSL / TLS tanúsítványok különféle ismétléseit, ezt érdemes szem előtt tartani. A tanúsítványok a funkcionalitás és az érvényesítési szint függvényében változnak. Vagy másképpen fogalmazva, ezek a következők szerint változnak:

  • Hány identitást kell állítani
  • Milyen végpontokon lehet identitást érvényesíteni

E két kérdés megválaszolása egyértelműen megmutatja, hogy milyen típusú igazolásra van szüksége.

Hány azonosság Asserthez

Három különböző szintű érvényesítés érhető el az SSL / TLS tanúsítványokkal, és ezek attól függnek, hogy mennyi identitási információt szeretne érvényesíteni az Ön webhelyén.

  • Domain validációs SSL tanúsítványok – Állítsa be a kiszolgáló azonosságát
  • Szervezet validációs SSL tanúsítványok – Állítsa be a részleges szervezet azonosságát
  • Bővített validációs SSL tanúsítványok – Állítsa be a teljes szervezet azonosságát

Domain érvényesítés Az SSL tanúsítványok messze a legnépszerűbbek, áruk és kiállítási sebességük miatt. A DV SSL / TLS tanúsítványok egyszerű tartományvezérlés-ellenőrzést igényelnek, amely többféle módon is elvégezhető, de amint megkapja a tanúsítványt. Ezen kívül 30 és 90 napos verziót is ingyen kaphat, amely kétségtelenül növeli piaci részesedésüket.

A hátránya, hogy a DV SSL tanúsítványok minimális személyazonosságot követelnek meg. És mivel az összes adathalász webhelynek majdnem felében van telepítve egy DV SSL tanúsítvány, nem feltétlenül vásárolnak téged bizalom útján.

Szervezet érvényesítése Az SSL tanúsítványok az SSL / TLS tanúsítvány eredeti típusa. Ezenkívül ezek az egyetlen SSL-tanúsítvány, amely IP-címet tud biztosítani a CAB Fórum 2016-os döntése alapján, amely érvényteleníti az összes intranetes SSL-tanúsítványt. A szervezet validálása könnyű üzleti ellenőrzést igényel, és általában egy vagy két napon belül kiadható – néha gyorsabban. Az OV SSL tanúsítványok tartalmaznak bizonyos szervezeti információkat, de egy internetfelhasználónak rá kell kattintania a lakat ikonra, és meg kell keresnie. Manapság sok OV SSL tanúsítványt látunk telepítve nagyvállalati és vállalati hálózatokban, például tűzfalak mögött létrehozott kapcsolatokhoz..

Mivel sem a DV, sem az OV SSL tanúsítványok nem szolgáltatnak elegendő identitást a legtöbb böngésző kielégítéséhez, ezért semleges kezelést kapnak.

A kibővített validációs SSL tanúsítványok messze a legellentmondásosabbak, mivel a tech közösségben néhányan úgy érzik, hogy még több tennivalót kell tenni az érvényesítés megerősítéséhez, amelytől függnek. De az EV SSL maximális identitást biztosít. A kibővített érvényesítés befejezéséhez a Hitelesítés-szolgáltató egy szigorú ellenőrzési folyamaton keresztül irányítja a szervezetet, amely bizonyos esetekben akár egy hétig is eltarthat..

Az előny azonban tagadhatatlan: mivel elegendő identitást igényel, az EV SSL tanúsítvánnyal rendelkező webhely egyedi böngésző kezelést kap, beleértve annak nevét a böngésző címsorában.

Nincs más módja ennek elérésére, és nem is hamisíthatjuk – az EV címsor az egyik leghatékonyabb vizuális mutató, amely ma van..

Milyen végpontokon alapulhat identitás?

Az SSL / TLS tanúsítványok másik eltérési módja a funkcionalitás. A weboldalak már az internet korai napja óta meglehetősen fejlesztettek, a különböző vállalatok különböző módon telepítik a webhelyeket. Néhányuknak több domain van a különböző vállalati vertikumok számára; mások aldomaineket használnak több funkcióhoz és webes alkalmazásokhoz. Egyesek mindkettőt használják.

Nem számít a környezet, van egy SSL / TLS tanúsítvány, amely segíthet annak biztonságában.

Egyetlen domain

Az elsődleges webhely és a standard SSL tanúsítvány csak egyetlen domain. A legtöbb modern SSL / TLS tanúsítvány biztosítja mind a domain WWW, mind a nem WWW verzióit, ám egyetlen domainre korlátozódik. tudsz hasonlítsa össze az SSL tanúsítványokat itt.

Multi-Domain

Több domain tanúsítványok vagy egységes kommunikációs tanúsítványok (a Microsoft Exchange és az Office Communications szerverek esetében) szintén léteznek, hogy a szervezetek képesek legyenek több domain titkosítására egyetlen tanúsítvánnyal. Ez vonzó lehet, mivel pénzt takarít meg, és sokkal egyszerűbbé teszi a tanúsítványok (lejárati / megújítási) kezelését.

A több domain és az UCC tanúsítványok a SAN-t, a CSR Tárgy alternatív neve mezőjét használják további tartományok hozzáadásához a tanúsítványhoz. A legtöbb CA képes akár 250 különféle SAN-ot engedélyezni egyetlen tanúsítványon. És a legtöbb multi-domain tanúsítványhoz 2–4 ingyenes SAN tartozik, a többi megvásárolható szükség szerint.

Helyettesítő karakterű SSL tanúsítványok

Helyettesítő karakterű SSL tanúsítványok rendkívül hasznos tanúsítványtípusok, mivel korlátlan számú aldomaint kódolhatnak az URL azonos szintjén. Például, ha van olyan webhelye, amely aldomaineket használ, mint például:

  • app.website.com
  • portal.website.com
  • user.website.com

Titkosíthatja őket ugyanazzal a helyettesítő karakter tanúsítvánnyal, ha csillaggal látja el a CSR FQDN mezőjét: * .website.com

Most minden aldomaint – még azokat, amelyeket még nem adott meg – biztosíthatunk ezzel a tanúsítvánnyal.

A Wildcard tanúsítványoknak azonban két hátránya van. Az első az, hogy ha ugyanazt a nyilvános kulcsot használja néhány végponton, akkor kiszolgáltatottabbá válnak bizonyos kizsákmányolásokhoz, például a Bleichenbacher támadásokhoz..

A másik az, hogy nincs EV helyettesítő kártya lehetőség. A helyettesítő karakter funkciók miatt a böngészők nem felelnek meg a megbízhatóság ilyen szintjének átruházásával. Ha az aldomainekre szeretné az EV címsort, akkor ezeket külön kell titkosítania, vagy EV multi-domain tanúsítványt kell használnia..

Több domain helyettesítő karakter

Az SSL / TLS ökoszisztéma viszonylag új kiegészítéseként a Multi-Domain helyettesítő kártya akár 250 különböző domaint is képes titkosítani, de a SAN-mezőkben csillagot is használhat, amely lehetővé teszi 250 különböző domain és mindegyikük előtti titkosítását is. -szintű altartományok.

A multi-domain helyettesítő helyettesítő karakter egy másik példája a többszintű helyettesítő karakter, amely az aldomaineket az URL több szintjén képes titkosítani (a standard helyettesítő karakter csak egy szinten tudja titkosítani)..

A helyettesítő karakterisztika miatt a többtartományú helyettesítő karakterek EV formátumban sem érhetők el.

SSL / TLS mozgásban

Most, hogy lefedtük az SSL / TLS és a PKI korszerűsítésére szolgáló összes lényeges fogalmat, tegyük össze és nézzük mozgásba.

Érvényesítés és kibocsátás

Kezdjük a kezdet kezdetén azzal, hogy egy webhely vásárol SSL / TLS tanúsítványt egy CA-tól vagy viszonteladótól. A vásárlást követően a tanúsítvány-megszerzést kezelő szervezeti kapcsolat létrehoz egy igazolás-aláírási kérelmet azon a kiszolgálón, amelyre a tanúsítványt telepíteni fogja (a webhelyet üzemeltető kiszolgálón)..

A CSR mellett a szerver egy nyilvános / magánkulcsot is generál, és helyben menti a magánkulcsot. Amikor a CA megkapja a CSR-t és a nyilvános kulcsot, elvégzi a szükséges érvényesítési lépéseket annak biztosítása érdekében, hogy a tanúsítványban szereplő információk pontosak legyenek. Általában az üzleti hitelesítési tanúsítványok (nem DV) esetében ez magában foglalja a szervezet regisztrációs adatainak és nyilvános nyilvántartásainak keresését a kormányzati adatbázisokban.

A hitelesítés befejezése után a hitelesítésszolgáltató felhasználja az egyik kibocsátó tanúsítványának egyik privát kulcsát, általában egy közbenső gyökérkönyvtárat, és aláírja a tanúsítványt, mielőtt visszaadja a webhely tulajdonosának..

Most a webhelytulajdonos átveheti az újonnan kiadott SSL / TLS tanúsítványt, telepítheti azt a szerverükre és konfigurálhatja a webhelyet, hogy HTTPS kapcsolatokat létesítsen a 443-as porton (301 átirányítás segítségével forgalmat küld a meglévő HTTP-oldalakról az új HTTPS-társaikhoz)..

Hitelesítés és az SSL kézfogás

Most, hogy az SSL / TLS tanúsítvány telepítve van, és a webhely HTTPS-re van konfigurálva, nézzük meg, hogyan fogja megkönnyíteni a titkosított kapcsolatok létrehozását a webhely látogatóival.

A weboldalra érkezéskor a szerver bemutatja az SSL / TLS tanúsítványt a felhasználó böngészőjében. A felhasználói böngésző ezután ellenőrzések sorozatát hajtja végre.

Először a tanúsítványt hitelesíti a digitális aláírásának megnézésével és a tanúsítványlánc követésével. Ellenőrzi továbbá a tanúsítvány lejártát, és ellenőrzi a Tanúsítvány-átláthatóság (CT) naplóit és a Tanúsítvány-visszavonási listákat (CRL). Feltéve, hogy a lánc visszavezet a rendszer megbízható áruházának egyik gyökeréhez, és érvényes, a böngésző megbízni fog a tanúsítvánnyal.

Most a kézfogás ideje.

Az SSL / TLS kézfogás olyan lépések sorozata, ahol az ügyfél (felhasználó) és a szerver (webhely) megtárgyalja biztonságos kapcsolatának paramétereit, generál és kicseréli szimmetrikus munkamenetkulcsokat.

Először ők fognak dönteni a rejtjelkészletről. A rejtjelkészlet a kapcsolathoz használt algoritmusok és rejtjelek csoportja. Az SSL / TLS tanúsítvány a titkosítási csomagok listáját tartalmazza, amelyeket a szerver támogat. Általában a rejtjelkészlet tartalmaz nyilvános kulcsú titkosítási algoritmust, kulcsgeneráló algoritmust, üzenet-hitelesítési algoritmust és szimmetrikus vagy tömeges titkosítási algoritmust – bár ezt a TLS 1.3 tovább finomította..

Miután megkapta a támogatott rejtjelek listáját, az ügyfél kiválaszt egy kellemes felhasználót, és eljuttatja azt a szerverhez. Innentől az ügyfél előállít egy szimmetrikus munkamenet-kulcsot, titkosítja azt a nyilvános kulcs segítségével, majd elküldi azt a kiszolgálóra, aki rendelkezik a munkamenet-kulcs visszafejtéséhez szükséges magánkulccsal..

Amint mindkét fél megkapja a munkamenet kulcsát, a kommunikáció megkezdődhet.

És ez az SSL / TLS.

Láthatja, hogy az összes fogalom, amellyel korábban átmentünk, kölcsönhatásba lép egymással, hogy kifinomult, ám mégis elegáns rendszert hozzon létre az internetkapcsolatok biztosítása érdekében. A nyilvános kulcsú kriptográfiát használjuk a munkamenet kulcsok biztonságos cseréjére, amellyel kommunikálunk. A szerver vagy a szervezeti identitást igazoló tanúsítványok megbízhatóak lehetnek a különböző CA-k, böngészők és gyökérprogramok közötti infrastruktúra miatt..

A kommunikáció szimmetrikus, magánkulcs-titkosítás eredményeként jön létre, amely az ókor klasszikus kriptoszisztémáiból származik..

Nagyon sok mozgó alkatrész van, de ha lelassítja és megérti őket külön-külön, sokkal könnyebb megfigyelni, hogyan működik együtt.

Mielőtt elmész, végezzünk néhány SSL / TLS-hez kapcsolódó lépéssel, amelyeket telepítés utáni / konfigurálással végezhet el, hogy a legtöbbet hozza ki befektetéséből.

SSL / TLS után – Hozza ki a legtöbbet a megvalósításból

A tanúsítvány telepítése és a webhely helyes konfigurálása nem jelenti azt, hogy a webhelye biztonságos. A TLS a szélesebb körű, holisztikus kibervédelmi stratégia csak egy alkotóeleme. De ennek ellenére fontos elem. Fedezzük fel néhány dolgot, amelyeket megtehet annak érdekében, hogy a lehető legtöbbet hozza ki a megvalósítás.

Letiltja a régi protokollok kiszolgálói támogatását

Megduplázva a Cipher Suites-ról korábban folytatott beszélgetésünket, a kiszolgáló konfigurálásának része annak eldöntése, hogy mely titkosítókészleteket és SSL / TLS-verziókat támogatjuk. Fontos, hogy tiltsa le a régebbi SSL / TLS verziók támogatását, valamint a speciális algoritmusokat, hogy elkerüljük a számos ismert kihasználtsággal szembeni sebezhetőséget..

Az SSL 2.0 és az SSL 3.0 egyaránt 20 évnél régebbi. A legjobb gyakorlat az volt, hogy évekkel ezelőtt csökkentették a támogatásukat, ám a mai napig az Alexa 100 000 fő körülbelül 7% -a továbbra is engedélyezi őket. Ez veszélyes, mert kiteszi Önt az SSL eltávolításának és a támadások leminősítésének, mint például a POODLE.

A TLS 1.0 és a TLS 1.1 szintén kölcsönzött időben van.

A legnagyobb technológiai vállalatok, az Apple, a Microsoft, a Google és a Mozilla együttesen bejelentették a bukást, hogy 2020 elején el fogják veszíteni a TLS 1.0 és 1.1 támogatását..

A protokoll verziói érzékenyek olyan sérülékenységekre, mint a POODLE, a FREAK, BEAST és a CRIME (ezek mind rövidítések). A TLS 1.2 tíz éve működik, ezért a szabványnak kell lennie. A TLS 1.3 múlt nyáron fejeződött be, és az elfogadás azóta folyamatos ütemben halad.

Ezen kívül vannak speciális algoritmusok, amelyeket szintén nem szabad használni. A DES például órák alatt megsérülhet. Az RC4 sebezhetőbb, mint valaha is gondolták, és a Fizetési Kártyaipar adatbiztonsági előírásait már tiltotta. És végül, tekintettel a legutóbbi kihasználásokkal kapcsolatos hírekre, az RSA-t már nem tanácsos kulcst cserélni.

Javasolt algoritmusok / rejtjelek:

  • Kulcscsere: Elliptikus görbe Diffie-Helman (ECDH)
  • Hitelesítés: Elliptikus görbe digitális aláírási algoritmus (ECDSA)
  • Szimmetrikus / tömeges titkosítás: AES 256 Galois Counter módban (AES256-GCM)
  • MAC algoritmus: SHA-2 (SHA384)

Mindig bekapcsolt SSL

A múltban a webhelyek néha csak az információkat gyűjtő weboldalakat migrálták a HTTPS-re, miközben a webhely többi részét HTTP-n keresztül szolgálták fel. Ez rossz gyakorlat.

Amellett, hogy a Google ezeket az oldalakat „Nem biztonságos” jelöléssel látja el, akkor potenciálisan ki is teheti webhelye látogatóit azzal, hogy böngészőik előre-hátra ugrálnak a titkosított oldalak és a HTTP oldalak között..

A teljes webhelyet konfigurálnia kell a HTTPS-re. Ezt hívják mindig bekapcsolt SSL-nek. Végül is nem olyan, mintha az oldal fizet, az SSL / TLS tanúsítványa a teljes webhelyet titkosítja. Tegye így.

Hozzon létre egy hitelesítésszolgáltató engedélyezési (CAA) rekordot

A digitális tanúsítványok által képviselt legfontosabb kockázatok általában a téves kibocsátás. Ha egy nem Öntől kapott fél kiállít SSL / TLS tanúsítványt a webhelyedre, akkor ténylegesen megszemélyesíthet téged és mindenféle problémát okozhat.

A CAA nyilvántartásai enyhítik ezt a kockázatot azáltal, hogy korlátozzák azt, hogy a hitelesítésszolgáltatók miként adhatnak ki digitális tanúsítványokat az Ön webhelyére. A hitelesítésszolgáltatókat a CA / Böngésző fórum köteles ellenőrizni a CAA nyilvántartásait bármilyen tanúsítvány kiadása előtt. Ha a CA-nak nincs felhatalmazása az adott webhely kiadására, akkor nem. Ennek elmulasztása lenne, ha a böngésző közösség haragját felveszik.

A CAA-rekord hozzáadása viszonylag egyszerű, ez egy egyszerű DNS-rekord, amelyet a legtöbb tárhelyi platform felületén lehet hozzáadni. Korlátozhatja azokat a hitelesítésszolgáltatókat, amelyek a domainjéhez kiállíthatnak, valamint azt is, hogy a helyettesítő karakter-tanúsítványokat is ki lehet-e adni számára.

Adja hozzá webhelyét a HSTS előterhelési listájához

A HTTP Szigorú Szállítás Biztonság (HSTS) egy olyan HTTP fejléc, amely a böngészőket csak arra kényszeríti, hogy HTTPS kapcsolatot hozzanak létre egy adott webhellyel. Ilyen módon, még akkor is, ha a webes felhasználó megpróbál az oldal HTTP verziójára lépni, csak a HTTPS verziót látogatja meg. Ez azért fontos, mert lezárja az ablakot számos ismert kizsákmányolásra, például alacsonyabb szintű támadásokra és sütik eltérítésére.

Sajnos egy apró támadásvektor marad a HSTS-nél, ezért kell hozzáadnia webhelyét az előtöltési listához. Általában, amikor egy látogató megérkezik az Ön webhelyére, böngészője letölti a HTTP fejlécet, majd azt betartja mindaddig, amíg a házirendet tartják fenn. De a legelső látogatás előtt, még mielőtt a fejléc megérkezett, van még egy apró nyílás a támadó számára.

A HSTS előzetes letöltési listáját a Google működteti, és annak néhány változatát az összes fő böngésző használja. Ezek a böngészők csak a HTTPS-en keresztül tudnak csatlakozni a listán szereplő bármely webhelyhez – még akkor is, ha még soha nem járt ott. Egy-két hétig is eltarthat, mire a webhely megjelenik a listán, mivel a lista frissítéseit a böngészők kiadási ütemezésével együtt állítják elő..

SSL / TLS GYIK

Mi az X.509 tanúsítvány??

Az X.509 az SSL / TLS és más típusú PKI-k által használt digitális tanúsítvány típusára utal. Az X.509 egy nyilvános kulcsú titkosítási szabvány. Időnként előfordul, hogy a vállalatok X.509 tanúsítványt használnak a „digitális tanúsítvány” vagy a „PKI tanúsítvány” helyett.

Miért lejár az SSL / TLS tanúsítványok??

Ennek két oka van.

Az első az, hogy az internet folyamatosan változik, jönnek a weboldalak, és a webhelyek megy. És mivel a böngészők mennyire érzékenyek ezeknek a tanúsítványoknak a megbízhatóságában, elsősorban azt akarják tudni, hogy a tanúsítványokat bemutató webhelyek rendszeresen érvényesülnek. Nem különbözik annyitól, hogy alkalmanként be kell jelentkeznie, hogy frissítse a vezetői engedélyben szereplő információkat.

A másik ok technikai jellegű. Nehezebb elterjeszteni a frissítéseket és a műszaki változtatásokat, ha a tanúsítványok nem járnak le 3–5 évig. Míg ha a tanúsítványok 24 havonta járnak le, akkor a leghosszabb esetleges tanúsítvány két év lehet. 2017-ben a maximális érvényesség három évről kettőre csökkent. Ez valószínűleg rövidesen 12 hónapra rövidül.

Hogyan lehet megújítani az SSL / TLS tanúsítványt?

A megújítás kissé félrevezető lehet, mivel a régi tanúsítványt kicseréli egy újonnan kiállítottra. Rendszeresen ezt teheti lehetővé, hogy naprakész maradjon a titkosítási technológiával kapcsolatos új fejlesztésekkel, és biztosítja az érvényesítési információk frissítését. A hitelesítésszolgáltatók csak akkor használhatják újra az eredetileg szolgáltatott hitelesítési információt, mielőtt az alapkövetelmények arra kényszerítették őket, hogy újból érvényesítsék.

Megújításkor megtarthatja ugyanazt a tanúsítványtípust, mint korábban, vagy megtehetsz valami újat, megváltoztathatja a CA-kat is. A nagy dolog az, hogy mennyi idő van hátra a lejáró tanúsítványon – akár három hónapot is átvihet. Mindaddig, amíg megújítja a tanúsítvány lejárta előtt, átviheti a fennmaradó időt és újra felhasználhatja azokat az érvényesítési információkat, amelyek még nem tettek le az utolsó érvényesítés óta. Ha hagyja, hogy lejár, akkor a semmiből indul.

Mi a HTTPS ellenőrzés??

Nagyon sok nagyobb, nagyobb hálózatokkal rendelkező vállalat szeretné látni a forgalmát. E tekintetben a HTTPS egy kétélű kard. Védi az emberek magánéletét, de segíthet a számítógépes bűnözők elrejtésében is. Nagyon sok szervezet dekódolja a HTTPS forgalmát egy szélső eszközön vagy egy középdobozban, majd elküldi sima szövegen a tűzfal mögött, vagy újra titkosítja, és elküldi útjára. Ha nem titkosítja újra a forgalmat, akkor ezt SSL-megszüntetésnek hívják. Amikor újra titkosítja, ezt SSL áthidalásnak hívják.

Mi az SSL kirakodás??

Az SSL kirakodás egy másik vállalati gyakorlat. Méretarányosan ezer kézfogás végrehajtása, majd az összes adat titkosítása és visszafejtése adóztathatja a hálózat erőforrásait. Tehát sok nagyobb hálózat le fogja tölteni az SSL funkciókat egy másik eszközre, hogy az alkalmazáskiszolgáló összpontosítson alapvető feladataira. Ezt néha terheléselosztásnak nevezik.

Miért küldött nekem CA köztes tanúsítványt?

Emlékezzen korábban, amikor a gyökérprogramokat tárgyaltuk?

A Very OS rendelkezik egy gyökérraktárral, amelyet a PKI-bizalom megítélésére használ. De a CA-k nem adnak ki végfelhasználói tanúsítványokat ebből a gyökérből, attól tartva, hogy mi történne, ha valaha visszavonják. Ehelyett köztes gyökereket forgatnak, és ezeket kiadják. A probléma az, hogy a közbenső gyökerek nem tartózkodnak a rendszer bizalmi áruházában.

Tehát, ha a webhely nem nyújtja be a közbenső tanúsítványt a levél SSL / TLS tanúsítvánnyal együtt, akkor sok böngésző nem lesz képes kitölteni a tanúsítványláncot, és figyelmeztetést fog kiadni. Néhány böngésző gyorsítótárazó közbenső tanúsítványokat készít, de továbbra is bevált gyakorlatnak számít, ha a közbenső termékeket a levél tanúsítványával együtt telepíti.

Milyen dokumentációra van szükségem egy kibővített validációs SSL tanúsítványhoz?

A legtöbb esetben a kiterjesztett hitelesítést végző tanúsító hatóság először megpróbálja hozzáférni az információkhoz nyilvánosan elérhető „kormányzati” erőforrásokon keresztül.

Egyes helyeken ez azonban nem lehetséges. Van néhány dolog, amely elősegítheti az érvényesítés felgyorsítását. Noha a szakmai vélemény levél által teljesíthető hitelesítési ellenőrzések száma az utóbbi időben csökkent, ügyvéd vagy könyvelő jó státusszal rendelkező személye továbbra is jelentősen segíthet.

Ezen felül benyújthat egy kormány által kibocsátott üzleti hitelesítő adatot vagy “Jogosultság igazolást” dokumentumot, amely feljogosítja a szervezetet a felsorolt ​​név alatt üzleti vállalkozásra. Néhány példa ezekre a dokumentumokra:

  • Alapító okiratok
  • Alapítási bizonyítványok
  • Üzleti / gyártói / kereskedői engedélyek
  • Charta dokumentumok
  • Partnerségi megállapodások
  • Kereskedelmi név vagy feltételezett név regisztrálása
  • Registro Mercantil

Zárva

Remélem, ez ad ötletet az SSL / TLS-ről. Ha többet szeretne tudni, akkor azt javaslom részt vesz ezen az online tanfolyamon.

Ezt a hozzászólást Patrick Nohe, a Az SSL Áruház által kivágott, egy blog, amely a kiberbiztonsági híreket és trendeket tartalmazza.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map