Mi a TLS és hogyan működik?

A szállítási réteg biztonsága (TLS) az egyik legfontosabb és legszélesebb körben alkalmazott biztonsági protokoll. Védi az online módon továbbított adatok jelentős részét. Ez a legszembetűnőbb a webböngésző és a weboldal között a HTTPS-en keresztül átmenő adatok biztonságához, de felhasználható e-mailek és számos más protokoll biztonságára.

A TLS értékes, mivel biztosítja, hogy a kapcsolat másik fele legyen az, akinek állítják, megmutatja, hogy az adatok megőrzik-e eredeti integritását, és titkosítás révén bizalmasságot nyújt-e.

A TLS számos algoritmust és sémát használ e célok eléréséhez. Bonyolultnak tűnhet, de ez a cikk egyszerre csak egy szempontot fed le, hogy mélyrehatóbb képet kapjon arról, hogyan működik a TLS a kapcsolatok biztonságában.

Mit csinál a TLS??

Az információk online küldésekor három fő biztonsági problémával szembesülünk:

• Honnan tudhatjuk, hogy az a személy, akivel kommunikálunk, valóban az, akinek mondják??
• Honnan tudhatjuk, hogy az adatokat nem hamisították meg azóta, hogy elküldték őket?
• Hogyan lehet megakadályozni, hogy mások látják és hozzáférjenek az adatokhoz?

Ezek a kérdések kulcsfontosságúak, különösen akkor, ha érzékeny vagy értékes információkat küldünk. A TLS számos kriptográfiai technikát alkalmaz e három probléma mindkét megoldására. Együtt lehetővé teszik a protokoll számára hitelesítse a másik felet a kapcsolatban, ellenőrizze az adatok integritását és biztosítsa a titkosított védelmet.

Egyszerűsítsük a dolgokat, és tegyünk úgy, mintha az ország egész területén élő barátommal próbálnánk oda-vissza átadni információkat. Ha az információ érzékeny, akkor nagyon aggódik a fent említett három fő probléma miatt.

Nem csak levelet küldhet, és remélheti a legjobbakat, főleg ha gyanítja, hogy kommunikációját támadók célozzák meg. Ehelyett olyan rendszerre van szüksége, amely lehetővé teszi annak ellenőrzését, hogy a címzett jogos-e, a módszer arra, hogy ellenőrizze, hogy az üzenetek megváltoztak-e, és egy módszert, hogy megvédje őket a kíváncsiskodó szemtől..

A TLS számos különféle eljárás alkalmazásával teljesíti ezeket a követelményeket. Akkor kezdődik, amit a TLS kézfogás, ahol történik a hitelesítés és a kulcsok létrehozása.

Visszatérve a levél analógiához, a TLS hitelesítési része olyan lenne, mint egy levél küldése egy futárral, amely azonosítást igényel. Amikor a futár kézbesíti a levelet, összehasonlítják a személy azonosítóját az arcukkal, és ellenőrzik, hogy a címzett a megfelelő volt-e vagy sem.

A kulcsfontosságú létrehozási szakasz egy kicsit olyan lenne, mintha a levélben szerepelne egy olyan PIN-kód felének fele, amelyet a jövőbeni kommunikáció során használni kíván. Arra kéri a címzettet, hogy jöjjön fel a szám második felével, és küldje el neked visszatérő levélben.

Miután a futár ellenőrizte a személyazonosságát és a PIN-kódot meghatározták, mindent megkap, amire szüksége lehet az adatok biztonságos küldéséhez. A valóságban ezek a szakaszok sokkal összetettebbek, de erre később jutunk.

A TLS biztonságosan cserél információt az alkalmazási protokollal. Az analógia folytatása érdekében az adatok biztonságos továbbítása a TLS-en olyan lenne, mint egy üzenet kiírása és borítékba helyezése. Az aláírást a pecsétre írná, hogy ha a levelet megsértették, akkor a címzett képes lenne megmondani a bemásolt aláírással (ezt valójában a matematika végzi, de ezt később is mélyebben fedezzük)..

Ezután a levelet beteszi egy kis fémdobozba, amelyen kombinációs zár is található, és a kombinációt úgy állítja be, mint a PIN-kódot, amelyet a címzettel közösen hoztak létre. A dobozt a futáron keresztül küldné, amely ellenőrzi az azonosítást, amikor a csomagokat kézbesítik. A címzett ugyanolyan módon válaszol, és a jövőbeni kommunikáció ugyanazokat a lépéseket követi.

A TLS viszonylag hasonló módon oldja meg mindhárom problémánkat. A futár hitelesíti a címzettet és ellenőrzi, hogy a dobozt a kívánt személynek szállítják-e. A lezárt doboz a titkosítás egyik formáját szolgálja, megakadályozva, hogy bárki, kivéve a partnere, hozzáférhessen a levelekhez. Az aláírt boríték tudatja vele, hogy nem az üzenet hamisított-e meg.

Ez nagyon durva megközelítés ahhoz, amit a TLS tesz. A valóságban, A TLS az ügyfelek és a kiszolgálók között zajlik, nem pedig két ember, akik levélben küldenek egymást. Az analógia csak az, hogy képet kapjon a történõ eseményekrôl és annak hátterében álló érvelésrõl. A következő részekben részletesebben bemutatjuk, mi történik valójában.

TLS vs. SSL

A TLS-ről olvasva gyakran látni fogja az SSL említését, vagy akár TLS / SSL-ként. A Secure Sockets Layer (SSL) a TLS régi verziója, ám az iparban sokan még mindig hivatkoznak a TLS-re a régi moniker alatt. Ez a cikk az egész TLS kifejezést fogja használni, de fontos megjegyezni, hogy a neveket gyakran felcserélhetően használják. Az SSL-ről bővebben az útmutatóban olvashat.

A TLS története

Az egész azzal kezdődött, hogy biztosítani kellett a szállítási réteget. Mint fentebb említettük, a TLS előfutára az SSL volt. Az SSL első verzióit a kilencvenes években fejlesztette ki a Netscape, egy cég, amely felépítette az egyik korai böngészőt.

Az SSL 1.0 soha nem került kiadásra, mert súlyos sebezhetőségeket tartalmazott. A 2.0-s verzió 1995-ben jelent meg a Netscape Navigator 1.1 segítségével, ennek ellenére számos súlyos hibát tartalmazott. Az SSL 3.0 egy erősen átalakított verzió, és 1996-ban jelent meg, a biztonsági problémák sokaságának megoldásával.

1996-ban, az IETF kiadta az SSL 3.0 tervezetét az RFC 6101-ben. Az IETF munkacsoportot hozott létre az SSL szabványosítása céljából, és az eredményeket TLS 1.0-ként publikálta. Ezt az RFC 2246-ban dokumentálták, és a szabványosítás tartalmazott néhány változtatást az eredeti protokollban, valamint a névváltoztatást. Ezek a módosítások a Netscape, a Microsoft és az IETF munkacsoport közötti tárgyalások eredményeként jöttek létre.

2006-ban az IETF kiadta az RFC 4346-at, amely a TLS 1.1-et dokumentálja. Ez a verzió új biztonsági rendelkezéseket és számos más frissítést tartalmazott. Az 1.2-es verzió csak két évvel később, 2008-ban jelent meg. Ez magában foglalta a hitelesített titkosítási rejtjelek támogatását, a hash-funkciók felhasználásának számos változtatását és sok egyéb fejlesztést..

A következő verzió csak [year]-ban érkezett, amikor a TLS 1.3 meghatározásra került. Számos változtatást tartalmaz, beleértve a kényszerített titkosítást, a gyengébb algoritmusok támogatásának eltávolítását és még sok minden mást.

A TLS 1.0 és 1.1 verziója elavult [year]-ban, de az 1.2 verzió széles körben használatos. Az 1.3 verzió megnövekedett elfogadást lát.

TLS: A műszaki részletek

A TLS sok különböző elemből áll. Alapvető része a rekordprotokoll, az alapjául szolgáló protokoll, amely felelős minden más átfogó struktúrájáért.

A TLS verem ábrája. Jeffreytedjosukmono TLS protokoll verem. CC0 alatt engedélyezett.

A rögzítési protokoll öt különálló protokollt tartalmaz, amelyek mindegyikének formátuma van feljegyzések:

• Kézfogás – Ez a protokoll a biztonságos kapcsolat paramétereinek beállítására szolgál.
• Alkalmazás – Az alkalmazási protokoll a kézfogás után kezdődik, és ott történik az adatok biztonságos továbbítása a két fél között.
• Éber – A riasztási protokollt bármelyik fél használja a kapcsolat felvételéhez, ha hibákat, stabilitási problémákat vagy lehetséges kompromisszumokat jelez a másiknak..
• Cipher Spec. Módosítása – Ezt a protokollt az ügyfél vagy a kiszolgáló használja a titkosítási paraméterek módosítására. Ez elég egyértelmű, ezért ebben a cikkben nem fogjuk mélyebben bemélyedni.
• Heartbeat – Ez egy TLS kiterjesztés, amely lehetővé teszi a kapcsolat egyik oldalán, hogy tudja-e a társa még életben, és megakadályozza a tűzfalak inaktív kapcsolatok bezárását. Ez nem a TLS alapvető része, ezért ebben az útmutatóban kihagyjuk.

Ezen alprotokollok mindegyikét különböző szakaszokban használják különböző információk kommunikálására. A legfontosabb megérteni a kézfogás és az alkalmazási protokollok, mivel ezek felelősek a kapcsolat létrehozásáért, majd az adatok biztonságos továbbításáért..

A TLS kézfogás protokoll

Itt biztonságos módon jön létre a kapcsolat. Bonyolultnak tűnhet, ha Ön új fogalmakkal rendelkezik, de ezekkel később a cikk foglalkozik, ha hivatkozni kell rájuk..

A TLS kézfogásnak három alapvető típusa van: a alapvető TLS kézfogás, az kliens által hitelesített TLS kézfogás és a rövidített kézfogás.

Az alapvető TLS kézfogás

A TLS kézfogás folyamatát szemléltető ábra. Teljes TLS 1.2 kézfogás a FleshGrinder által. CC0 alatt engedélyezett.

Az ilyen típusú kézfogásban csak a szerver hitelesítve van, és nem az ügyfél. A tárgyalási fázissal kezdődik, amikor az ügyfél küld egy Ügyfél Hello üzenet. Ez tartalmazza a TLS legmagasabb verzióját, amelyet az ügyfél támogat, a lehetséges rejtjelkészleteket, annak megjelölését, hogy támogatja-e a tömörítést, egy véletlenszerű számot és néhány egyéb információt

A Client Hello üzenet a következővel találkozik: Szerver Hello üzenet. Ez a válasz tartalmazza a munkamenet azonosítóját, a protokoll verzióját, a rejtjelkészletet és a tömörítést (ha van ilyen), amelyet a kiszolgáló választott az ügyfél listájából. Ez magában foglal egy másik véletlenszámot is.

A kiválasztott rejtjelkészlettől függ, de a kiszolgáló ezt általában követi Bizonyítvány üzenet a hitelesítéshez. Ez érvényesíti identitását és tartalmazza a nyilvános kulcsot.

Ha rövid távú Diffie-Hellman vagy névtelen Diffie-Hellman kulcscseréket használnak, akkor ezt egy Szerverkulcscsere üzenet. Más kulcscsere-módszerek kihagyják ezt a részt. Amikor a szerver befejezte a tárgyalás oldalát, elküldi a Szerver Hello Done üzenet.

Most már az ügyfél fordul újra. A választott rejtjelkészlettől függően a Ügyfélkulcscsere üzenet. Ez tartalmazhat egy nyilvános kulcsot vagy egy előzetes titkot, amelyet a kiszolgáló nyilvános kulcsával titkosítottak.

Ezután mindkét fél a véletlenszerű számokat és az előmester titkot használja, hogy előállítson egy fő titkot. A kulcsok a fő titokból származnak, amelyeket felhasználnak a kommunikáció hitelesítésére és titkosítására.

Az ügyfél ezután küld egy Cipher Spec. Módosítása üzenet. Ez azt mondja a szervernek, hogy a következő üzeneteket most hitelesíteni és titkosítani kell (bár néha a titkosítást nem lehet használni).

Az ügyfél ezt követően a Befejezett titkosított üzenet, amely a hitelesítéshez MAC-t is tartalmaz. A szerver dekódolja ezt az üzenetet, és ellenőrzi a MAC-ot. Ha ezen folyamatok bármelyike ​​meghiúsul, akkor a kapcsolatot el kell utasítani.

Most a szerver fordul, hogy küldjön egy Cipher Spec. Módosítása üzenet, valamint a Befejezett üzenet ugyanazzal a tartalommal, mint a fentiek. Az ügyfél ezután megpróbálja dekódolni és ellenőrizni a tartalmat. Ha mindez sikeresen befejeződik, akkor a kézfogás befejeződik. Ezen a ponton létrejön az alkalmazás protokoll. Az adatok ezután biztonságosan cserélhetők, mint az Befejezett üzenet felülről, hitelesítéssel és opcionális titkosítással.

Ügyfél által hitelesített TLS kézfogás

Ez a kézfogás nagyban hasonlít az alapvető TLS kézfogáshoz, de az ügyfél is hitelesítve van. A fő különbség az, hogy miután a szerver elküldte Bizonyítvány üzenet, ez is küld egy Tanúsítvány igénylés üzenet, az ügyfél igazolásának kérésére. A kiszolgáló befejezése után az ügyfél tanúsítvánnyal küldi el Bizonyítvány üzenet.

Az ügyfél ezután elküldi Ügyfélkulcscsere üzenet, csakúgy, mint az alapvető TLS kézfogás. Ezt követi a Tanúsítvány ellenőrzése üzenet, amely tartalmazza az ügyfél digitális aláírását. Mivel a kiszámítás az ügyfél magánkulcsa alapján történik, a szerver ellenőrizheti az aláírást a nyilvános kulcs segítségével, amelyet az ügyfél digitális tanúsítványának részeként küldtek el. A maradék Ügyfél által hitelesített TLS kézfogás ugyanúgy követi az alapvető TLS kézfogást.

Rövidített TLS kézfogás

Miután már megtörtént a kézfogás, a TLS lehetővé teszi a folyamat nagy részének rövidítését rövidített kézfogás használatával. Ezek a kézfogások a munkamenet azonosítóját használják az új kapcsolat összekapcsolására az előző paraméterekkel.

A rövidített kézfogás lehetővé teszi mindkét fél számára a biztonságos kapcsolat folytatását ugyanazon beállításokkal, mint amelyet korábban tárgyaltak. Mivel a kézfogás kezdeményezésében általában részt vevő kriptográfia nagyon nehéz lehet a számítási erőforrásoknál, ez időt takarít meg, és könnyebbé teszi a kapcsolatot.

A folyamat a következővel kezdődik: Ügyfél Hello üzenet. Nagyon hasonlít a korábbi Client Hello üzenethez, de tartalmazza a munkamenet azonosító a korábbi kapcsolatból. Ha a szerver ismeri a munkamenet azonosítóját, akkor magába foglalja azt Szerver Hello üzenet. Ha nem ismeri fel a munkamenet azonosítóját, akkor egy másik számot ad vissza, és helyette egy teljes TLS-kézfogásra kell kerülnie..

Ha a szerver felismeri a munkamenet azonosítóját, akkor a Bizonyítvány és Kulcscsere lépések kihagyhatók. Az Cipher Spec. Módosítása és Befejezett az üzeneteket ugyanúgy küldjük el, mint a fentebb bemutatott alapvető TLS kézfogást. Miután az ügyfél visszafejtette az üzenetet és ellenőrizte a MAC-t, az adatokat el lehet küldeni a biztonságos TLS kapcsolaton keresztül.

Van egy TLS kiterjesztés, amely lehetővé teszi a kapcsolatok folytatását munkamenet-jegyekkel, a munkamenet-azonosítók helyett. A szerver titkosítja a munkamenet adatait, és elküldi azokat az ügyfélnek. Amikor az ügyfél meg akarja folytatni ezt a kapcsolatot, elküldi a munkamenet jegyet a szervernek, amely dekódolja azt a paraméterek feltárása érdekében..

A munkamenet jegyeket nem használják olyan gyakran, mert meghosszabbításra van szükségük. Ennek ellenére bizonyos helyzetekben előnyösek lehetnek, mivel a szervernek nem kell semmit tárolnia.

A TLS kézfogás kicsomagolása

A kézfogás három legfontosabb lépése a következő:

• a paraméterek vannak kiválasztva,
• hitelesítést hajt végre, és
• a kulcsok be vannak állítva.

Fedjük le őket egy kicsit részletesebben, hogy megértsük, mi történik valójában.

A paraméterek

A kézfogás kezdetén az ügyfél és a szerver közös megegyezéssel tárgyalja a kapcsolat paramétereit. Ezek közül az első a TLS melyik verziója. Ez a legmagasabb verzió, amelyet mindkét fél támogat, ami általában a legbiztonságosabb.

A felek azt is eldöntik, hogy melyik kulcscsere-algoritmust fogják használni a főkulcs létrehozásához. Ebben a szakaszban a hash-funkció, a titkosítási algoritmus és a tömörítési módszer szintén megállapodásra kerül. Ezeket részletesen tárgyaljuk, amikor a Alkalmazási protokoll később a cikkben.

Hitelesítés: Digitális igazolások

A hitelesítés a kommunikációs csatorna biztosításának kulcsfontosságú eleme, mivel mindkét fél tudomására hozza, hogy valójában azokkal beszél, akiknek gondolják magukat, nem pedig bejelentőket. A TLS-ben és sok más biztonsági mechanizmusban ez elérhető a digitális tanúsítványokkal.

A digitális tanúsítványok olyan elektronikus dokumentumok, amelyek megmutatják az egyén vagy entitás és a nyilvános kulcs közötti kapcsolatot. Ezt a linket egy hitelesítésszolgáltató (CA) hitelesíti, amely egy megbízható szervezet, amely ellenőrzi, hogy a kettő valóban kapcsolatban áll-e, majd a saját hírnevét használja a bizalom bizalmának biztosításához..   

A különböző tanúsítási szintek eltérő mértékben jelentik a bizalmat. Fontos tudni, hogy ha az ügyfél vagy a kiszolgáló megbízható és érvényes tanúsítvánnyal rendelkezik, akkor ésszerű feltételezni, hogy a nyilvános kulcs legitim, és hogy nem a támadóval foglalkozik..

Megjegyzés a nyilvános kulcsokon

A nyilvános kulcsú titkosítás (más néven aszimmetrikus titkosítás) a kriptográfia fontos része, és széles körben használják a TLS különféle szempontjain. Itt egy gyors bevezetés azok számára, akik nem ismerik a működését.

A rövid magyarázat erre A nyilvános kulcsú kriptográfia egy kulcs helyett egy kulcspárt használ a titkosításhoz és a dekódoláshoz. A feladó az adatok titkosításához a címzett nyilvános kulcsát használja. Titkosítás után csak a címzett megfelelő magánkulccsal lehet visszafejteni. A nyilvános kulcs természetesen nyilvánosan megosztható, míg a privát kulcsot titokban kell tartani.

A nyilvános kulcsú titkosítás lehetővé teszi a felek számára az információk biztonságos megosztását, még akkor is, ha soha nem találkoztak, vagy nem volt lehetőségük korábban kulcscserére. Ezt a prímszámok néhány egyedi tulajdonságán keresztül teszi meg. További információt a nyilvános kulcsú titkosításról szóló cikkünkben találhat.

Mester titok létrehozása

Mint fentebb láttuk, amikor megvitattuk az alapvető TLS kézfogás folyamatát, miután egy párt (vagy mindkét fél) igazolta személyazonosságát nyilvános tanúsítvánnyal, a következő lépés a fő titok létrehozása, más néven megosztott titok. A fő titok az az alap, amellyel a két fél között továbbított adatok titkosításához és integritásának ellenőrzéséhez használt kulcsok származnak.

A TLS kézfogás számos különféle mechanizmust használhat a titok biztonságos megosztására. Ide tartoznak az RSA, a Diffie-Hellman kulcscsere különféle típusai, a PSK, a Kerberos és mások. Mindegyiknek megvannak a maga előnyei és hátrányai, például biztosítja a későbbi titoktartást, ám ezek a különbségek nem tartoznak a cikk hatálya alá.

A pontos folyamat attól függ, hogy melyik kulcscsere-módszert választották, de az a Az alapvető TLS kézfogás szakasz.

Az előmester titkát a korábban kiválasztott kulcscsere-módszer szerint vezetik le. Az ügyfél a kiszolgáló nyilvános kulcsával titkosítja az előzetes titkot, hogy biztonságosan elküldje azt a kapcsolaton keresztül.

Ezután az ügyfél és a szerver egyaránt használja az előtétbiztos titkot és a véletlenszerű számokat, amelyeket a kommunikáció kezdetén küldtek, hogy feljusson a fő titokhoz. A mesterkulcs kiszámítása után arra használják, hogy négy vagy hat különálló kulcsot állítson elő. Ezek a:

• Az ügyfél írja a MAC-kulcsot – Ezt a kulcsot a szerver használja az ügyfél által elküldött adatok integritásának ellenőrzésére.
• Szerver írja a MAC kulcsot – A szerverírás MAC kulcsot az ügyfél használja a kiszolgáló által elküldött adatok integritásának ellenőrzésére.
• Ügyfél írási titkosítási kulcs – A szerver ezt a kulcsot használja az ügyfél által elküldött adatok titkosításához.
• Szerver írási titkosítási kulcs – Az ügyfél ezt a kulcsot használja a szerver által elküldött adatok titkosításához.
• Az ügyfél írja az IV kulcsot – A kliens írási IV kulcsot a kiszolgáló használja az AEAD rejtjelekben, de nem, ha más kulcscsere-algoritmusokat használnak.
• Szerver írási kulcs – Hasonlóképpen, ezt a kulcsot az ügyfél használja az AEAD rejtjelekben, de nem, ha más kulcscsere-algoritmusokat használnak.

A mesterkulcs létrehozása a TLS kézfogás fontos része, mivel lehetővé teszi a kapcsolat mindkét oldalán a kulcsok biztonságos származtatását, amelyek felhasználhatók mind hitelesítésre, mind titkosításra. Elővigyázatosságként külön kulcsokat használunk mindkét folyamathoz.

A hitelesítési és titkosítási kulcsok származtatása után mindkettő védelmére szolgálnak Befejezett üzenetek, valamint az alkalmazásprotokollon keresztül küldött rekordok.

Az alkalmazás protokollja

Miután biztonságos kapcsolatot létesített a TLS kézfogás, az alkalmazási protokollt kell használni a továbbított adatok védelmére. Konfigurálható az algoritmusok széles skálájának felhasználására, hogy megfeleljen a különböző forgatókönyveknek.

Hitelesítési algoritmusok

Az üzenetek integritása számos különféle algoritmussal ellenőrizhető. Ezek tartalmazzák:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

A küldött adatok integritásának igazolására a feladó az információt kivonat-funkción keresztül futtatja, hogy egyedi karakterláncot adjon vissza. Ez olyan speciális képlet, amely mindig ugyanazt az eredményt adja vissza, amikor ugyanazt a bemenetet megkapja.

A feladó ezeket az adatokat saját magánkulccsal írja alá, hogy digitális aláírást kapjon. A digitális aláírást ezután csatolják az üzenethez, és elküldik a címzettnek. Annak ellenőrzése, hogy az adatok megőrzik-e integritását, és hogy nem történt-e megsértésük, a címzett a feladó nyilvános kulcsával dekódolja a kivonatot. Ezután ugyanazt a hash-funkciót használják az elküldött adatokra. A címzett ezt követően összehasonlítja a két értéket.

Ha ugyanazok, ez azt jelenti, hogy az adatokat nem változtatta meg a küldő aláírása óta. Ha eltérőek, akkor valószínű, hogy az adatokat meghamisították, vagy más hiba történt.

Ez a rövid változat, amely szerint a hash-funkciók felhasználhatók az adatok integritásának bemutatására. Ha mélyebb megértést szeretne, olvassa el a titkosításról, sózásáról és kivonásáról szóló cikket.

Titkosítási algoritmusok

A TLS szimmetrikus kulcsos titkosítást használ az átvitt adatok bizalmas kezelése érdekében. A nyilvános kulcsú titkosítással ellentétben csak egy kulcsot használunk mind a titkosítási, mind a dekódolási folyamatban. Miután az adatokat egy algoritmus titkosította, rejtjelező szövegként jelenik meg. Amíg megfelelő algoritmust használnak, a támadók nem férnek hozzá a tényleges adatokhoz, még akkor sem, ha elfogják azokat.

A TLS számos különféle algoritmust használhat, például Camellia vagy ARIA, bár a legnépszerűbb az AES.

összenyomás

A tömörítés az adatkódolás folyamata, hogy kevesebb helyet foglaljon el. A TLS támogatja a tömörítést, ha a kapcsolat mindkét oldala úgy dönt, hogy ezt használja. E képesség ellenére általában ajánlott elkerülni a TLS használatát az adatok tömörítésére, különösen a CRIME támadás óta (lásd: TLS biztonsági kérdések az alábbiakban ismertetett szakasz) megállapította, hogy képes használni a tömörített adatokat a munkamenet eltérítésére.

Párnázás

A padding extra adatokat ad hozzá az üzenetnek a titkosítás előtt. Ez egy általános kriptográfiai folyamat, amelyet arra használunk, hogy megakadályozzuk, hogy a titkosított adatok struktúráján szereplő utalások valódi jelentését megadják. A TLS általában a PKCS # 7 kitöltést alkalmazza az iratok titkosítása előtt.

Riasztási protokoll

Ha a kapcsolat vagy a biztonság instabillá válik, veszélybe kerül, vagy súlyos hiba történt, a riasztási protokoll lehetővé teszi a feladó számára, hogy értesítse a másik felet. Ezeknek az üzeneteknek két típusa van: figyelmeztető vagy végzetes. A figyelmeztető üzenet jelzi, hogy a munkamenet instabil, és lehetővé teszi a címzett számára, hogy meghatározza, folytatja-e a munkamenetet.

Egy végzetes üzenet jelzi a címzettnek, hogy a kapcsolat sérült vagy komoly hiba történt. Az üzenet elküldése után a feladónak bezárnia kell a kapcsolatot. A riasztási protokoll információkat tartalmaz arról is, hogy mi okozza az adott kapcsolódási problémát. Ide tartoznak például a visszafejtési hiba, az ismeretlen igazolási hatóság, az illegális paraméterek és még sok más.

TLS & az OSI modell

Az OSI modell lehetővé teszi a különböző kommunikációs rendszerek és protokollok szemléletmódjának fogalommeghatározását és egységesítését. Fontos megjegyezni, hogy ez csak egy modell, és néhány protokollunk nem felel meg ennek.

Az OSI hét külön réteggel rendelkezik, amelyek megmutatják a szintet, amelyen a protokollok működnek, A TLS egyetlen csoportba sem illeszkedik. Átfolyik egy másik szállítási protokollon, például a TCP-n, ami azt jelenti, hogy a negyedik réteg, a szállítási réteg felett fekszik. A legszembetűnőbb, mint egy szállítási réteg, de mivel kézfogást végez, ez azt jelentené, hogy része a prezentációs vagy az alkalmazási rétegeknek.

Mint láthatja, a TLS egyszerűen nem felel meg az OSI modellnek. Ez nem azt jelenti, hogy a TLS megsérült vagy hibás, ha van ilyen, csak azt mutatja, hogy az OSI modell hibás és nem képes elszámolni az összes kommunikációs protokollt.

TLS használat

A TLS segítségével online kommunikációnk jelentős részét biztosítjuk. Általában olyan protokollokon keresztül valósítják meg, mint a Átviteli vezérlő protokoll (TCP), de felhasználható a Datagram Congestion Control Protocol-ban (DCCP) és a User Datagram Protocol-ban (UDP).

Biztosíthat olyan protokollokat, mint a HTTP, SMTP, FTP, XMPP és NNTP, valamint mások. A leggyakoribb alkalmazás a Hypertext Transfer Protocol Secure (HTTPS), amely védi a böngésző és a webhely közötti kapcsolatot. Megmondhatja, hogy mikor használja a HTTPS-t az online kapcsolat biztosításához, mert egy kis zöld zár ikon jelenik meg az URL bal oldalán a böngésző tetején.

A TLS VPN-k létrehozására is felhasználható, mint például az OpenConnect és az OpenVPN. A titkosítási és hitelesítési képességei alapján alagutat képez, amely összekapcsolhatja a gazdagépeket és a hálózatokat. Az olyan TLS-alapú VPN-technológiák, mint az OpenVPN, előnyösek az olyan alternatívákkal szemben, mint az IPsec, mivel az OpenVPN-nek nem ismert súlyos biztonsági problémái. Ezeket a VPN-ket könnyebben konfigurálhatják.

Egy másik felhasználási területe az biztonságos e-mail a STARTTLS-en keresztül. A TLS megvalósítása megakadályozza, hogy a támadók hozzáférjenek az üzenetekhez, amikor e-mail szerverek között utaznak.

TLS biztonsági kérdések

A legtöbb protokollhoz hasonlóan a TLS-nek is számos korábbi sebezhetősége és elméleti támadása volt a különféle megvalósításai ellen. Ennek ellenére, a legújabb verziók biztonságosnak tekinthetők gyakorlati célokra.

A korábbi verziók, mint például az SSL 2.0 és 3.0 (és a TLS 1.0, amely lényegében megegyezik az SSL 3.0-tal) számos biztonsági hibát tartalmaznak, de mivel ezek régi és elavult protokollok, nem fogunk belemélyedni a részletekbe. Ehelyett a TLS 1.2 és 1.3 verziót kell használnia a kapcsolatok biztonságossá tételéhez.

A TLS újabb verziója számos frissítéssel rendelkezik, amelyek kevésbé érzékenyek, mint az SSL. Ennek ellenére a protokollnak még mindig a következő biztonsági kérdései merültek fel:

Újratárgyalási támadások

A TLS egyik jellemzője, hogy lehetővé teszi az ügyfél és a szerver párok számára, hogy újra megbeszéljék a meglévő kapcsolat paramétereit. 2009-ben fedezték fel, hogy ezt a támadók kihasználhatják, hogy forgalmat injektálhassanak, hogy úgy látszanak, mintha az az ügyféltől származik. A kiszolgálók elfogadják a kérést legitimnek, ami azt jelenti, hogy a támadók potenciálisan manipulálhatják a kimenő üzeneteket.

Ez a támadás nem teszi lehetővé a támadó számára, hogy láthassa a választ, de ennek ellenére káros lehet. Jelenleg javasolt szabvány egy kiterjesztés, amely megakadályozza ezeket a támadásokat.

VADÁLLAT

Az SSL / TLS (BEAST) elleni böngésző támadását a kutatók először fedezték fel 2011-ben. Kihasználja a TLS titkosítási blokkoló láncának sebezhetőségét, amely felhasználható az üzenetek visszafejtésére. Ez a támadás csak a TLS 1.0-t érinti, amely a protokoll régi és gyengébb verziója. Noha ez [year]-ig nem csökken, a felhasználóknak inkább az 1.2 és 1.3 verziót kell használniuk.

Időzített támadások

Ezek az oldalsó csatornatámadások elemzik, hogy mennyi ideig tart az algoritmus futtatása, majd felhasználják ezeket az információkat a visszalépéshez és a kulcs kitalálásához. 2013-ban felfedezték a Lucky Thirteen támadást, hogy kihasználja mind az időzítési támadást, mind a kitöltő oraklám támadását, miközben az üzenet hitelesítési kódját (MAC) ellenőrzik. Ez a támadás felhasználható a TLS algoritmus megtörésére, bár a TLS-felhasználók többsége számára ez nem tekinthető veszélyesnek.

BŰN & MEGSZEG

A CRIME támadás számos protokoll ellen működik. Ha az adatok tömörítésre kerülnek, akkor az tartalmat kivonhat a hitelesítési sütikből. Ez az információ felhasználható munkamenet-eltérítésre. Noha számos protokollt érint, a támadás különösen aggasztó, amikor a HTTP-tömörítést használják, mivel nincsenek hatékony enyhítő stratégiák..

2013-ban úgy találták, hogy a böngésző megismerése és kiszűrése a Hypertext adaptív tömörítésén keresztül (BREACH) hasonló módon befolyásolja a HTTP-tömörítést. A támadás ezen verziója helyreállíthatja az e-mail címeket és egyéb értékes adatokat, amelyeket a TLS titkosított. A BREACH támadást csökkentheti a HTTP tömörítés letiltása, vagy olyan technikák használata, mint például a helyszínek közötti kérelem-hamisítás (CSRF) védelme..

Csökkent támadások

Ezek olyan támadások, amelyek becsapják a kiszolgálókat a TLS korábbi és kevésbé biztonságos verzióinak használatába. A támadók ezeket a technikákat használhatják a kevésbé biztonságos kulcscsere és rejtjelek használatának tárgyalására. A Logjam támadás jó példa, mert a kiszolgáltatott szerverek 512 bites Diffie-Hellman-et használhatnak, ami gyenge. A támadók ezután megtörhetik ezt a kulcscsere-mechanizmust és kibonthatják a kulcsokat, így teljes hozzáférést biztosítva a munkamenethez.

heartbleed

A szívverés egy biztonsági hiba, amelyet véletlenül bevezettek az OpenSSL rejtjelezési könyvtárba 2012-ben, Mivel ez a TLS ilyen általánosan alkalmazott megvalósítása, jelentős globális károkat okozott.

A TLS szívverés-kiterjesztésének egyik fejlesztője egy puffer túlolvasott biztonsági rést adott meg, amely lehetővé teszi bizonyos további adatok feltárását. A hibát a kód áttekintésekor nem vették fel, ami számos jelentős támadáshoz vezetett.

Mivel az OpenSSL könyvtár ilyen széles körben kerül alkalmazásra, a probléma enyhítésének nemzetközi költsége meglehetősen drága volt. A kiszolgáló rendszergazdáinak telepíteniük kellett az új javítást, és újra kell regenerálniuk a tanúsítványokat és a kulcspárokat, amelyek a sérülékenység fennállásának kétéves időszakában esetleg veszélybe kerültek..

MEGFULLAD

Az RSA visszafejtésének elavult és gyengült eNcryption (DROWN) támadással 2016-ban jelent meg, és kihasználja az SSL 2.0 szerver támogatását. Kiválasztott titkosított szöveges támadást alkalmaz az olyan kiszolgálók ellen, amelyek továbbra is támogatják az SSL 2.0-t, valamint azokat, amelyek ugyanazt a nyilvános kulcsot tanúsítják egy másik szerverrel, amely támogatja az SSL 2.0-t..

Amikor a támadást bejelentették, a támadás kezdeti költségei mintegy 18 000 dollár és körülbelül 400 dollár minden egyes támadásért. Amikor a DROWN támadás sikeres, megszerzi a munkamenet kulcsokat.

A támadást enyhítheti az, ha nem osztja meg a szerver tanúsítványokat. Az OpenSSL csoport olyan javításokat is kiadott, amelyek eltávolítják a régebbi protokollok és rejtjelek támogatását, de ezek csak akkor működnek, ha a szerver tanúsítványát nem osztják meg az SSL 2.0-t támogató más szerverekkel..

Unholy PAC

Ezt a támadást 2016-ban találták meg. Kihasználja a Web Proxy Autodiscovery Protocol (WPAD) hiányosságait. Amikor egy felhasználó TLS titkosított kapcsolaton keresztül próbál meglátogatni egy webhelyet, a hiba láthatóvá teheti az URL-t. Mivel az URL-eket néha hitelesítés formájában küldik a felhasználóknak, az Unholy PAC támadás lehetővé teszi a támadó számára, hogy átvegye a felhasználói fiókot.

A TLS biztonságos?

Noha úgy tűnik, hogy sok biztonsági kérdés merül fel, a valóság az, hogy ezek többsége meglehetősen kisebb jelentőségű, és enyhíteni lehet. A technológia fejlődésével a sebezhetőségeket felfedezik és új támadásokat fejlesztenek ki, a TLS-nek továbbra is több biztonsági problémája van. Ennek ellenére egyelőre és a belátható jövőben úgy tűnik, hogy a TLS továbbra is az egyik legfontosabb és legmegbízhatóbb eszköz, amelyet online világunk védelmére használunk..

Kiberbiztonsági üzleti technológia A TheDigitalArtist licenc alatt áll CC0