Mi az a TLS-kézfogás, és hogyan működik?

A TLS az egyik leggyakrabban használt biztonsági eszköz az interneten. A protokoll aktívan működik számos hálózati kommunikációs folyamattal: fájlátvitel, VPN-kapcsolatok (egyes megvalósításokban kulcscseréhez), azonnali üzenetküldő szolgáltatások vagy IP-telefónia.

A protokoll egyik kulcsfontosságú eleme a kézfogás. Ebben a cikkben erről fogunk beszélni.

"SSL/TLS kézfogás" a HTTPS-kapcsolat létrehozásának lépésének neve. Az SSL/TLS protokollhoz kapcsolódó munka nagy részét ebben a szakaszban végzik el. Tavaly az IETF véglegesítette a TLS 1.3-at, amely teljesen átalakította a kézfogási folyamatot.
A cikk kétféle kézfogással foglalkozik - a TLS 1.2 és TLS 1.3 protokollokhoz, amelyeket az absztrakt szinttől kezdve, fokozatosan a konkrétumokba mélyedve fogunk figyelembe venni:

• kriptográfiai protokollok koordinálása;
• hitelesítés SSL tanúsítvánnyal;
• munkamenet kulcs generálása.

Hogyan működik a TLS kézfogás?

A HTTPS-kapcsolat két félből áll: a kliensből (a kapcsolat kezdeményezője, általában egy webböngészőből) és a szerverből. Az SSL/TLS kézfogás célja az összes titkosítási munka elvégzése a biztonságos kapcsolat létrehozásához, beleértve a használatban lévő SSL tanúsítvány hitelességének ellenőrzését és a titkosítási kulcs generálását.

Tárcsázós egyeztetés

Minden szoftver egyedi. Ezért még a legnépszerűbb webböngészők is eltérő funkciókkal rendelkeznek. Hasonlóképpen a szerver oldalon – a Windows Server, az Apache és az NGINX is különbözik egymástól. A dolgok még bonyolultabbá válnak, ha egyéni konfigurációkat ad hozzá.

Ez az oka annak, hogy a TLS-kézfogás első lépése az, hogy a kliens és a szerver információt cseréljenek képességeikről a támogatott kriptográfiai funkciók további kiválasztásához.

Amint az ügyfél és a kiszolgáló megállapodnak a használandó rejtjelkészletről, a szerver elküldi az SSL-tanúsítványát az ügyfélnek.

Hitelesítés

A tanúsítvány kézhezvétele után az ügyfél ellenőrzi annak hitelességét. Ez egy rendkívül fontos lépés. A biztonságos kapcsolat biztosításához nemcsak titkosítania kell az adatokat, hanem arról is gondoskodnia kell, hogy azok a megfelelő webhelyre kerüljenek. Az SSL/TLS tanúsítványok biztosítják ezt a hitelesítést, és ennek módja a használt titkosítási csomagtól függ.

Minden megbízható SSL-tanúsítványt egy tanúsító hatóság (CA) bocsát ki. A hitelesítésszolgáltatónak szigorú szabályokat kell követnie a tanúsítványok kiadására és érvényesítésére vonatkozóan, hogy megbízható legyen. A CA-ra úgy is gondolhat, mint egy közjegyzőre – az aláírása azt jelenti, hogy a tanúsítványban szereplő adatok valódiak.

A TLS-kézfogás hitelesítési része során az ügyfél számos titkosítási szempontból biztonságos ellenőrzést hajt végre, hogy megbizonyosodjon arról, hogy a kiszolgáló által kiadott tanúsítvány érvényes. A folyamat magában foglalja a digitális aláírás ellenőrzését, és azt, hogy a tanúsítványt megbízható CA állította-e ki.

Ezen a ponton az ügyfél közvetetten ellenőrzi, hogy a kiszolgáló birtokában van-e a tanúsítványhoz társított privát kulcs.

Az RSA-ban, a legszélesebb körben használt nyilvános kulcsú titkosítási rendszerben az ügyfél a nyilvános kulcsot használja a véletlenszerű adatok titkosításához, amelyeket a munkamenetkulcs generálásához használnak majd. A szerver csak akkor tudja majd visszafejteni és felhasználni ezeket az adatokat, ha rendelkezik privát kulccsal, amelynek megléte biztosítja a fél hitelességét.

Ha más kriptorendszert használnak, az algoritmus változhat, de a másik fél hitelessége továbbra is ellenőrzésre kerül.

Kulcscsere

A TLS kézfogás utolsó része egy „munkamenetkulcs” létrehozását foglalja magában, amelyet ténylegesen a biztonságos kommunikációhoz használnak majd.

A munkamenet kulcsai "szimmetrikusak", vagyis ugyanazt a kulcsot használják a titkosításhoz és a visszafejtéshez.

A szimmetrikus titkosítás gyorsabb, mint az aszimmetrikus titkosítás, így alkalmasabb HTTPS-kapcsolaton keresztüli adatküldésre. A kulcsgenerálás pontos módja a választott rejtjelkészlettől függ, a két leggyakoribb az RSA és a Diffie-Hellman.

A kézfogás befejezéséhez mindkét fél közli a másikkal, hogy minden szükséges munkát elvégezett, majd ellenőrzi az ellenőrző összegeket, hogy megbizonyosodjon arról, hogy a kézfogás minden beavatkozás vagy sérülés nélkül történt.

A teljes SSL-kézfogás néhány száz ezredmásodperc alatt történik. Ez az első dolog, ami HTTPS-kapcsolaton történik, még a weboldal betöltése előtt. Az SSL-kézfogás után egy titkosított és hitelesített HTTPS-kapcsolat kezdődik, és az ügyfél és a szerver által küldött és fogadott összes adat védett.

A TLS 1.3-ig minden alkalommal, amikor felkeresett egy webhelyet, a kézfogás megismétlődött. A TLS 1.3 kézfogás támogatja a 0-RTT vagy nulla oda-vissza folytatási időt, ami nagymértékben megnöveli a visszatérő látogató sebességét.

Lépésről lépésre kézfogási folyamat a TLS 1.2-ben

Nézzük meg közelebbről a TLS-kézfogást az RSA használatával. A Diffie-Hellman algoritmus használatát az alábbiakban ismertetjük.

1. Az első üzenet a "Client Hello" nevet kapta. Ez az üzenet felsorolja az ügyfél képességeit, így a kiszolgáló kiválaszthatja a kommunikációhoz használandó titkosítási csomagot. Az üzenet egy nagy, véletlenszerűen kiválasztott prímszámot is tartalmaz, az úgynevezett „kliens véletlenszáma”.
2. A szerver udvariasan „Szerver Hello” üzenettel válaszol. Ott közli a klienssel, hogy milyen kapcsolati paramétereket választottak ki, és visszaadja a véletlenszerűen kiválasztott prímszámot, amelyet "szerver véletlenszámának" neveznek. Ha az ügyfél és a kiszolgáló nem ugyanazon a titkosítási csomagon osztozik, a kapcsolat meghiúsul.
3. A Tanúsítvány üzenetben a szerver elküldi az SSL-tanúsítványláncát a kliensnek, beleértve a levelező- és köztes tanúsítványokat is. Miután az ügyfél megkapta őket, több ellenőrzést is végrehajt a tanúsítvány ellenőrzése érdekében. Az ügyfélnek azt is ellenőriznie kell, hogy a szerver rendelkezik-e a tanúsítvány privát kulcsával, ami a kulcscsere/előállítási folyamat során történik.
4. Ez egy opcionális üzenet, amely csak bizonyos kulcscsere-módszerek esetén szükséges (például Diffie-Hellman), amelyek további adatokat igényelnek a kiszolgálótól.
5. A "Server Hello Done" üzenet értesíti a klienst, hogy a szerver befejezte az adatátvitelt.
6. Az ügyfél ezután részt vesz a munkamenetkulcs létrehozásában. Ennek a lépésnek a részletei az eredeti Hello-üzenetekben kiválasztott kulcscsere-módszertől függenek. Mivel RSA-ról beszélünk, a kliens egy véletlenszerű bájtkarakterláncot generál, amelyet pre-master secret-nek neveznek, titkosítja azt a szerver nyilvános kulcsával, és visszaadja.
7. A "Change Cipher Spec" üzenet tudatja a másik féllel, hogy a munkamenetkulcs létrejött, és átválthat egy titkosított kapcsolatra.
8. Ekkor egy „Kész” üzenet kerül elküldésre, jelezve, hogy a kézfogás a kliens oldalon befejeződött. Ettől a pillanattól kezdve a kapcsolatot munkamenetkulcs védi. Az üzenet olyan adatokat (MAC) tartalmaz, amelyek segítségével ellenőrizhető, hogy a kézfogást nem manipulálták-e.
9. Most a szerver visszafejti a fő titkot, és kiszámítja a munkamenet kulcsát. Ezután "Change Cipher Spec" üzenetet küld, amely értesíti, hogy titkosított kapcsolatra vált.
10. A szerver egy "Kész" üzenetet is küld az újonnan generált szimmetrikus munkamenetkulcs használatával, és ellenőrzi az ellenőrző összeget a teljes kézfogás integritásának ellenőrzésére.

Ezen lépések után az SSL-kézfogás befejeződött. Mindkét fél rendelkezik munkamenetkulccsal, és titkosított és hitelesített kapcsolaton keresztül kommunikálhat.

Ekkor a webalkalmazás első bájtjai (az aktuális szolgáltatáshoz kapcsolódó adatok - HTML, Javascript stb.) elküldhetők.

Lépésről lépésre kézfogási folyamat a TLS 1.3-ban

A TLS 1.3 kézfogás lényegesen rövidebb, mint elődje.

1. A TLS 1.2-höz hasonlóan a "Client Hello" üzenet kezdeményezi a kézfogást, de ezúttal sokkal több információt tartalmaz. A TLS 1.3 37-ről 5-re csökkentette a támogatott rejtjelek számát. Ez azt jelenti, hogy a kliens kitalálhatja, hogy milyen kulcsmegállapodást vagy csereprotokollt használ, így az üzeneten kívül elküldi a kitalált protokollból származó nyilvános kulcs részét.
2. A szerver „Szerver Hello” üzenettel válaszol. Az 1.2-es kézfogáshoz hasonlóan ebben a szakaszban is elküldik a tanúsítványt. Ha a kliens a csatolt adatokkal helyesen találta ki a titkosítási protokollt, és a szerver beleegyezett, akkor az utóbbi elküldi a nyilvános kulcs rá eső részét, kiszámítja a munkamenet kulcsát és a „Server Finished” üzenettel fejezi be az átvitelt.
3. Most, hogy az ügyfél rendelkezik minden szükséges információval, ellenőrzi az SSL-tanúsítványt, és a két nyilvános kulcsot használja a munkamenetkulcs másolatának kiszámításához. Amikor ez megtörtént, "Kliens kész" üzenetet küld.

A TLS kézfogás fölött

Korábban az SSL/TLS-sel kapcsolatos egyik panasz az volt, hogy túlterhelte a szervereket további többletterheléssel. Ez befolyásolta azt a mára megszűnt elképzelést, hogy a HTTPS lassabb, mint a HTTP.

A TLS 1.2 előtti kézfogások sok erőforrást igényeltek, és nagy léptékben komolyan terhelhetik a szervert. Még a TLS 1.2 kézfogások is lelassulhatnak, ha egyszerre sok történik. A hitelesítés, a titkosítás és a visszafejtés drága folyamatok.

Kisebb webhelyeken ez valószínűleg nem okoz észrevehető lassulást, de a napi több százezer látogatót fogadó vállalati rendszereken ez komoly probléma lehet. A kézfogás minden új verziója jelentősen leegyszerűsíti a folyamatot: a TLS 1.2 két fázist hajt végre, míg a TLS 1.3 csak egybe illeszkedik, és támogatja a 0-RTT-t.

A TLS 1.3 kézfogás fejlesztései a TLS 1.2-hez képest

A fenti magyarázatban a kézfogás tíz különálló szakaszra oszlik. A valóságban sok ilyen dolog egyidejűleg történik, ezért gyakran csoportosítják őket és fázisoknak nevezik.

A TLS 1.2 kézfogásnak két fázisa van. Néha továbbiak is szükségesek lehetnek, de ha mennyiségről van szó, az alapértelmezett forgatókönyv az optimális.

Az 1.2-vel ellentétben a TLS 1.3 handshake egy fázisba illeszkedik, bár pontosabb lenne másfélét mondani, de így is lényegesen gyorsabb, mint a TLS 1.2.

Rejtjelkészletek csökkentése

Soha senkinek nem állt szándékában 37 programcsomagot használni az adatok titkosításához, így alakult ki a protokoll. Minden alkalommal, amikor új algoritmust adtak hozzá, új kombinációkat adtak hozzá, és hamarosan az IANA 37 különböző titkosítási csomagot kezelt.

Ez két okból rossz:

1. Ez a változatosság hibás konfigurációkhoz vezet, amelyek sebezhetővé teszik az internetfelhasználókat az ismert kizsákmányolásokkal szemben.
2. Ez még zavaróbbá tette az SSL beállítását.

Az IETF megszüntette a TLS 1.3 legbiztonságosabb algoritmusainak támogatását, így a választási lehetőségek korlátozásával megszüntette a zavart. Különösen a kulcscsere módszerének megválasztását törölték. Az efemer Diffie-Hellman séma lett az egyetlen módja annak, hogy a kliens a kézfogás első részében elküldje kulcsfontosságú információit a "Client Hello"-val együtt. Az RSA titkosítást az összes többi statikus kulcscsere-sémával együtt teljesen eltávolították.

Ennek ellenére van egy lehetséges Achilles-sarka a TLS 1.3-ban.

Nulla oda-vissza folytatási idő – 0-RTT

A 0-RTT az, amiért az egész technológiai világ sürgetett, és most megérkezett a TLS 1.3-mal. Mint említettük, a TLS kézfogás történelmileg lassú volt, ezért fontos volt felgyorsítani. A 0-RTT ezt úgy teszi meg, hogy tárol néhány titkos információt a kliensről, általában egy munkamenet-azonosítót vagy munkamenetjegyeket, amelyeket a következő kapcsolatnál használhat fel.

A 0-RTT minden előnye ellenére tartalmaz néhány lehetséges buktatót. Ez a mód fogékonnyá teszi az ügyfeleket az újrajátszható támadásokra, ahol a támadó, akinek valahogy sikerül hozzáférnie a titkosított munkamenethez, megszerezheti a 0-RTT adatokat, beleértve az ügyfél első kérését is, és visszaküldheti a szervernek.

Az exploit azonban nem könnyen használható. Ez a kockázat valószínűleg csekély árat jelent egy rendkívül hasznos funkcióért.

Biztonság

Kezdettől fogva aggodalomra ad okot, hogy egy kézfogás során mennyi információ érkezett tiszta szöveggel. Nyilvánvalóan ez nem biztonságos, tehát minél több kézfogási lépés történik titkosítva, annál jobb.

A TLS 1.2-es kézfogásban az egyeztetési szakaszok nem voltak védettek, ehelyett egy egyszerű MAC funkciót használtak annak biztosítására, hogy senki ne zavarja az átvitelt. A tárgyalási szakasz magában foglalja a „Client Hello” és a „Server Hello” üzeneteket.

A MAC funkció indikátorként működik, de nem nyújt semmilyen biztonsági garanciát. Talán hallott már olyan támadásról, amely kevésbé biztonságos protokollok és funkciók használatára kényszeríti a feleket (downgrade támadás). Ha a szerver és a kliens is támogatja az elavult titkosítási csomagokat – erről a kapcsolat lehallgatásával könnyen beszerezhető információ –, a támadó a szerver által választott titkosítást gyengébbre cserélheti. Az ilyen támadások önmagukban nem veszélyesek, de megnyitják az ajtót az eredeti titkosítási programcsomag egyéb ismert kihasználásai előtt.

A TLS 1.3 kézfogás a kapcsolat korai szakaszában digitális aláírást használ, így biztonságosabb, és megvédi a titkosítást feltörő támadásoktól. Az aláírás lehetővé teszi a szerver gyorsabb és hatékonyabb hitelesítését is.

Most pedig nézzük meg, hogyan valósulnak meg a TLS 1.3-as kézfogás frissítései magának az SSL/TLS-kézfogásnak mindhárom fő funkciójában.

TLS kézfogás titkosító csomagok

A titkosítási csomag olyan algoritmusok halmaza, amelyek meghatározzák a biztonságos kapcsolat paramétereit.

Minden kapcsolat elején a legelső interakció, a „Client Hello” a támogatott rejtjelkészletek listája. A szerver a legjobb, legbiztonságosabb opciót választja, amelyet támogat, és megfelel a követelményeknek. Megnézheti a rejtjelkészletet, és kitalálhatja az összes kézfogási és csatlakozási paramétert.

TLS 1.2 titkosítási csomagok

• A TLS egy protokoll.
• Az ECDHE egy kulcscsere algoritmus.
• Az ECDSA egy hitelesítési algoritmus.
• Az AES 128 GCM egy szimmetrikus titkosítási algoritmus.
• Az SHA256 egy kivonatoló algoritmus.

A fenti példa az efemer elliptikus görbe Diffie-Hellman (DH) rendszert használja a kulcscseréhez és az Elliptic Curve digitális aláírási algoritmust a hitelesítéshez. A DH az RSA-val is összekapcsolható (digitális aláírási algoritmusként működik) a hitelesítés végrehajtásához.

Íme a legszélesebb körben támogatott TLS 1.2 titkosítási csomagok listája:

TLS 1.3 titkosítási csomagok

• A TLS egy protokoll.
• Az AES 256 GCM egy hitelesített titkosítási algoritmus csatolt adatokkal (AEAD).
• Az SHA384 a hash kulcsgeneráló függvényalgoritmus (HKFD).

Azt már tudjuk, hogy a Diffie-Hellman efemer kulcscsere valamelyik verzióját fogjuk használni, de a paramétereket nem ismerjük, így a TLS 1.2 titkosítócsomag első két algoritmusára már nincs szükség. Ezek a funkciók továbbra is működnek, csak a kézfogás során már nem kell egyeztetni velük.

A fenti példából láthatja, hogy az AES-t (Advanced Encryption Standard) nagy mennyiségű adat titkosítására használják. Galois számláló módban működik, 256 bites kulcsokkal.

Íme az öt titkosítási csomag, amelyet a TLS 1.3 támogat:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

Mi változott a TLS 1.3-ban a TLS 1.2-hez képest?

Fontos megjegyezni, hogy az 1.3-as verziót a biztonsági és teljesítménybeli fejlesztések szem előtt tartásával tervezték. Ennek érdekében a TLS 1.3-ban újratervezték a kulcsgeneráló algoritmust, és kijavították az ismert sebezhetőségeket.

A TLS 1.3 kézfogás bizonyos folyamatokat is javít, például az üzenetek hitelesítését és a digitális aláírásokat.

Végül a régebbi kulcsgenerálási vagy -csere-algoritmusok fokozatos megszüntetése mellett a TLS 1.3 kiküszöböli a régebbi szimmetrikus rejtjeleket. A TLS 1.3 teljesen kiküszöbölte a blokk titkosításokat. A TLS 1.3-ban engedélyezett szimmetrikus titkosítás egyetlen típusa a hitelesített titkosítás további adatokkal (AEAD). Egy funkcióban egyesíti a titkosítást és az üzenethitelesítést (MAC).

Hitelesítés a TLS kézfogásban

Történelmileg a két fő kulcscsere opció az RSA és a Diffie-Hellman (DH), manapság a DH-t gyakran az elliptikus görbe kulcscserével (ECDH) társítják. Néhány alapvető hasonlóság ellenére alapvető különbségek vannak a kulcscsere e két megközelítése között.

Más szavakkal, az RSA TLS kézfogás eltér az ECDH TLS kézfogástól.

Az RSA prímtényezőket és moduláris aritmetikát használ. A nagy prímszámok kiszámításához sok CPU-teljesítményre van szükség, és nehéz megtalálni őket.

A Diffie-Hellmant néha exponenciális kulcscserének is nevezik, ami hatványozásra utal (a moduláris aritmetika mellett), de maga a DH valójában nem titkosít vagy dekódol semmit. Tehát a „matematikai érvelés” helyett „titkosítási módszer”-nek nevezni kissé félrevezető lehet.

Egy rövid történelmi kirándulás tisztázhatja ezt a kérdést.

Whitfield Diffie és Martin Hellman még 1976-ban készített egy kulcscsere protokollt Ralph Merkle munkája alapján, akinek nevének mindkettő szerint szerepelnie kell a protokoll nevében is.

Megpróbálták megoldani a biztonságos kulcscsere problémáját egy nem biztonságos csatornán keresztül, még akkor is, ha egy támadó hallgat rá. Sikerült is, de volt egy nagy hiba: a DH-kulcscsere nem tartalmazott hitelesítést, így nem lehetett igazolni a kapcsolat másik végén lévő felet.

Ez tekinthető a nyilvános kulcsú kriptográfia és a PKI születésének. Röviddel azután, hogy Diffie és Hellman bemutatta kulcscsere protokollját, elkészültek az RSA kriptorendszer legkorábbi verziói. Diffie és Hellman megalkották a nyilvános kulcsú titkosítás koncepcióját, de magával az egyirányú titkosítási funkcióval még nem álltak elő.

Ron Rivest (R az RSA-ban) alkotta meg azt a koncepciót, amely végül az RSA kriptorendszerré vált.

Az RSA sok tekintetben a DH szellemi utódja. A következőket hajtja végre:

• kulcsgenerálás;
• kulcscsere;
• Titkosítás;
• dekódolás.

Így az RSA egy olyan képességesebb algoritmus, amely képes kezelni a kulcscserét és a digitális aláírásokat is, vagyis a biztonságos kulcscsere mellett hitelesítést is. Ezért az RSA nagyobb kulcsokkal rendelkezik: megfelelő biztonságot kell biztosítani a digitális aláíráshoz.

Míg az RSA kezeli a hitelesítést és a kulcscserét, a Diffie-Hellman csak a kulcscserét segíti elő. A DH családnak négy gyakori változata van:

• Diffie-Hellman (DH);
• efemer (rövid távú) Diffie-Hellman (DHE);
• elliptikus görbe Diffie-Hellman (ECDH);
• Elliptikus görbe efemer Diffie-Hellman (ECDHE).

Diffie-Hellman megint csak önmagában nem hitelesít semmit. Digitális aláírási algoritmussal együtt kell használni. Így például, ha ECDH-t vagy ECDHE-t használt, a legtöbb rejtjelkészlet az Elliptic Curve Digital Signature Algorithm-mel (ECDSA) vagy az RSA-val lesz párosítva.

Hitelesítés a TLS 1.2 kézfogásban

Ahogy az imént említettük, az RSA kiegészítő funkciói a digitális aláírással történő hitelesítéshez nagy kulcsokat igényelnek, amelyek ellenállnak a brute force támadásoknak. Ezeknek a kulcsoknak a mérete nagymértékben megnöveli a számítási, titkosítási és visszafejtési költségeket a kézfogás során.

Másrészt, ha Diffie-Hellman nem hajt végre hitelesítést, akkor mit csinál? Mint fentebb említettük, a DH-t gyakran használják elliptikus görbe kriptográfiával együtt hitelesítés és kulcscsere biztosítására.

Az elliptikus kriptográfia (ECC) sokkal kisebb kulcsméretekkel rendelkezik, amelyek illeszkednek az alapjául szolgáló elliptikus görbéhez. Öt megfelelő görbe létezik ehhez az összefüggéshez:

• 192 bit;
• 224 bit;
• 256 bites;
• 384 bites;
• 521 bit.

De nem ez az egyetlen különbség az ECC nyilvános/magán kulcsok és az RSA kulcsok között. Két teljesen különböző célra használják a TLS kézfogás során.

Az RSA-ban a nyilvános/privát kulcspárt a szerver hitelesítéshez és a szimmetrikus munkamenetkulcs-cseréhez egyaránt használják. Valójában a pre-master secret sikeres használata hitelesíti a szervert.

A Diffie-Hellman esetében a nyilvános/privát kulcspár NEM használható szimmetrikus munkamenetkulcs cseréjére. Amikor Diffie-Hellman érintett, a privát kulcs valójában a kísérő aláírási algoritmushoz (ECDSA vagy RSA) van társítva.

RSA hitelesítés

Az RSA hitelesítési folyamat a kulcscsere folyamatához kapcsolódik. Pontosabban a kulcscsere a hitelesítési folyamat része.

Amikor egy kliensnek bemutatják a kiszolgáló SSL-tanúsítványát, több jelzőt is ellenőriz:

• digitális aláírás nyilvános kulccsal;
• egy tanúsítványlánc, amely biztosítja, hogy a tanúsítvány a megbízhatósági tároló egyik gyökértanúsítványából származzon;
• lejárati dátum, hogy megbizonyosodjon arról, hogy nem járt le;
• tanúsítvány visszavonásának állapota.

Ha mindezen ellenőrzések sikeresek voltak, akkor az utolsó tesztet hajtják végre - a kliens a szerver nyilvános kulcsával titkosítja az elő-főtitkot, és elküldi. Bármely kiszolgáló megpróbálhat bármilyen SSL/TLS-tanúsítványt sajátjaként átadni. Végül is ezek nyilvános tanúsítványok. Így a kliens hitelesítheti a szervert a privát kulcs „működés közben” láttán.

Így, ha a szerver vissza tudja fejteni a fő titkosítás előtti titkosítást, és felhasználja a munkamenetkulcs kiszámításához, akkor hozzáférést kap. Ez ellenőrzi, hogy a szerver a használt nyilvános/privát kulcspár tulajdonosa.

DH hitelesítés

Diffie-Hellman és ECDSA/RSA használata esetén a hitelesítés és a kulcscsere egymás mellett működik. Ez pedig visszavezet minket a kulcsokhoz és azok használatához. Az RSA nyilvános/privát kulcsot kulcscserére és hitelesítésre egyaránt használják. A DH+ECDSA/RSA esetén az aszimmetrikus kulcspárt csak a digitális aláírási vagy hitelesítési fázisban használják.

Amikor az ügyfél megkapja a tanúsítványt, továbbra is elvégzi a szabványos ellenőrzéseket:

• ellenőrzi az aláírást a tanúsítványon,
• tanúsítvány lánc,
• érvényesség,
• áttekintés állapota.

A magánkulcs tulajdonjogát azonban másképp ellenőrzik. A TLS kézfogási kulcscsere során (4. lépés) a szerver a privát kulcsával titkosítja a kliens és a szerver véletlenszámát, valamint a DH paraméterét. Ez a kiszolgáló digitális aláírásaként működik, és az ügyfél a hozzá tartozó nyilvános kulcs segítségével ellenőrizheti, hogy a kiszolgáló a kulcspár jogos tulajdonosa.

Hitelesítés a TLS 1.3 kézfogásban

A TLS 1.3-ban a hitelesítés és a digitális aláírás továbbra is fontos szerepet tölt be, de az egyeztetés egyszerűsítése érdekében eltávolították a titkosítási csomagokból. A szerver oldalon valósulnak meg, és biztonságuk és mindenütt jelenlétük miatt számos, a szerver által támogatott algoritmust használnak. A TLS 1.3 három fő aláírási algoritmust tesz lehetővé:

• RSA (csak aláírás),
• Elliptikus görbe digitális aláírási algoritmus (ECDSA),
• Edwards Digital Signature Algorithm (EdDSA).

A TLS 1.2-es kézfogással ellentétben a TLS 1.3-as kézfogás hitelesítési része nincs magához a kulcscseréhez társítva. Inkább a kulcscserével és az üzenet hitelesítéssel párhuzamosan kerül feldolgozásra.

Ahelyett, hogy szimmetrikus MAC-áramkört futtatna a kézfogás integritásának ellenőrzésére, a szerver aláírja a teljes visszafejtési kivonatot, amikor a „Server Hello” üzenetet adja vissza a megosztott kulcs egy részével.

Az ügyfél megkapja a "Server Hello" által továbbított összes információt, és szabványos SSL/TLS-tanúsítvány-hitelesítési ellenőrzéseket hajt végre. Ez magában foglalja a tanúsítványon lévő aláírás ellenőrzését, majd a visszafejtési hashhez hozzáadott aláírással való összehasonlítást.

Az egyezés megerősíti, hogy a szerver birtokolja a titkos kulcsot.

Kulcscsere TLS-kézfogásban

Ha kiemeli ennek a szakasznak a fő gondolatát, ez így fog hangzani:

Az RSA megkönnyíti a kulcscserét azáltal, hogy lehetővé teszi a kliens számára, hogy titkosítson egy megosztott titkot, és elküldje azt a kiszolgálónak, ahol a megfelelő munkamenetkulcs kiszámítására szolgál. A DH kulcscseréhez valójában egyáltalán nincs szükség nyilvános kulcscserére, inkább mindkét fél közösen hoz létre egy kulcsot.

Ha ez most kissé elvontnak hangzik, akkor ennek a résznek a végére mindennek világosabbnak kell lennie.

RSA kulcscsere

Az RSA-kulcscsere elnevezése valójában téves elnevezés. Ez valójában RSA titkosítás. Az RSA aszimmetrikus titkosítást használ a munkamenetkulcs létrehozásához. A DH-val ellentétben a nyilvános/privát kulcspár nagy szerepet játszik.

Ez a következőképpen történik:

1. xÉs y
2. Az ügyfél generál előmesteri titok(a), majd a kiszolgáló nyilvános kulcsával titkosítja és elküldi a szervernek.
3. A szerver dekódolja előmesteri titok a megfelelő privát kulcs segítségével. Most mindkét oldal rendelkezik mindhárom bemeneti változóval, és keverje össze néhány pszeudo véletlen függvényekkel (PRF), hogy létrehozzon egy mesterkulcsot.
4. Mindkét fél keveri a főkulcsot még több PRF-fel, és megkapja a megfelelő munkamenet-kulcsokat.

DH kulcscsere

Így működik az ECDH:

1. A kliens és a szerver két prímszámot cserél ( xÉs y), amelyeket véletlen számoknak nevezünk.
2. Az egyik fél kiválaszt egy titkos számot előmesteri titok a), és kiszámítja: x a mod y. Ezután elküldi az eredményt (A) a másik résztvevőnek.
3. A másik oldal is ezt teszi, a sajátját választva előmesteri titok(b) és kiszámítja x b mod y, majd visszaküldi az értékét (B).
4. Ezt a részt mindkét oldal a megadott értékek elfogadásával és a művelet megismétlésével fejezi be. Az ember számol b a mod y, a másik kiszámítja a b mod y.

Létezik egy modulo tulajdonság, amely szerint mindkét oldal ugyanazt az értéket kapja, ami a kapcsolat során a szimmetrikus titkosításhoz használt kulcs lesz.

TLS 1.2 kézfogás a DH-hoz

Most, hogy megtudtuk, miben különbözik a DH az RSA-tól, nézzük meg, hogyan néz ki egy DH-alapú TLS 1.2 kézfogás.

Ismét sok hasonlóság van a két megközelítés között. A kulcscseréhez az ECDHE-t, a hitelesítéshez pedig az ECDSA-t használjuk.

1. Az RSA-hoz hasonlóan az ügyfél egy "Client Hello" üzenettel kezdi, amely tartalmazza a titkosítási csomagok listáját, valamint az ügyfél véletlenszámát.
2. A szerver a „Server Hello” üzenettel válaszol, amely tartalmazza a kiválasztott rejtjelkészletet és a szerver véletlenszámát.
3. A szerver elküldi az SSL tanúsítványát. Az RSA TLS kézfogáshoz hasonlóan az ügyfél egy sor ellenőrzést hajt végre a tanúsítvány hitelességére vonatkozóan, de mivel a DH maga nem tudja hitelesíteni a kiszolgálót, további mechanizmusra van szükség.
4. A hitelesítés végrehajtásához a szerver veszi a kliens és a szerver véletlenszámait, valamint a munkamenetkulcs kiszámításához használt DH paramétert, és titkosítja azokat saját privát kulccsal. Az eredmény digitális aláírásként fog működni: a kliens a nyilvános kulccsal ellenőrzi az aláírást és azt, hogy a szerver a kulcspár jogos tulajdonosa, és saját DH paraméterével válaszol.
5. A szerver ezt a fázist egy "Szerver Hello Done" üzenettel fejezi be.
6. Az RSA-val ellentétben a kliensnek nem kell aszimmetrikus titkosítással elküldenie a főtitkot a szervernek, hanem a kliens és a szerver a korábban kicserélt DH-paramétereket használja a pre-master secret megszerzéséhez. Ezután mindenki az általa kiszámított előtitkot használja ugyanazon szekciókulcs megszerzésére.
7. A kliens "Change Cipher Spec" üzenetet küld, hogy értesítse a másik felet, hogy titkosításra vált.
8. A kliens végső "Befejezve" üzenetet küld, jelezve, hogy a kézfogás egy részét befejezte.
9. Hasonlóképpen, a szerver „Change Cipher Spec” üzenetet küld.
10. A kézfogás a szervertől érkező „Kész” üzenettel ér véget.

A DHE előnyei az RSA-val szemben

Két fő oka van annak, hogy a kriptográfusok közössége a DHE-t részesíti előnyben az RSA-val szemben: a tökéletes továbbítási titok és az ismert sebezhetőségek.

Tökéletes előre titkolózás

Korábban talán azon töprengett, hogy mit jelent a DHE és az ECDHE végén található „tüntető” szó. A mulandó szó jelentése „rövid életű”. Ez pedig segíthet megérteni a Perfect Forward Secrecy (PFS) funkciót, amely egyes kulcscsere-protokollok jellemzője. A PFS biztosítja, hogy a felek között kicserélt munkamenetkulcsok ne kerülhessenek veszélybe, még akkor sem, ha a tanúsítvány privát kulcsa sérül. Más szóval, megvédi a korábbi munkameneteket a kibontástól és a visszafejtéstől. A PFS elsőbbséget élvezett a Heartbleed hiba felfedezése után. Ez a TLS 1.3 alapvető összetevője.

RSA kulcscsere biztonsági rése

Vannak olyan sérülékenységek, amelyek kihasználhatják a padding ( párnázás), az RSA régebbi verzióiban használt kulcscsere során (PKCS #1 1.5). Ez a titkosítás egyik aspektusa. Az RSA-val az előtitkot a nyilvános kulccsal kell titkosítani, és a titkos kulccsal vissza kell fejteni. De amikor ezt a kisebb, fő titkosítás előtti titkot egy nagyobb nyilvános kulcsban helyezik el, ki kell tölteni. A legtöbb esetben, ha megpróbálja kitalálni a tartalmat, és hamis kérést küld a szervernek, akkor téved, és a rendszer felismeri az eltérést és kiszűri azt. De jó esély van rá, hogy elegendő kérést tud majd küldeni a szervernek, hogy kitalálja a helyes kitöltést. Ekkor a szerver hibásan kitöltött üzenetet küld, ami viszont szűkíti a pre-master secret lehetséges értékét. Ez lehetővé teszi a támadó számára, hogy kiszámítsa és kompromittálja a kulcsot.

Ez az oka annak, hogy az RSA-t eltávolították a DHE javára a TLS 1.3-ban.

Kulcscsere a TLS 1.3 kézfogásban

A TLS 1.3-as kézfogásban a kulcscsere-sémák korlátozott választéka miatt az ügyfél sikeresen kitalálhatja a sémát, és elküldheti a megosztott kulcs rá eső részét a kézfogás kezdeti (Client Hello) fázisában.

Nem az RSA volt az egyetlen kulcscsere-séma, amelyet a TLS 1.3-ban eltávolítottak. A nem efemer Diffie-Hellman sémákat is megszüntették, csakúgy, mint a nem kellően biztonságos Diffie-Hellman paraméterek listáját.

Mit értesz nem kellően biztonságos beállítások alatt? Anélkül, hogy túl sok matematikába mennénk, a Diffie-Hellman és a legtöbb nyilvános kulcsú titkosítási rendszer összetettsége a diszkrét logaritmus-problémák megoldásának összetettsége. A kriptorendszernek elég összetettnek kell lennie ahhoz, hogy ki tudja számítani, ha a bemeneti paraméterek (kliens és szerver véletlenszámai) ismeretlenek, különben az egész séma használhatatlan lesz. A Diffie-Hellman sémákat, amelyek nem tudtak elég nagy paramétereket biztosítani, kiküszöbölték a TLS 1.3-ban.

1. A TLS 1.3-as kézfogás kezdetén, tudva, hogy a DHE-kulcs-megállapodási séma kerül alkalmazásra, az ügyfél belefoglalja a megosztott kulcs rá eső részét a tervezett kulcscsere-séma alapján a "Client Hello" üzenetbe.
2. A szerver megkapja ezeket az információkat, és ha a kliens helyes, visszaküldi a nyilvános kulcs részét a "Server Hello" üzenetben.
3. Az ügyfél és a szerver kiszámítja a munkamenet kulcsát.

Ez nagyon hasonló ahhoz, ami a DH-val történik a TLS 1.2-es kézfogás során, azzal a különbséggel, hogy a TLS 1.3-ban a kulcscsere korábban történik.

Konklúzió helyett

Az SSL/TLS kézfogás egy lenyűgöző folyamat, amely kulcsfontosságú a biztonságos internethez, mégis olyan gyorsan és zökkenőmentesen történik, hogy a legtöbb ember nem is gondol rá.

Legalábbis addig, amíg valami nem stimmel.

Az SSL és a TLS hálózati protokollok olyan kriptográfiai protokollok, amelyek hitelesítést és védelmet nyújtanak a jogosulatlan hozzáférés és a továbbított adatok integritásának megsértése ellen. Az SSL/TLS protokollok célja, hogy megakadályozzák az azonosítók hamisítását a kliens vagy a szerver oldalán, valamint az adatok nyilvánosságra hozatalát vagy megsérülését. Erre a célra megbízható hitelesítési módszert, kommunikációs csatorna titkosítást és üzenetintegritási kódokat használnak. Az SSL/TLS szabvány alapértelmezett portja 443 HTTPS, 465 SMTPS (e-mail), 636 LDAPS, 563 NNTPS, 994 IRCS (csevegés), 995 POP3S esetén.

SSL protokoll

Az SSL protokollt a Netscape fejlesztette ki a szolgáltatási és szállítási protokollok közötti adatok védelmére. Az első nyilvános verzió 1995-ben jelent meg. Széles körben használják VoIP alkalmazásokhoz, azonnali üzenetküldő szolgáltatásokhoz. Az SSL egy biztonságos csatorna, amely a következő tulajdonságokkal rendelkezik:

• Privát csatorna. Biztosítja, hogy a titkosítási kulcs meghatározásához szükséges párbeszédpanel után minden üzenet titkosítva legyen.
• A csatorna hitelesítve van. A hitelesítés nem kötelező a kliens oldalon, de kötelező a szerver oldalon.
• Csatorna megbízhatóság. Az üzenetek továbbításakor az integritás ellenőrzése a MAC segítségével történik.

Az SSL protokoll szimmetrikus és aszimmetrikus kulcsokat is használ.

Az SSL protokoll jellemzői és célja

Az SSL protokoll két problémára nyújt megoldást - a továbbított információk titkosítására és az információk pontosan oda történő továbbítására, ahol szükséges (hitelesítés). A protokoll fő célja, hogy megbízható módot biztosítson az alkalmazások közötti adatcserére. Az SSL megvalósítása többrétegű környezet formájában valósul meg, amelyet az információ biztonságos továbbítására használnak nem biztonságos kommunikációs csatornákon keresztül.

A többrétegű struktúrát egy kapcsolatmegerősítő protokollréteg és egy rögzítési protokollréteg képviseli. Az első réteg egy szállítási protokoll, például a TCP - az SSL Record Protocollal együtt ezek a rétegek alkotják az SSL magját, amely ezt követően komplex infrastruktúrák kialakításában vesz részt.

Az SSL protokoll főbb jellemzői között meg kell jegyezni a szoftver-platform függetlenséget. Jelenleg az SSL protokoll nem nyújt megfelelő biztonságot – felváltotta a TLS protokoll.

TLS protokoll

A TLS protokoll egy titkosítási protokoll, amelyet az internet különböző csomópontjai közötti biztonságos adatátvitelre használnak. Ezt a protokollt VoIP-alkalmazások, webböngészők és azonnali üzenetküldő alkalmazások használják. A TLS az SSL 3.0 specifikáción alapul. A protokollt az IETF fejleszti és fejleszti.

A TLS protokoll által biztosított főbb biztonsági intézkedések a következők:

• Kulcs használata az üzenet hitelesítési kódjának ellenőrzésére.
• A TLS-verzió visszaminősítésének vagy kevésbé biztonságos hálózati protokollra való lecserélésének lehetősége megszűnik.
• A kézfogás üzenet a felek között váltott összes üzenet kivonatát tartalmazza.
• Alkalmazás rekordszámozás használata MAC segítségével.
• Egy pszeudo-véletlen függvény használata, amely a bemeneti üzeneteket 2 részre osztja, amelyek mindegyikét más-más hash-függvény dolgozza fel.

A TLS protokoll jellemzői és célja

A TLS protokoll a következő algoritmusokat használja:

• RC4, Triple DES, SEED, IDEA stb. a szimmetrikus titkosításhoz.
• RSA, DSA, Diffie-Hellman és ECDSA a kulcshitelesítéshez.
• MD5, SHA és SHA-256/384 a hash funkciókhoz.

Az alkalmazások adatokat tároló rekordokat cserélnek. A rekordok tömöríthetők, kiegészíthetők, titkosíthatók vagy azonosíthatók. Ebben az esetben minden bejegyzés jelzi a csomag hosszát és a használt TLS verziót.

Általában véve a kriptográfia használata az SSL/TLS protokollokban jelentősen csökkenti az alkalmazások teljesítményét, de megbízható adatátviteli biztonságot nyújt. A protokollok gyakorlatilag semmilyen beállítást nem igényelnek a kliens oldalon, és a leggyakoribb biztonsági protokollok az interneten.

Minden érvünk azon alapul, hogy az operációs rendszer Windows XP vagy újabb (Vista, 7 vagy 8), amelyre az összes megfelelő frissítés és javítás telepítve van. Most van még egy feltétel: a böngészők legújabb verzióiról beszélünk, nem pedig „gömb alakú Ognelisokról a légüres térben”.

Tehát a böngészőket úgy konfiguráljuk, hogy a TLS protokoll legújabb verzióit használják, és egyáltalán ne használják az elavult verziókat és az SSL-t. Legalábbis amennyire ez elméletben lehetséges.

Az elmélet pedig azt mondja, hogy bár az Internet Explorer már a 8-as verziótól kezdve támogatja a TLS 1.1-et és 1.2-t, Windows XP és Vista alatt nem kényszerítjük erre. Kattintson: Eszközök/Internetbeállítások/Speciális, és a „Biztonság” részben ezt találjuk: SSL 2.0, SSL 3.0, TLS 1.0... talált még valamit? Gratulálunk, TLS 1.1/1.2 lesz! Ha nem találják, akkor Windows XP vagy Vista van, és Redmondban retardáltnak tartják.

Tehát törölje az összes SSL négyzet bejelölését, jelölje be az összes elérhető TLS négyzetet. Ha csak a TLS 1.0 érhető el, akkor legyen az; ha több aktuális verzió is elérhető, jobb, ha csak azokat jelöli ki, és törölje a TLS 1.0 jelölését (és ne lepődjön meg később, hogy egyes oldalak nem nyitnak meg HTTPS-en keresztül). Ezután kattintson az „Alkalmaz” és az „OK” gombra.

Az Operával egyszerűbb – igazi bankettet kínál különböző protokollverziókból: Eszközök/Általános beállítások/Speciális/Biztonság/Biztonsági protokoll. Mit látunk? A teljes készlet, amelyből csak a TLS 1.1 és TLS 1.2 esetén hagyjuk meg a jelölőnégyzeteket, ezután kattintsunk a „Részletek” gombra, és ott töröljük az összes sort, kivéve azokat, amelyek „256 bites AES”-sel kezdődnek – ezek a ponton vannak. vége. A lista elején van egy sor „256 bit AES ( Névtelen DH/SHA-256), törölje a pipát is. Kattintson az „OK” gombra, és örüljön a biztonságnak.

Az Operának azonban van egy furcsa tulajdonsága: ha a TLS 1.0 engedélyezve van, akkor ha biztonságos kapcsolat létesítésére van szükség, akkor azonnal ezt a protokollverziót használja, függetlenül attól, hogy az oldal támogatja-e az újabbakat. Például, minek zavarni – minden rendben van, minden védett. Ha csak a TLS 1.1 és 1.2 engedélyezve van, először a fejlettebb verziót próbálják ki, és csak akkor vált a böngésző az 1.1-es verzióra, ha azt a webhely nem támogatja.

De a gömbölyű Ognelis Firefox egyáltalán nem fog kedvünkre járni: Eszközök/Beállítások/Speciális/Titkosítás: nem tehetünk mást, mint letiltani az SSL-t, a TLS csak 1.0-s verzióban érhető el, nincs mit tenni - pipával hagyjuk.

A legrosszabbat azonban az összehasonlításból tanuljuk meg: a Chrome és a Safari egyáltalán nem tartalmaz beállításokat, hogy melyik titkosítási protokollt használja. Amennyire tudjuk, a Safari nem támogatja az 1.0-nál frissebb TLS-verziókat a Windows operációs rendszerhez készült verziókban, és mivel az ehhez az operációs rendszerhez tartozó új verziók kiadása megszűnt, nem is fog.

A Chrome tudomásunk szerint támogatja a TLS 1.1-et, de a Safarihoz hasonlóan nem tagadhatjuk meg az SSL használatát. Nincs mód a TLS 1.0 letiltására a Chrome-ban. De a TLS 1.1 tényleges használatával kapcsolatban van egy nagy kérdés: először bekapcsolták, majd működési problémák miatt kikapcsolták, és amennyire meg lehet ítélni, még nem kapcsolták vissza. Vagyis úgy tűnik, hogy van támogatás, de úgy tűnik, hogy ki van kapcsolva, és a felhasználónak nincs módja visszakapcsolni. Ugyanez a történet a Firefox esetében is – valójában támogatja a TLS 1.1-et, de még nem érhető el a felhasználó számára.

Összegzés a fenti multilevélből. Melyek a titkosítási protokollok elavult verzióinak használatának általános veszélyei? Az a tény, hogy valaki más bekerül az Ön biztonságos kapcsolatába az oldallal, és hozzáfér minden „ott” és „ott” információhoz. Gyakorlatilag teljes hozzáférést kap az e-mail fiókjához, az ügyfél-banki rendszerben lévő számlájához stb.

Nem valószínű, hogy véletlenül feltörne valaki más biztonságos kapcsolatára, csak rosszindulatú cselekedetekről beszélünk. Ha az ilyen műveletek valószínűsége alacsony, vagy a biztonságos kapcsolaton keresztül továbbított információ nem különösebben értékes, akkor nem kell vesződnie és olyan böngészőket használnia, amelyek csak a TLS 1.0-t támogatják.

Egyébként nincs más választás: csak az Opera és csak a TLS 1.2 (a TLS 1.1 csak a TLS 1.0 továbbfejlesztése, részben örökli a biztonsági problémáit). Előfordulhat azonban, hogy kedvenc webhelyeink nem támogatják a TLS 1.2-t :(

Az SSL TLS protokoll védi az internetkapcsolatokat HTTP-n (internetes oldalakhoz), FTP-n (fájlkezelő), IMAP-on, POP3-on és SMTP-n (levélprotokollok) keresztül.

2014-ben egy sérülékenységet fedeztek fel az SSL-ben, amely kezdett elavulni, így a TLS szabvány az SSL 3.0 alapján készült el.

TLS(angolul: Transport Layer Security) egy titkosítási protokoll, amely biztonságos adatátvitelt biztosít a szerverről a kliensre. A TLS a bizalmasság érdekében szimmetrikus titkosításon, a hitelesítéshez aszimmetrikus titkosításon, valamint a továbbított információk integritásának megőrzése érdekében hitelesítési kódokon alapul. Figyelembe veszi elődje hibáit, és folytatja a fejlesztést.

Lényegében az SSL és a TLS működési elvei közötti különbségek minimálisak, így amikor SSL-ről beszélnek, akkor TLS-re gondolnak.

Hogyan működik a TLS

A TLS folyamat több szakaszra osztható:

• TLS kézfogás
• TLS False Start
• TLS bizalmi lánc

TLS kézfogás— egyezteti a kapcsolati paramétereket a kliens és a szerver között (titkosítási mód, protokollverzió), és ellenőrzi a tanúsítványokat is. Ez az eljárás nagy mennyiségű számítási erőforrást használ fel, ezért annak érdekében, hogy ne jöjjön létre minden alkalommal új kapcsolat, és ne kelljen újra ellenőrizni a tanúsítványokat, a TLS False Start eljárást fejlesztették ki.

TLS False Start— az ülés folytatásának eljárása. Ha korábban munkamenet nyílt meg az ügyfél és a kiszolgáló között, ez a lépés lehetővé teszi a kézfogási eljárás kihagyását a korábban konfigurált adatok felhasználásával. Biztonsági okokból azonban minden munkamenetnek megvan a maga élettartama, és ha lejár, a TLS Handshake eljárással újra megnyílik.

TLS bizalmi lánc— kötelező TLS csatlakozási eljárás. Hitelesítést biztosít a kliens és a szerver között. A „bizalmi láncra” épül, amely a hitelesítésszolgáltatók által kiadott hitelességi tanúsítványokon alapul. A tanúsító hatóság ellenőrzi a tanúsítvány valódiságát, és ha az megsérül, az adatokat visszavonja. Ennek az eljárásnak köszönhetően a továbbított adatok hitelessége ellenőrzésre kerül.

Így az adatok továbbításakor először a TLS Handshake vagy TLS False Start eljárás hívódik meg, amely egyezteti a paramétereket, majd a TLS Chain of trust, amely hitelesítést biztosít (a továbbított információ szerzőségének ellenőrzése).

A TLS működéséről a hivatalos Datatracker dokumentációban tudhat meg többet.

TLS biztonsági beállítások

• A TLS-verziót nem lehet visszaminősíteni egy korábbi (kevésbé biztonságos) verzióra, és nem váltható át nem biztonságos titkosítási algoritmusra.
• Az egymást követő alkalmazásrekordok meg vannak számozva, és a sorszám kerül felhasználásra az üzenet-hitelesítési kódban.
• Csak a kulcs tulajdonosa állíthatja elő az üzenet-hitelesítési kódot.
• A kézfogást befejező üzenet a korábban elküldött üzenetek hitelességének megerősítésére szolgál.

SSL/TLS telepítése

A cég honlapján kiválaszthatja és megvásárolhatja azt, amelyik TLS 1.2-vel működik:

A tanúsítvány kiadása után telepítse saját maga az egyik utasítás szerint.

Ha olyan problémába ütközik, hogy egy adott webhelyhez nem lehet hozzáférni, és egy üzenet jelenik meg a böngészőben, ennek ésszerű magyarázata van. A probléma okait és megoldásait ebben a cikkben ismertetjük.

SSL TLS protokoll

A költségvetési szervezetek – és nem csak a költségvetési szervezetek – felhasználói, amelyek tevékenysége közvetlenül kapcsolódik a pénzügyekhez, a pénzügyi szervezetekkel, például a Pénzügyminisztériummal, a Pénzügyminisztériummal stb. együttműködve minden műveletüket kizárólag a biztonságos SSL protokoll használatával végzik. Munkájuk során alapvetően az Internet Explorer böngészőt használják. Bizonyos esetekben - Mozilla Firefox.

SSL hiba

E műveletek és általában a munkavégzés során a fő figyelmet a biztonsági rendszerre fordítják: tanúsítványokra, elektronikus aláírásokra. A működéshez a CryptoPro szoftver aktuális verziója kerül felhasználásra. Vonatkozó problémák az SSL és TLS protokollokkal, Ha SSL hiba megjelent, valószínűleg nincs támogatás ehhez a protokollhoz.

TLS hiba

TLS hiba sok esetben a protokolltámogatás hiányát is jelezheti. De... lássuk, mit lehet tenni ebben az esetben.

SSL és TLS protokoll támogatás

Tehát, amikor a Microsoft Internet Explorer használatával keres fel egy SSL-védett webhelyet, megjelenik a címsor Győződjön meg arról, hogy az ssl és tls protokollok engedélyezve vannak. Először is engedélyeznie kell a TLS 1.0 protokoll támogatását az Internet Explorerben.

Ha olyan webhelyet keres fel, amelyen az Internet Information Services 4.0 vagy újabb verziója fut, az Internet Explorer konfigurálása a TLS 1.0 támogatására segíti a kapcsolat biztonságát. Természetesen, feltéve, hogy a távoli webszerver, amelyet használni próbál, támogatja ezt a protokollt.

Ehhez a menüben Szolgáltatás Válassz csapatot internetes lehetőségek.

A lapon Továbbá fejezetben Biztonság, győződjön meg arról, hogy a következő jelölőnégyzetek be vannak jelölve:

• SSL 2.0 használata
• SSL 3.0 használata
• SSL 1.0 használata

Kattintson a gombra Alkalmaz , és akkor rendben . Indítsa újra a böngészőt .

A TLS 1.0 engedélyezése után próbálja meg újra felkeresni a webhelyet.

Rendszerbiztonsági szabályzat

Ha mégis előfordulnak SSL és TLS hibák Ha továbbra sem tudja használni az SSL-t, akkor a távoli webszerver valószínűleg nem támogatja a TLS 1.0-t. Ebben az esetben le kell tiltania a FIPS-kompatibilis algoritmusokat igénylő rendszerházirendet.

Ehhez be Vezérlőpultok válassza ki Adminisztráció, majd kattintson duplán Helyi biztonsági szabályzat.

A Helyi biztonsági beállítások részben bontsa ki Helyi politikák majd kattintson a gombra Biztonsági beállítások.

Az ablak jobb oldalán található házirendnek megfelelően kattintson duplán Rendszerkriptográfia: használjon FIPS-kompatibilis algoritmusokat a titkosításhoz, a kivonatoláshoz és az aláíráshoz majd kattintson a gombra Tiltva.

Figyelem!

A változás a helyi biztonsági házirend újbóli alkalmazásakor lép életbe. Kapcsolja be, és indítsa újra a böngészőt.

CryptoPro TLS SSL

Frissítse a CryptoPro-t

A probléma megoldásának egyik lehetősége a CryptoPro frissítése, valamint az erőforrás konfigurálása. Ebben az esetben ez elektronikus fizetéssel működik. Lépjen a Hitelesítés-szolgáltató oldalra. Válassza az Elektronikus piactereket forrásként.

Az automatikus munkahely-beállítás elindítása után már csak az marad várja meg az eljárás befejezését, akkor töltse újra a böngészőt. Ha meg kell adnia vagy ki kell választania egy erőforráscímet, válassza ki a kívántat. Előfordulhat, hogy a telepítés befejeztével újra kell indítania a számítógépet.