Mi tls, savepearlharbor

Általános információk a TLS

Miután az SSL protokoll által szabványosított IETF (Internet Engineering Task Force), átkeresztelték a TLS. Ezért, bár a nevét az SSL és a TLS felcserélhetők, attól még más, mint az egyes ismertet egy másik protokoll verzióját.

Mint már említettük, TLS volt a célja, hogy a munka a TCP azonban dolgozni datagramszolgáltatás protokollokat, mint az UDP (User Datagram Protocol), egy speciális változata a TLS alakult, úgynevezett DTLS (datagram Transport Layer Security).

Titkosítás, hitelesítés, integritás és

A TLS protokoll célja, hogy a három szolgáltatást minden futó alkalmazást, nevezetesen, titkosítás, hitelesítés és integritását. Technikailag nem minden három lehet használni, de a gyakorlatban, hogy biztosítsák a biztonságos, általában használja mind a három:

Annak megállapítása érdekében, biztonságosan titkosított adatcsatornán kapcsolat csomópontok meg kell egyezni a titkosítási módszerek és kulcsokat. TLS protokoll egyedileg meghatározza azt az eljárást, még tárgyalja a fenti TLS handshake. Meg kell jegyezni, hogy a TLS nyilvános kulcsú, ami lehetővé teszi a csomópontok célja egy közös titkos titkosítási kulcs nélkül előzetes ismerete egymást.
Csak a TLS handshake eljárás, azt lehet megállapítani a valódi személyazonosságát az ügyfél és a kiszolgáló. Például az ügyfél biztos lehet benne, hogy a szerver, amely azt információkat a bankszámlán, a bank valóban a szerveren. Ezzel szemben a cég szerverén lehet benne, hogy a kliens csatlakozik hozzá - ez volt alkalmazottja, nem egy harmadik féllel (ez a mechanizmus az úgynevezett bizalmi láncot és lesz szó a vonatkozó fejezetben).

Végül TLS biztosítja a küldő minden üzenet kóddal MAC (Message Authentication Code), ami egy algoritmus, amely - egy egyirányú kriptográfiai hash függvény (valójában - egy ellenőrző), a kulcsok amelyekről ismert, hogy mindkét fél a kommunikáció. Amikor üzenetet küld, által generált MAC-értéket lehet előállítani és a vevő biztosítja az adatok integritását és azok védelmét hamisítást.

Így röviden tekinthető mindhárom mechanizmusa TLS protokoll kriptobezopasnosti.

TSL kézfogás

Mielőtt elkezdené az adatcsere esetében a TLS, a kliens és a szerver meg kell állapodnia a kapcsolat paramétereit, nevezetesen: a felhasznált változatot protokoll titkosítási módszert, és ellenőrizze, igazolások, ha szükséges. A rendszer megkezdi vegyület úgynevezett TLS handshake és alább látható:

Nézzük részletesen az egyes lépéseket az eljárás:

Mivel TLS fut TCP, TCP-kapcsolat beállítása indul a kliens és a szerver.
A telepítés után a TCP, az ügyfél elküldi a szervernek leírás szöveges formában (azaz protokoll verzió, amely azt akarja, hogy használja a támogatott titkosítási módszerek, stb.).
A szerver fenntartja változata a használt protokollt, válasszon egy titkosítási módszert a listából, tulajdonít a tanúsítványát, és küldi el a választ, hogy az ügyfél (ha szükséges, a szerver is kérheti a kliens tanúsítvány).
protokoll és a titkosítási eljárás változat ebben a pillanatban elfogadottnak tekintendők, a kliens ellenőrzi küldött igazolást és kezdeményezi vagy az RSA, vagy a kulcs csere DiffieHellman-, beállítástól függően.
A kiszolgáló feldolgozza a kliens küld egy üzenetet, ellenőrzi a MAC, és elküldi a kliens egy végső ( „kész”) üzenetet küld az ügyfél titkosított formában.
Az ügyfél dekódolja a vett üzenetet, ellenőrzi a MAC, és ha minden rendben van, akkor a kapcsolat létrejön, és megkezdődik a megosztás alkalmazás adatait.

Egyértelmű, hogy a létesítmény egy TLS kapcsolatot, általában hosszadalmas és időigényes folyamat, ezért a TLS szabvány, van néhány optimalizálást. Különösen, van egy eljárást, úgynevezett „rövidített kézfogás”, amely lehetővé teszi a használatát előzetesen egyeztetett paraméterek csökkentése vegyület (persze, ha az ügyfél és kiszolgáló között TLS-kapcsolat a múltban). Ezt az eljárást részletesen tárgyalja a „folytatása session”.

Emellett van egy további bővítése a kézfogás eljárás, amely az úgynevezett TLS rajt. Ez a bővítmény lehetővé a kliens és a szerver elindításához cseréje titkosított adatokat megállapítását követően azonnal a titkosítási eljárást, amely csökkenti a kapcsolat beállítási üzeneteket egy ciklus. Ezt mondták részletesen bekezdésben „TLS False Start”.

Key Exchange TLS protokoll

Különböző történelmi és kereskedelmi okokból leggyakrabban használt TLS kulcscsere algoritmus az RSA: Az ügyfél generál szimmetrikus kulcsot, kódolja a szerver nyilvános kulcsával, és elküldi a szervernek. Másfelől, a kiszolgáló az ügyfél kulcs visszafejtése a privát kulcsot. Ezt követően, a kulcs csere nyilvánítják befejeződött. Ez az algoritmus van egy hátránya: ez egy pár Szabadtéri privát kulcsot használnak, hogy hitelesítse a szerverre. Ennek megfelelően, ha egy támadó hozzáférést nyer a szerver privát kulcsával, akkor dekódolni a teljes ülés. Sőt, a támadó egyszerűen írja be a teljes munkamenet titkosított változata majd tegyen egy átirat, ha tudja, hogy a szerver privát kulcs. Ugyanakkor, kulcs csere DiffieHellman-védettebb, amint szimmetrikus kulcs soha nem hagyja el a kliens vagy szerver, és ezért nem lehet elfogott támadók, akkor is, ha tudja, a privát kulcs a szerver. Ez a szolgáltatás alapja csökkentve annak kockázatát, hogy veszélyeztetné a korábbi üléseken: egy új létrehozása minden egyes új ülésén, az úgynevezett „átmeneti” szimmetrikus kulcsot. Ennek megfelelően, még a legrosszabb esetben (ha az ellenféltől ismeri a szerver privát kulcs), a támadó csak megkapja a kulcsokat, hogy a jövőben ülés, de nem tudja visszafejteni a korábban rögzített.

Abban a pillanatban, minden böngésző telepítésekor a TLS kapcsolatok előnyben részesítik a kombinációja DiffieHellman-algoritmus és alkalmazása ideiglenes kulcsok biztonságának növelése érdekében.

Emlékeztetni kell jegyezni, hogy a nyilvános kulcsú titkosítás használják csak a TLS handshake eljárás a kezdeti beállítás során a kapcsolatot. Miután az alagút beállítás jön szimmetrikus titkosítás, és a kommunikáció az aktuális munkamenet titkosított szimmetrikus kulcsok. Meg kell növelni a sebességet, a nyilvános kulcsú titkosítás jóval nagyobb feldolgozási teljesítmény.

A újrakezdését TLS munkamenet

Mint már korábban említettük, a teljes TLS handshake eljárás meglehetősen időigényes és drága tekintve számítási költség. Ezért olyan eljárást, amely lehetővé teszi, hogy folytassa a korábban megszakított kapcsolat alapján a már beállított adat került kialakításra.

Mivel az első nyilvános változata a protokoll (SSL 2.0) szerver a TLS handshake (vagyis az első jelentést ServerHello) képes generálni és elküldeni egy 32 bájtos műveleti azonosítót. Természetesen ebben az esetben a szerver tárolja az előállított cache azonosító és a műveleti paramétereket minden egyes ügyfél. Másfelől, az ügyfél üzletek ő küldött azonosítót, és egy olyan (persze, ha van ilyen), hogy az eredeti üzenet ClientHello. Ha mind a kliens és a szerver azonos munkamenet-azonosítókat, a telepítés egy közös csatlakozási történik az egyszerűsített algoritmus az ábrán látható. Ha nem, akkor van szükség teljes változatát TLS handshake.

Az eljárás folytatása a munkamenet lehetővé teszi, hogy kihagyja azt a lépést, így egy szimmetrikus kulcs, ami nagyban javítja a telepítési idő kapcsolat, de nem befolyásolja a biztonságot, mint a korábban alkalmazott neskomprometirovannye adatok az előző ülésen.

Azonban van egy praktikus korlátozás: mivel a szerver kell adatokat tárolni az összes nyilvános ülésein, ez vezet a probléma népszerű erőforrásokat igényelt, ugyanakkor több ezer, több millió ügyfél.
Kerülő probléma alakult mechanizmusa «Session Ticket», amely szükségtelenné teszi az adatok tárolására minden ügyfél számára a kiszolgálón. Ha az ügyfél az első telepítés során kapcsolatot jelzi, hogy támogatja ezt a technológiát, a kiszolgáló során TLS handshake küld az ügyfél egy úgynevezett Session Ticket - kapcsolati paraméterek, titkosított szerver privát kulcs. A következő alkalommal a folytatása az ülés, a kliens elküldi a ClientHello elérhető ő Session Ticket. Így a szerver mentesül annak szükségességét, hogy az adatok tárolására minden tekintetben, de a kapcsolat továbbra is biztonságos, mivel a Session Ticket titkosított kulccsal ismert, csak a szerver.

TSL rajt

kapcsolat újrafelvételét protokoll technológia kétségtelenül növeli a termelékenységet és csökkenti a számítási költség, de ez nem vonatkozik a kezdeti kapcsolatot a szerver, vagy ha az előző munkamenet lejárt.
A még nagyobb teljesítményű lett kifejlesztve TLS False Start technológia opcionális meghosszabbítása protokoll, és lehetővé teszi, hogy adatokat küldjön, ha a TLS handshake kitölteni csak részben. Részletes TLS rajt program az alábbiak szerint:

Fontos megjegyezni, hogy a TLS rajt nem változtatja meg a TLS handshake eljárást. Ez azon a feltételezésen alapul, hogy abban a pillanatban, amikor a kliens és a szerver már ismeri a kapcsolat paramétereit és szimmetrikus kulcsok, alkalmazás adatok már elküldte, és az összes szükséges ellenőrzést lehet végezni párhuzamosan. Ennek eredményeként, a kapcsolat készen áll, hogy az egyik üzenetküldő iteráció előtt.

TLS Chain bizalom

Hitelesítés szerves részét képezi az egyes TLS kapcsolatot. Tekintsük a legegyszerűbb hitelesítési folyamat között Alice és Bob:

Aliz és Bob létre saját nyilvános és titkos kulcsokat.
Alice és Bob kicserélik nyilvános kulcsokat.
Aliz egy üzenetet, kódolja a saját titkos kulcsot és elküldi Bobnak.
Bob kapott Alice a kulccsal dekódolja az üzenetet, és így ellenőrzi a vett üzenetet.

Egyértelmű, hogy a rendszer a bizalomra épül Aliz és Bob közötti. Feltételezzük, hogy a csere a nyilvános kulcsok történt, például az ember, és így, Alice biztos, hogy a kulcsot közvetlenül a Bob és Bob viszont biztos, hogy Alice nyilvános kulcsa.

Tegyük fel, hogy Alice üzenetet kap Charlie, akivel nem ismeri, de aki azt állítja, hogy barátok Bob. Ennek bizonyítására, Charlie kérte előzetesen bejelentkezni a saját nyilvános kulcsát zárt Bob nyilvános kulcsát, és csatolja az aláírást az üzenethez, hogy Alice. Alice az első ellenőrzés Bob szignója Charlie kulcs (ez képes megtenni, mert Bob nyilvános kulcsa már ismert), meg van győződve arról, hogy Charlie tényleg Bob barátja, figyelembe az üzenetet, és végrehajtja a már ismert integritás-ellenőrzés, ügyelve arra, hogy az üzenet valóban a Charlie :

Azt az előző bekezdésben a létrehozása a „bizalmi láncot” (vagy «bizalmi láncot», ha angol nyelven).
A TLS, a lánc bizalom alapja eredetiségigazolásokra által nyújtott speciális szervezeteket, úgynevezett tanúsítványkibocsátókat (CA - tanúsítvány hatóságok). CA ellenőrizze, és ha ki, tanúsítvány veszélybe kerül, a tanúsítvány visszavonása.

A kiadott bizonyítványok áll már tekinthető bizalmi láncot. A gyökér ez az úgynevezett „Root CA tanúsítvány” - által aláírt igazolást egyik fő központja, melyek hitelessége vitathatatlan. Általában a bizalmi láncot így néz ki:

Természetesen vannak olyan esetek, amikor szükséges, hogy visszavonja a kiadott tanúsítványt, illetve törölni (például veszélybe került saját tanúsítvány kulcs veszélybe került, vagy a teljes tanúsítási eljárás). Ehhez a hitelességét az igazolások tartalmazzák különleges utasításokat ellenőrzi azok helytállóságát. Ezért, amikor az épület egy bizalmi láncot, szükség van, hogy ellenőrizze a jelentősége az egyes bizalom egység.

A mechanizmus Ennek a vizsgálatnak az egyszerű és ez alapján az úgynevezett „Tanúsítvány-visszavonási lista» (CRL - «tanúsítvány-visszavonási lista»). Mind a CA az a lista, amely egy egyszerű listát sorszámát visszavont tanúsítványok. Ennek megfelelően, aki azt akarja, hogy ellenőrizze a bizonyítvány hitelességét, egyszerűen töltse be a listát, és néztem ellenőrzi a tanúsítvány száma. Ha a szám megtalálható - ez azt jelenti, hogy a tanúsítvány visszavonása.

Itt nyilvánvaló van némi technikai irracionalitás: ellenőrizni egyetlen bizonyítvány szükséges lekérdezni a teljes listát a visszavont tanúsítványok, amely maga után vonja lassulás. Ennek leküzdésére mechanizmust fejlesztettek néven „Certificate Status Protocol» (OCSP - Online Certificate Status Protocol). Ez lehetővé teszi a tanúsítvány állapotellenõrzés dinamikusan. Természetesen ez csökkenti a terhelést a hálózati sávszélesség, de ugyanakkor ad okot, hogy számos problémát:

CA kell megbirkózni a terhelés valós időben;
CA biztosítaniuk kell, hogy a rendelkezésre álló bármikor;
Mivel a valós idejű lekérdezi CA információt kapni arról, hogy mi oldalakat látogatják minden felhasználó számára.

Tulajdonképpen minden modern böngésző, mindkét megoldás (OCSP és CRL) kiegészítik egymást, sőt, mint általában beállíthatja a preferált a tanúsítvány állapotának érvényesítési politika.

Így ez a cikk foglalkozik a kulcsfontosságú eszközök által nyújtott TLS protokoll adatok védelme érdekében. Egyes gag Article'm sajnálom, ára az eredeti célja a fordítást.