Az SSL ( Eng. Secure Sockets Layer – a biztonságos socket szintje ) egy titkosítási protokoll , amely biztonságosabb kapcsolatot feltételez. Aszimmetrikus kriptográfiát használ a cserekulcsok hitelesítésére, szimmetrikus titkosítást a bizalmasság megőrzésére, üzenet-hitelesítési kódokat az üzenetek integritására. A protokollt széles körben használták azonnali üzenetküldésre és IP-alapú hangátvitelre ( Voice over IP – VoIP ) olyan alkalmazásokban, mint az e- mail , internetes fax stb. 2014-ben az Egyesült Államok kormánya a protokoll jelenlegi verziójának sebezhetőségéről számolt be [1] . Az SSL-t el kell hagyni a TLS helyett (lásd: CVE-2014-3566).
Az SSL-t eredetileg a Netscape Communications fejlesztette ki, hogy hozzáadja a HTTPS protokollt Netscape Navigator webböngészőjéhez . Ezt követően az SSL 3.0 protokoll alapján kidolgozták és elfogadták az RFC szabványt , amely a TLS nevet kapta .
Az SSL protokoll biztonságos kommunikációt biztosít a következő két elemen keresztül:
Az SSL aszimmetrikus kriptográfiát használ a cserekulcsok hitelesítésére, szimmetrikus titkosítót a bizalmasság megőrzésére, valamint üzenethitelesítési kódokat az üzenetek integritásának biztosítására.
Az SSL protokoll egy "biztonságos csatornát" biztosít, amelynek három fő tulajdonsága van:
Az SSL előnye, hogy független az alkalmazási protokolltól. Az alkalmazásprotokollok ( HTTP , FTP , TELNET , stb.) teljesen transzparens módon működhetnek az SSL protokollon felül, vagyis az SSL képes egyeztetni a titkosítási algoritmust és a session kulcsot, és hitelesíteni a szervert, mielőtt az alkalmazás megkapja vagy továbbítja a az üzenet első bájtja.
Az SSL protokollt eredetileg a Netscape Communications fejlesztette ki . Az 1.0-s verzió soha nem került nyilvánosságra. A 2.0-s verzió 1995 februárjában jelent meg, de sok olyan biztonsági hibát tartalmazott, amelyek az SSL 3.0-s verziójának kifejlesztéséhez vezettek [2] . Az 1996-ban kiadott SSL 3.0-s verzió volt az alapja a TLS 1.0, az Internet Engineering Task Force ( IETF ) protokollszabvány létrehozásának, amelyet először az RFC 2246-ban határoztak meg 1999 januárjában. A Visa , a Master Card , az American Express és sok más szervezet rendelkezik engedéllyel az SSL protokoll kereskedelmi célú internetes használatára. Így az SSL a projektnek megfelelően bővíthető, hogy támogassa az előre és visszafelé kompatibilitást és a kapcsolatok közötti egyeztetést egy peer-to-peer hálózatban. 2011 márciusától az RFC 6176 szerint a TLS kliensek nem használhatják az SSL 2.0 protokollt, amikor kapcsolatot kérnek a szerverrel, és a szervereknek el kell utasítaniuk az ilyen kéréseket.
A TLS 1.0-t először az RFC 2246 -ban határozták meg 1999 januárjában az SSL 3.0 frissítéseként. Amint az RFC kijelenti, "a protokoll és az SSL 3.0 közötti különbségek nem kritikusak, de jelentősek a TLS 1.0 és az SSL 3.0 közötti inkompatibilitások megjelenése szempontjából." A TLS 1.0 tartalmaz olyan eszközöket, amelyekkel a TLS–SSL 3.0 kapcsolat megvalósítása gyengítené a biztonságot.
A TLS 1.1-et 2006 áprilisában vezették be az RFC 4346 -ban [3] . Ez a TLS 1.0-s verziójának frissítése volt. Jelentős változások ebben a verzióban:
A TLS 1.2-t 2008 augusztusában jelentették be az RFC 5246 -ban. A TLS 1.1 korábban javasolt verzióján alapul.
A TLS 1.3 szabványt 2018 augusztusában ismerték el az RFC 8446 szabványban.
Az SSL többrétegű környezetet használ az információcsere biztonságának biztosítására. A kommunikáció bizalmas jellege annak köszönhető, hogy a biztonságos kapcsolat csak a megcélzott felhasználók számára nyitott.
Az SSL protokoll két protokoll között helyezkedik el: a kliensprogram által használt protokoll (HTTP, FTP, LDAP, TELNET stb.) és a TCP/IP szállítási protokoll között. Az SSL úgy védi az adatokat, hogy szűrőként működik mindkét oldalon, és továbbítja azokat a szállítási rétegnek [4] [5] .
A protokoll működése két szintre osztható:
Az első réteg viszont három alprotokollból áll:
A kapcsolati kézfogási protokoll a munkamenetadatok egyeztetésére szolgál az ügyfél és a szerver között. A munkamenet adatai a következőket tartalmazzák:
A kapcsolati handshake protokoll egy adatcsere-láncot hoz létre, amely megkezdi a felek hitelesítését, és megegyezik a titkosításban, a kivonatolásban és a tömörítésben. A következő lépés a résztvevők hitelesítése, amelyet szintén a kapcsolatmegerősítő protokoll hajt végre.
A titkosítási paraméter-módosítási protokoll a kulcsadatok (kulcsanyag) megváltoztatására szolgál – ez a titkosítási kulcsok létrehozásához használt információ. A protokoll csak egy üzenetből áll, amelyben a szerver azt mondja, hogy a küldő módosítani akarja a kulcskészletet.
A figyelmeztető protokoll egy üzenetet tartalmaz, amely állapotváltozást vagy esetleges hibát jelez a feleknek. Jellemzően figyelmeztetést küldünk, ha a kapcsolat megszakad, és érvénytelen üzenet érkezik, az üzenet nem dekódolható, vagy a felhasználó megszakítja a műveletet.
Az SSL protokoll tanúsítványokat használ annak ellenőrzésére, hogy a nyilvános kulcs a valódi tulajdonosához tartozik-e. Az SSL-tanúsítvány beszerzésének módjai:
Önaláírt tanúsítvány - a felhasználó által létrehozott tanúsítvány - ebben az esetben a tanúsítvány kibocsátója megegyezik a tanúsítvány tulajdonosával. Az „üres” tanúsítvány egy olyan fiktív információt tartalmazó tanúsítvány, amelyet ideiglenes jelleggel használnak az SSL beállításához és működésének ellenőrzéséhez egy adott környezetben.
Az SSL - tanúsítványok között vannak tartományellenőrzött tanúsítványok és kiterjesztett érvényesítési tanúsítványok . Ez utóbbi egy domain nevet egy valós személyhez vagy entitáshoz társít.
4 fő kulcsgeneráló algoritmus létezik: RSA , Fixed Diffie-Hellman, Efemer Diffie-Hellman, Anonymous Diffie-Hellman
rsaHa egy privát RSA-kulcs „elveszett”, az azt megkapó kriptoanalitikus lehetőséget kap az összes rögzített múltbeli és jövőbeli üzenet visszafejtésére. A kulcscsere megvalósítása az RSA-ban egyirányú: a kézfogási szakaszban létrejövő szimmetrikus kulcs létrehozásához szükséges összes információ elküldésre kerül a szervernek és a szerver nyilvános kulcsával titkosítva. A privát kulcs felfedése lehetővé teszi ennek a munkamenetnek a szimmetrikus kulcsának kiderítését.
Diffie-HellmanA Fixed Diffie-Hellman mechanizmus állandó nyilvános kulcsot használ, amely a szervertanúsítványban van regisztrálva. Ez azt is jelenti, hogy minden új kapcsolatnál az ügyfél megadja a kulcs részét. A kulcscsere után egy új szimmetrikus kulcs jön létre az aktuális munkamenet információcseréjéhez. A szerver privát kulcsának felfedésével a kriptoanalizátor visszafejtheti a korábban rögzített üzeneteket, valamint az összes jövőbeli üzenetet. Ezt maga a mechanizmus teszi lehetővé. Mivel a kriptoanalitikus ismeri a szerver privát kulcsát, képes lesz kideríteni az egyes munkamenetek szimmetrikus kulcsát, és még az sem segít, hogy a kulcsgenerálási mechanizmus kétirányú.
Az Anonymous Diffie-Hellman mechanizmus nem garantálja a magánélet védelmét, mivel az adatokat titkosítatlanul továbbítják.
Az egyetlen lehetőség, amely garantálja a múltbeli és jövőbeli üzenetek biztonságát, az Efemer Diffie-Hellman . Az előzőekben tárgyalt módszerekhez képest az a különbség, hogy minden új kapcsolatnál egyszeri kulcsot generál a szerver és a kliens. Így még ha a kriptoanalitikus megkapja is az aktuális privát kulcsot, csak az aktuális munkamenetet tudja visszafejteni, a korábbi vagy jövőbeli munkameneteket azonban nem.
Az adatok titkosításának két fő módja van: szimmetrikus titkosítás (megosztott titkos kulcs) és aszimmetrikus titkosítás (nyilvános/privát kulcspár).
Az SSL aszimmetrikus és szimmetrikus titkosítást is használ.
Az aszimmetrikus titkosítás lényege, hogy egy kulcspárt használnak. Az egyik kulcsot nyilvánosnak nevezik (általában magában a tulajdonos tanúsítványában teszik közzé), a második kulcsot pedig privátnak nevezik - titokban tartják. Mindkét kulcsot párban használjuk: a nyilvános kulcsot az adatok titkosítására, a privát kulcsot pedig a visszafejtésre használjuk. Ez a kapcsolat két fontos dolgot tesz lehetővé.
Az RSA az egyik legszélesebb körben használt aszimmetrikus titkosítási algoritmus.
A szimmetrikus titkosításnál ugyanazt a kulcsot használják az adatok titkosításához és visszafejtéséhez. Ha a felek titkosított üzeneteket szeretnének biztonságos módon cserélni, akkor mindkét félnek azonos szimmetrikus kulcsokkal kell rendelkeznie. Ezt a típusú titkosítást nagy mennyiségű adat esetén használják (mivel a szimmetrikus titkosítás gyorsabb). Az általánosan használt algoritmusok a DES , 3-DES , RC2 , RC4 és AES .
Az SSL protokoll nyilvános kulcsú titkosítást használ a kliens és a szerver kölcsönös hitelesítésére (digitális aláírás technológiával), valamint munkamenetkulcs generálására, amelyet viszont a gyorsabb szimmetrikus kriptográfiai algoritmusok használnak nagy mennyiségű adat titkosítására. .
A hash érték egy üzenetazonosító, mérete kisebb, mint az eredeti üzenet mérete. A leghíresebb hash algoritmusok az MD5 (Message Digest 5), amely 128 bites hash értéket állít elő, az SHA-1 (Secure Hash Algorithm), amely 160 bites hash értéket állít elő, az SHA-2 és az SHA-3 . A kivonatoló algoritmus eredménye egy olyan érték, amely az adatátvitel integritásának ellenőrzésére szolgál.
A rögzítési réteg szintű protokoll titkosított adatokat fogad a kliens programtól és továbbítja a szállítási rétegnek. A rögzítési protokoll felveszi az adatokat, blokkokra bontja, és titkosítja (dekódolja) az adatokat. Ugyanakkor aktívan felhasználják azokat az információkat, amelyekről az adatok visszaigazolása során megállapodtak.
Az SSL protokoll lehetővé teszi a szimmetrikus kulcsú titkosítást akár blokk- , akár adatfolyam-titkosítással . A gyakorlatban gyakran használják a blokk-rejtjeleket. A blokk-rejtjel működési elve az, hogy egy egyszerű szövegblokkot leképeznek ugyanabba a titkosított szöveg blokkra. Ez a rejtjel egy 2128 sort tartalmazó táblázatként ábrázolható , minden sor egy egyszerű szöveges M blokkot és a megfelelő C rejtjelezett szövegblokkot tartalmaz . Minden kulcshoz létezik hasonló táblázat.
A titkosítás ábrázolható függvényként
C = E ( Kulcs , M ), ahol M az eredeti adat, Kulcs a titkosítási kulcs, C a titkosított adat.
A blokkok általában kicsik (általában 16 bájt), így felmerül a kérdés: hogyan lehet titkosítani egy hosszú üzenetet?
Az ilyen titkosítás első módját ECB (Electronic Codebook) vagy egyszerű helyettesítési módnak nevezik. Lényege, hogy az eredeti üzenetet blokkokra bontjuk (ugyanarra a 16 bájtra), és mindegyik blokkot külön titkosítjuk. Ezt a módot azonban ritkán használják a forrásszöveg statisztikai jellemzőinek megőrzésének problémája miatt: a titkosítás után 2 azonos egyszerű szövegblokkból két azonos titkosított szövegblokk lesz.
A probléma megoldására egy második módot fejlesztettek ki - CBC (Cipher-block láncolás). Ebben az esetben minden új rejtjelezett szöveg blokk XOR-re kerül az előző titkosítási eredménnyel. Az első blokk XOR-re van írva valamilyen inicializálási vektorral (Initialization Vector, IV). Azonban a fenti elméletek mindegyike egyetlen nagy objektumra van kifejlesztve, míg az SSL-nek, mint kriptográfiai protokollnak, egy sor csomagot kell titkosítania. Ilyen helyzetben a CBC alkalmazásának két módja van:
Alkalmazások tervezésekor az SSL minden más alkalmazási rétegbeli protokoll, például a HTTP , FTP , SMTP , NNTP és XMPP "alatt" valósul meg , így "átláthatóvá" válik a használata. Korábban az SSL-t elsősorban megbízható szállítási protokollokkal, például a TCP-vel ( Transmission Control Protocol ) használták. Mindazonáltal olyan datagram-átviteli protokollokkal is implementálták, mint a User Datagram Protocol (UDP) és a Datagram Control Protocol (DCCP), amelyek használatát szabványosították, így született meg a Datagram Transport Layer Security (DTLS) kifejezés.
Az SSL protokoll gyakori használata a HTTPS (Hypertext Transfer Protocol Secure) protokoll kialakulásához vezetett, amely támogatja a titkosítást. A HTTPS protokollon keresztül továbbított adatok az SSL vagy TLS kriptográfiai protokollba „csomagolva” vannak , ezáltal biztosítva ezen adatok védelmét. Ezt a védelmi módszert széles körben használják a webes világban olyan alkalmazásoknál, ahol fontos a kapcsolat biztonsága, például fizetési rendszerekben. A HTTP - vel ellentétben a HTTPS alapértelmezés szerint a 443 -as TCP -portot használja.
| Protokoll verzió | Biztonság | Weboldal támogatás |
|---|---|---|
| SSL 2.0 | Nem | 4,9% |
| SSL 3.0 | Nem | 16,6% |
| TLS 1.0 | Lehet | 94,7% |
| TLS 1.1 | Igen | 82,6% |
| TLS 1.2 | 85,5% |
2017 elejétől az összes nagyobb SSL/TLS-t támogató webböngésző a következő:
| Böngésző | Platformok | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|---|
| Króm 1-21 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Igen | Nem | Nem | Nem |
| Króm 29-53 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8, 10) | igen [7] | igen [7] | igen [8] | Nem |
| Chrome 58+ | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8, 10) | Igen | Igen | Igen | Igen |
| Firefox 1-27 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | igen [9] | Nem [10] | Nem [11] | Nem |
| Firefox 27-53 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Igen | Igen | Igen | Nem |
| Firefox 54+ | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Igen | Igen | Igen | Igen |
| IE6 | Windows (XP) | Igen | Nem | Nem | Nem |
| IE 7-8 _ | Windows (XP, Vista) | Igen | Nem | Nem | Nem |
| IE 8-9 _ | Windows 7 | Igen | Igen | Igen | Nem |
| IE9 | Windows Vista | Igen | Nem | Nem | Nem |
| IE 10+ | Windows (7, 8) | Igen | Igen | Igen | Nem |
| Edge 12-15 | Windows 10 | Igen | Igen | Igen | Nem |
| Opera 5-7 | Linux, Mac OS X, Windows | igen [12] | Nem | Nem | Nem |
| Opera 8-9 | Linux, Mac OS X, Windows | Igen | igen [13] | Nem | Nem |
| Opera 10+ | Linux, Mac OS X, Windows | Igen | Igen | Igen | Nem |
| Opera 44+ | Linux, Mac OS X, Windows | Igen | Igen | Igen | Igen |
| Safari 4 | Mac OS X, Windows (XP, Vista, 7), iOS 4.0 | Igen | Nem | Nem | Nem |
| Safari 5 | Mac OS X, Windows (XP, Vista, 7) | Igen | Nem | Nem | Nem |
| Safari 7-10 | iOS 5.0- | Igen | Igen | Igen | Nem |
Műszaki adatok:
Kezdetben az SSL-alapú virtuális magánhálózatokat ( VPN ) az IPsec VPN - en alapuló kiegészítő és alternatív távoli hozzáférési technológiaként fejlesztették ki . Azonban olyan tényezők, mint a kellő megbízhatóság és az alacsony költség vonzóvá tették ezt a technológiát a VPN-szervezetek számára. Az SSL-t széles körben használják az e-mailekben is.
Az SSL leggyakoribb megvalósítása az OpenSSL nyílt forráskódú kriptográfiai csomag , amely az Eric Young által írt SSLeay -en alapul. Az OpenSSL legújabb verziója támogatja az SSLv3-at. A csomag különféle tanúsítványok létrehozására és kezelésére szolgál . Tartalmaz egy könyvtárat is az SSL-támogatáshoz különböző programok által. A könyvtárat például a közös Apache HTTP- kiszolgáló SSL-modulja használja .
Az SSL-ben lévő összes adatot rekordok (rekordok) formájában küldik el - olyan objektumok, amelyek egy fejlécből és bizonyos mennyiségű adatból állnak. Minden rekord fejléc 2 vagy 3 bájt hosszúságú kódot tartalmaz. Ha a rekordhossz kód első bájtjában a legjelentősebb bit 1, akkor a rekordnak nincs kitöltése, és a fejléc teljes hossza 2 bájt, ellenkező esetben a rekord tartalmaz kitöltést és a teljes fejléc hossza 3 bájt. Hosszú (3 bájt) fejléc esetén az első bájt második legjelentősebb bitje különleges jelentéssel bír. Ha egyenlő 0-val - a rekord információs, ha egyenlő 1-gyel - a rekord biztonsági menekülés. A rekordhossz kód nem tartalmazza a fejléc bájtok számát. Egy 2 bájtos fejléc hosszát a következőképpen számítjuk ki:
RECORDHOSSZ = ((byte[0] & 0x7F) << 8) | bájt[1];
Itt a bájt[0] az első vett bájt, az [1] pedig a második fogadott bájt.
3 bájtos fejléc esetén a rekord hossza a következőképpen kerül kiszámításra:
RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | bájt[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = bájt[2];
A PADDING érték adja meg a feladó által az eredeti rekordhoz hozzáadott bájtok számát. A kitöltési adatok arra szolgálnak, hogy a rekord hossza többszöröse legyen a titkosítási blokk méretének. A feladó a megadott adatok után hozzáadja a PADDING -et, majd az egészet titkosítja, mivel ennek a tömbnek a hossza többszöröse a használt titkosítás blokkméretének. Mivel a továbbított adatok mennyisége ismert, az üzenet fejléce a PADDING mennyiségének figyelembevételével alakítható ki . Az üzenet címzettje visszafejti a teljes adatmezőt, és megkapja az eredeti információt, majd kiszámítja a RECORD-LENGTH valódi értékét , miközben a PADDING eltávolításra kerül az "adat" mezőből.
Az SSL rekord adatrész 3 összetevőből áll:
MAC-DATA - üzenet hitelesítő kód
MAC-SIZE - a hash összeg kiszámításához használt algoritmus funkciója
ACTUAL-DATA - ténylegesen továbbított adat vagy üzenet adatmező
PADDING-DATA - PADDING adatok (blokk titkosítással)
MAC-ADATOK = HASH [ TITKOS , AKTUÁLIS ADATOK , PADDING-ADATOK , SORSZÁM ]
Itt először a SECRET kerül átadásra a hash függvénynek, ezt követi az ACTUAL-DATA és a PADDING-DATA , majd a SEQUENCE-NUMBER , egy sorszám.
A SECRET értéke attól függ, hogy ki küldi az üzenetet. Ha az ügyfél ezt teszi, akkor a SECRET egyenlő a CLIENT-WRITE-KEY értékkel . Ha az ügyfél megkapja az üzenetet, a SECRET egyenlő a CLIENT-READ-KEY értékkel .
A sorszám egy 32 bites kód, amely 4 bájtban kerül átadásra a hash függvénynek a magastól az alacsonyig terjedő hálózati sorrendben. A sorszám a szerver vagy kliens számlálója. Minden átviteli irányhoz egy pár számlálót használnak - a küldő és a címzett számára; minden üzenet elküldésekor a számláló 1-gyel növekszik.
Az üzenet fogadója a várt sorszám értéket használja a MAC elküldéséhez (a hash típusát a CIPHER-CHOICE paraméter határozza meg ). A számított MAC-DATA értéknek meg kell egyeznie a továbbított értékkel. Ha az összehasonlítás sikertelen, az üzenet sérültnek minősül, ami hibát eredményez, ami a kapcsolat megszakadásához vezet.
Az utolsó egyezés-ellenőrzés blokkrejtjel használata esetén történik. Az üzenetben lévő adatmennyiségnek ( RECORD-LENGTH ) a titkosítási blokk méretének többszörösének kell lennie. Ha ez a feltétel nem teljesül, az üzenet sérültnek minősül, ami megszakad.
2 bájtos fejléc esetén a maximális üzenethossz 32767 bájt, 3 bájtos fejléc esetén 16383 bájt. Az SSL-beszélgetési protokoll üzeneteinek egyetlen SSL-protokoll-rekordnak kell megfelelniük, az alkalmazásprotokoll-üzenetek pedig több SSL-rekordot is elfoglalhatnak.
Az SSL beszélgetési protokoll 2 fő fázist tartalmaz.
1. fázisAz első fázis egy bizalmas kommunikációs csatorna létrehozására szolgál.
Ez a fázis inicializálja a kapcsolatot, amikor mindkét partner "hello" üzenetet vált. A kliens CLIENT-HELLO üzenetet küld . A szerver megkapja ezt az üzenetet, feldolgozza, és visszaküldi a SERVER-HELLO üzenetet .
Ezen a ponton a kiszolgáló és az ügyfél is elegendő információval rendelkezik ahhoz, hogy tudja, szükség van-e új főkulcsra. Ha nincs szükség a kulcsra, a szerver és a kliens a 2. fázisba lép.
Amikor új főkulcsot kell létrehozni , a szerver SERVER-HELLO üzenete már elegendő adatot tartalmaz ahhoz, hogy az ügyfél mesterkulcsot generáljon . Ezek az adatok magukban foglalják a kiszolgáló aláírt tanúsítványát, az alaprejtjelek listáját és a kapcsolatazonosítót (a kiszolgáló által generált véletlen szám, amelyet a munkamenet során használnak). Miután az ügyfél generált egy mesterkulcsot , elküldi a kiszolgálónak egy CLIENT-MASTER-KEY üzenetet, vagy egy hibaüzenetet, ha az ügyfél és a szerver nem tudnak megegyezni az alaptitkosításban.
A mesterkulcs meghatározása után a szerver SERVER-VERIFY üzenetet küld a kliensnek , amely hitelesíti a szervert.
A 2. fázist hitelesítési fázisnak nevezzük. Mivel a szerver már az első fázisban hitelesítve van, a kliens hitelesítése a második fázisban történik meg. A szerver kérést küld a kliensnek, és ha a kliens rendelkezik a szükséges információkkal, pozitív választ, ha nem, hibaüzenetet küld. Amikor az egyik partner hitelesített egy másikat, az kész üzenetet küld . Ügyfél esetén a CLIENT-FINISHED üzenet a CONNECTION-ID titkosított formáját tartalmazza, amelyet a szervernek ellenőriznie kell. Ha az ellenőrzés sikertelen volt, a szerver ERROR üzenetet küld .
Amikor az egyik partner küldött egy kész üzenetet , addig el kell fogadnia az üzeneteket, amíg meg nem kapja a kész üzenetet a másik partnertől, és csak akkor fejeződik be az SSL beszélgetési protokoll , amikor mindkét partner elküldte és fogadta a kész üzenetet. Ettől a pillanattól kezdve az alkalmazási protokoll működésbe lép.
Az alábbiakban bemutatunk néhány lehetőséget az SSL beszélgetési protokollon belüli üzenetváltásra. A kliens C , a szerver S. A "{smth}key" azt jelenti, hogy a "smth" egy kulccsal van titkosítva.
Munkamenetazonosító hiányában| ügyfél-üdv | C®S: | kihívás, cipher_specs |
| szerver-üdv | S® C: | kapcsolatazonosító,szerver-tanúsítvány,titkosítási_specifikációk |
| kliens-főkulcs | C®S: | {master_key}server_public_key |
| ügyfél-befejezés | C®S: | {connection-id}client_write_key |
| szerver-ellenőrzés | S® C: | {challenge}szerver_írási_kulcs |
| szerver-befejezés | S® C: | {new_session_id}server_write_key |
| ügyfél-üdv | C®S: | kihívás, session_id, cipher_specs |
| szerver-üdv | S® C: | kapcsolatazonosító, session_id_hit |
| ügyfél-befejezés | C®S: | {connection-id}client_write_key |
| szerver-ellenőrzés | S® C: | {challenge}szerver_írási_kulcs |
| szerver-befejezés | S® C: | {session_id}server_write_key |
| ügyfél-üdv | C®S: | kihívás, session_id, cipher_specs |
| szerver-üdv | S® C: | kapcsolatazonosító, session_id_hit |
| ügyfél-befejezés | C®S: | {connection-id}client_write_key |
| szerver-ellenőrzés | S® C: | {challenge}szerver_írási_kulcs |
| Kérelem-tanúsítvány | S® C: | {auth_type ,challenge'}server_write_key |
| ügyfél-tanúsítvány | C®S: | {cert_type,client_cert,response_data}client_write_key |
| szerver-befejezés | S® C: | {new_session_id}server_write_key |
Az SSL 3 típusú hitelesítést támogat:
Ha a kiszolgáló hitelesített, akkor annak hitelesítési üzenetében meg kell adni a megfelelő hitelesítési láncot, amely egy elfogadható CA-hoz vezet. Egyszerűen fogalmazva, a hitelesített szervernek érvényes tanúsítványt kell adnia az ügyfélnek. Mindegyik fél felelős annak ellenőrzéséért, hogy a másik fél tanúsítványa még nem járt-e le vagy nem vonták vissza. Amikor a szerver hitelesít, a csatorna ellenáll (biztonságos) a webszerver és a böngésző közötti adatelfogási kísérletnek, de a teljesen névtelen munkamenet eredendően sebezhető az ilyen támadásokkal szemben. Az anonim szerver nem tudja hitelesíteni a klienst. A kulcscsere folyamatának fő célja egy kliens titkos (pre_master_secret) létrehozása, amelyet csak a kliens és a szerver ismer. A titok (pre_master_secret) a megosztott titok (master_secret) létrehozására szolgál. A megosztott titokra azért van szükség, hogy üzenetet hozzon létre a tanúsítvány, a titkosítási kulcsok, a MAC (üzenet hitelesítési kód) titkának és a kész üzenet ellenőrzéséhez. A kész üzenet elküldésével a felek jelzik, hogy ismerik a helyes titkot (pre_master_secret).
Teljesen anonim munkamenet hozható létre az RSA vagy Diffie-Hellman algoritmus használatával a cserekulcsok generálására. RSA használata esetén a kliens a titkot (pre_master_secret) titkosítja a nem hitelesített szerver nyilvános kulcsával. Az ügyfél megtanulja a nyilvános kulcsot a szerver kulcscsere üzenetéből. Az eredményt kulcscsere üzenetben küldi el az ügyfél. Mivel az elfogó nem ismeri a szerver privát kulcsát, nem tudja visszafejteni a titkot (pre_master_secret). A Diffie-Hellman algoritmus használatakor a szerver nyilvános paramétereit a kiszolgáló kulcscsere-üzenete tartalmazza, és kulcscsere üzenetben küldi el a kliensnek. Az elfogó, amely nem ismeri a privát értékeket, nem fogja tudni megtalálni a titkot (pre_master_secret).
Ebben az esetben a kulcscsere és a szerver hitelesítés kombinálható. A nyilvános kulcsot a szerver tanúsítványa is tartalmazhatja, vagy ideiglenes RSA -kulcs is használható , amelyet a kiszolgáló kulcscsere üzenetében küld el. Ideiglenes RSA-kulcs használatakor a csereüzeneteket a kiszolgáló RSA- vagy DSS-tanúsítványa írja alá (???). Az aláírás tartalmazza a Client_Hello.random üzenet aktuális értékét, így a régi aláírások és a régi ideiglenes kulcsok nem ismételhetők meg. A szerver az ideiglenes RSA-kulcsot csak egyszer használhatja munkamenet létrehozásához. A kiszolgáló tanúsítványának ellenőrzése után az ügyfél titkosítja a titkot (pre_master_secret) a kiszolgáló nyilvános kulcsával. A titkos (pre_master_secret) sikeres dekódolása után egy "befejezett" üzenet generálódik, ezzel demonstrálva a szerver felé, hogy ismeri a szerver tanúsítványának megfelelő privát kulcsot.
Ha az RSA-t kulcscserére használják, az ügyféltanúsítvány-ellenőrző üzenetet használják az ügyfél hitelesítésére. A kliens aláírja a master_secret és az összes megelőző handshake protokoll üzenetből számított értéket. Ezek a kézfogási üzenetek egy szervertanúsítványt tartalmaznak, amely megegyezik a kiszolgáló aláírásával egy Server_Hello.random üzenettel, amely megegyezik az aktuális kézfogási üzenet aláírásával (???).
Ebben az esetben a szerver támogathat egy paraméter-specifikus Diffie-Hellman algoritmust is, vagy használhatja a kiszolgáló kulcscsere-üzeneteit DSS- vagy RSA-tanúsítvánnyal aláírt ideiglenes paraméterek küldésére. Az ideiglenes paraméterek kivonatolása hello.random üzenettel történik aláírás előtt, hogy a támadó ne ismételje meg a régi paramétereket. Az ügyfél mindkét esetben ellenőrizheti a tanúsítványt vagy az aláírást, hogy megbizonyosodjon arról, hogy a paraméterek a szerverhez tartoznak.
Ha az ügyfél rendelkezik olyan tanúsítvánnyal, amely tartalmazza a Diffie-Hellman algoritmus paramétereit , akkor a tanúsítvány tartalmazza a kulcscsere befejezéséhez szükséges információkat is. Ebben az esetben a kliensnek és a szervernek ugyanazokat a Diffie-Hellman eredményeket (pre_master_secret) kell generálnia minden alkalommal, amikor kapcsolatot létesítenek. Annak elkerülése érdekében, hogy a titkot (pre_master_secret) a szükségesnél hosszabb ideig tárolja a számítógép memóriájában, a titkot a lehető leggyorsabban át kell alakítani megosztott titokká (master_secret). A kulcscsere működéséhez az ügyfélbeállításoknak kompatibilisnek kell lenniük a szerver által támogatottakkal.
A Record Layer protokoll egy réteges protokoll. Az üzenetek minden szinten tartalmaznak hossz-, leírás- és érvényességi mezőket. Az írási protokoll fogadja a továbbítandó üzeneteket, feldarabolja az adatokat kezelhető blokkokra, intelligensen tömöríti az adatokat egy MAC (üzenet hitelesítési kód) segítségével, titkosítja és továbbítja az eredményt. Visszafejti a kapott adatokat, ellenőrzi, kicsomagolja, összegyűjti és a kliens magasabb szintjeire szállítja.
Négy rögzítési protokoll létezik:
Ha egy SSL-megvalósítás olyan bejegyzéstípust kap, amelyet nem ismer, akkor azt a bejegyzést a rendszer egyszerűen figyelmen kívül hagyja. Minden, az SSL-lel együtt használható protokollt alaposan át kell gondolni, mivel meg kell küzdenie az ellene irányuló támadásokkal. Vegye figyelembe, hogy a rekord típusa és hossza miatt a protokollt nem védi titkosítás. Ügyelni kell a forgalom minimalizálására.
Az SSL-kliens és a szerver megállapodnak abban, hogy kézfogási eljárással hoznak létre kapcsolatot. A kézfogás során a kliens és a szerver megállapodnak a kapcsolat biztosításához használt különféle paraméterekben:
Ezzel befejeződik a kézfogás, és megkezdődik a biztonságos kapcsolat, amelyet a kulcsadatok segítségével titkosítanak és visszafejtenek. Ha a fentiek bármelyike sikertelen, akkor az SSL-kézfogás meghiúsult, és a kapcsolat nem jön létre.
Létezik egy titkosítási paraméter-módosítási protokoll, amely jelzi a titkosítási módba való átállást. A protokoll egyetlen üzenetet tartalmaz, amely titkosítva és tömörítve van az aktuálisan létrehozott kapcsolaton. Az üzenet csak egy 1 értékű bitből áll.
struct { enum { change_cipher_spec ( 1 ), ( 255 ) } type ; } ChangeCipherSpec ;A kliens és a kiszolgáló titkosítás-módosítási üzenetet küld, hogy értesítse a fogadó felet, hogy a következő írások az újonnan egyeztetett CipherSpec-nek és kulcsoknak megfelelően védettek lesznek. Az üzenet elfogadása azt eredményezi, hogy a vevő utasítja az írási réteget, hogy azonnal másolja át a függőben lévő olvasási állapotot az aktuális olvasási állapotba. Közvetlenül az üzenet elküldése után a feladónak utasítania kell az írási réteget, hogy változtassa meg a visszaírási módot az aktuális írási módra. A rejtjelváltási üzenet a kézfogás során, a biztonsági paraméterek átvitele után, de a "kész" üzenet elküldése előtt kerül elküldésre.
Az írási SSL protokoll által támogatott érvényesítési típusok egyike a riasztási protokoll. A riasztási üzenet közvetíti az üzenetben felmerült nehézségeket és a riasztás leírását. A kritikus szintű riasztási üzenet azonnal megszakítja a kapcsolatot. Ebben az esetben a munkamenetnek megfelelő egyéb kapcsolatok folytatódhatnak, de a munkamenet azonosítót érvényteleníteni kell. Más üzenetekhez hasonlóan a riasztási üzenetet is titkosítják és tömörítik, amint az aktuális kapcsolati állapot megjelenik.
Az adatalkalmazási üzenet rekord szinten működik. A kapcsolat aktuális állapota alapján töredezett, tömörített és titkosított. Az üzenetek átlátszónak minősülnek a rekordréteg számára.
Számos támadást lehet végrehajtani az SSL protokoll ellen. Az SSL azonban ellenáll ezeknek a támadásoknak, feltéve, hogy a felhasználó csak megbízható szervereket használ az információk feldolgozásához. Az SSL 2.0 bizonyos helyzetekben sebezhető [23] :
Az SSL 2.0 alapértelmezés szerint le van tiltva az Internet Explorer 7 [24] , Mozilla Firefox 2 [25] , Opera 9.5 [26] és Safari böngészőkkel kezdődő böngészőkben .
2014. október 14-én a POODLE (Padding Oracle On Downgraded Legacy Encryption) nevű CVE-2014-3566 biztonsági rést azonosítottak. Ez a biztonsági rés lehetővé teszi a támadó számára, hogy Man-in-the-Middle támadást hajtson végre egy SSL 3.0-val titkosított kapcsolaton. A POODLE sebezhetőség a protokoll sérülékenysége, és nem egyik megvalósításában, így minden SSL v3-mal titkosított kapcsolatot érint.
Az SSL 3.0-nak más gyengeségei is vannak. Például a beállítandó főkulcs fele teljes mértékben az MD5 hash függvényétől függ, amely nem ütközésálló, ezért nem tekinthető biztonságosnak [27] .
Ezt a fajta támadást akkor hajtják végre, ha a támadónak fogalma van arról, hogy milyen típusú üzeneteket küldenek.
A kriptoanalitikus létrehozhat egy adatbázist, amelyben a kulcsok titkosított, egyszerű szöveges karakterláncok. A létrehozott adatbázis alapján meghatározhatja az adott adatblokknak megfelelő munkamenet-kulcsot.
Általában az ilyen támadások lehetségesek SSL esetén. Az SSL azonban nagy munkamenetkulcsok használatával próbálja felvenni ezeket a támadásokat – a kliens az exportkorlátozások által megengedettnél hosszabb kulcsot generál, amelynek egy része tiszta szövegben kerül elküldésre a szervernek, a többi pedig a titkos résszel kombinálva. egy kellően hosszú kulcs (például 128 bit, ahogy azt az RC4 megköveteli). Az egyszerű szöveges támadások blokkolásának módja az, hogy elfogadhatatlanul megnöveljük a szükséges szövegmennyiséget. A munkamenetkulcs hosszához hozzáadott minden bit megduplázza a szótár méretét. A 128 bites munkamenetkulcs használatával a szótár mérete messze meghaladja a modern technikai lehetőségeket (a megoldáshoz számos olyan atomra lenne szükség, amely nem található meg az egész univerzumban). Egy másik módja annak, hogy az SSL ellensúlyozza ezt a támadást, a lehető legnagyobb kulcshosszúság használata (nem export esetben). Ennek az a következménye, hogy a legegyszerűbb és legolcsóbb támadási módszer a kulcs frontális támadása, de egy 128 bites kulcs esetében a felfedés költsége végtelennek tekinthető.
Reflection AttackA támadó rögzíti a kommunikációs munkamenetet a szerver és az ügyfél között. Később a kliens rögzített üzeneteinek lejátszásával megpróbál kapcsolatot létesíteni a szerverrel. Az SSL azonban egy speciális egyedi kapcsolatazonosítóval (IC) visszaveri ezt a támadást. Természetesen elméletileg egy harmadik fél nem tudja megjósolni az IS-t, mert az véletlenszerű eseményeken alapul. Egy nagy erőforrással rendelkező támadó azonban nagyszámú munkamenetet naplózhat, és megpróbálhatja felvenni a "helyes" munkamenetet a szerver által a Server_Hello üzenetben küldött hiba alapján . De az SSL nonces -ek legalább 128 bitesek, ami azt jelenti, hogy a támadónak 264 nonces -t kell írnia ahhoz, hogy 50%-os esélye legyen a találgatásra. De a 2 64 elég nagy szám ahhoz, hogy értelmetlenné tegye ezeket a támadásokat.
Handshake protokoll támadásA támadó megpróbálhatja úgy befolyásolni a kézfogáscserét, hogy a felek eltérő titkosítási algoritmusokat válasszanak, és ne az általuk általában választottakat. Mivel sok implementáció támogatja az exportált titkosítást, és néhányan még a 0-titkosítást vagy a MAC-t is, ezek a támadások nagy érdeklődésre tartanak számot.
Egy ilyen támadáshoz a támadónak gyorsan meg kell hamisítania egy vagy több kézfogási üzenetet. Ha ez megtörténik, a kliens és a szerver különböző hash-értékeket számít ki a kézfogási üzenethez. Ennek eredményeként a felek nem fogadják el egymástól a „ kész ” üzeneteket . A titok ismerete nélkül a támadó nem tudja kijavítani a kész üzenetet , így a támadás észlelhető.
SSL kapcsolatok feltörése az adatközponton belülAz SSL-protokollokkal védett információk tömeges feltörésének leghírhedtebb incidensét az FBI-ügynökök hajtották végre Carnivore és NarusInsight rendszerekkel, ami az Electronic Frontier Foundation emberi jogi szervezet nevében indított perhez vezetett az AT&T ellen, amely ezeket a komplexumokat kriptográfiai feltörés céljából telepítette. védett információ.
Az eset miatt az Egyesült Államokban felháborodott nagy közfelháborodás és a Képviselőház Alkotmányos Bizottsága szintjén folyó vizsgálat ellenére nem történt az SSL-protokoll technológiai feltörése az FBI ügynökei által . Magába az adatközpontba telepítették a Carnivore-t és a NarusInsight-ot , ahol a távoli kliensekkel SSL-kapcsolatokat folytató szerverek voltak. A NarusInsight teljesen visszanyerte a titkosított információkat úgy, hogy nem az SSL-kapcsolatra figyelt, hanem magán az adatközponton belüli alkalmazásszerverek közötti belső forgalomra, miután az SSL-en keresztül kapott adatokat maga a szerver dekódolta, és megkapta azokat külső felhasználóktól.
Ez az incidens azonban megmutatta, hogy az SSL nem lehet megbízható eszköz az interneten található szerveradatok kriptográfiai védelmére, mivel a speciális szolgáltatások olyan lehallgató rendszereket telepíthetnek az adatközpontba, mint a NarusInsight vagy a SORM-2 [28] . Bármilyen típusú kriptográfiát, amely azt jelenti, hogy a rejtjelkulcsok az adatközpontban lévő fogadó szerveren vannak, automatikusan feltörnek a titkosszolgálati szippantásokkal úgy, hogy azokat magába a címzettbe fecskendezik be. Továbbá az adatok teljes rekonstrukciója a jelenleg szabályozott eljárásoknak és jogalkotási aktusoknak, például a „ Patriot Act ”-nek megfelelően. Ezen túlmenően ezek a jogalkotási aktusok az adatközpont-tulajdonosok vádemeléséig megtiltják a titkosszolgálati szippantók eltávolítását a fogadó szerverek belső részéből. Ha ezekkel a rendszerekkel működik, az SSL csak két felhasználó közötti kapcsolatot tud biztosítani az interneten, nem pedig egy külső webhelyhez fűződő SSL-kapcsolatot.
BEAST attack2011. szeptember 23-án Duong és Giuliano Rizzo thaiföldi kutatók egy Java kisalkalmazás segítségével bemutatták a Beast ("Browser Exploit Against SSL/TLS") elnevezésű "elképzelés bizonyítékát", amely a TLS 1.0 sebezhetőségére utal [29] [30] . Korábban ezt a sebezhetőséget, amelyet eredetileg Phillip Rogaway [31] fedezett fel 2002-ben, gyakorlatilag senki sem tudta kimutatni. A TLS 1.1 biztonsági rést 2006-ban jelentették.
A támadás több feltételezésen alapul, de mint kiderült, ezek megvalósíthatóak. Először is, a kriptoanalitikusnak képesnek kell lennie a böngésző által továbbított forgalom lehallgatására . Másodszor, valahogyan rá kell kényszeríteni a felhasználót, hogy ugyanazon a biztonságos kommunikációs csatornán keresztül továbbítsa az adatokat . Létesítsünk biztonságos kapcsolatot Bob ( B ) és Alice ( A ) számítógépei között. Tegyük fel, hogy a hozzánk érkezett üzenet i-edik blokkja titkos információkat (például jelszót) tartalmaz.
C i = E ( Kulcs , M i x vagy C i-1 ), ahol C i a titkosított blokk, M i a titkos szöveg
Tegyük fel, hogy az A jelszó P . Ellenőrizhetjük, hogy a feltételezésünk helyes-e:
Így sikerült elfogni az inicializálási vektort, ami a következő üzenet első blokkjának titkosítására szolgál, de ez egyben az előző üzenet utolsó blokkja is (titkosított formában) - IV . Elfogtuk a C i-1- et is . Ezen adatok felhasználásával üzenetet alkotunk, így az első blokk egyenlő lesz a következővel:
M 1 = C i-1 xor IV xor P
Ha a kriptoanalitikus ugyanazon a biztonságos csatornán tudja továbbítani az üzenetet, akkor az új üzenet első blokkja így fog kinézni:
C 1 = E ( Kulcs , M 1 xor IV ) = E ( Kulcs , ( C i-1 xor IV xor P ) xor P ) xor IV ) = E ( Kulcs , ( C i-1 xor P )) = C i
Kiderül, hogy ha P = M , akkor az új C 1 üzenet első titkosított blokkja egyenlő lesz a korábban elfogott C i -vel .
A gyakorlatban egy probléma adódik: az M blokk 16 bájt hosszú, még ha két bájt kivételével az összeset ismerjük, a többi kitalálásához 2 15 próbálkozásra van szükség. Mi van, ha nem tudunk semmit?
Ebből az a következtetés vonható le, hogy ez a gyakorlat akkor működhet, ha a kriptoanalitikusnak korlátozott számú feltételezése van M értékéről , vagy inkább ennek a blokknak a tartalmáról. A következő feltételezés az, hogy a kriptoanalitikus szabályozhatja az adatok helyét a blokkban, például tudva, hogy a jelszó n karakter hosszú. Ennek ismeretében a kriptoanalitikus úgy rendezi el a jelszót, hogy az első blokkba csak 1 karakter kerüljön, a következőbe pedig a maradék (n-1) - vagyis az első 15 bájt ismert adatot tartalmaz. És 1 karakter kitalálásához egy támadónak legrosszabb esetben 256 kísérletre van szüksége.
A sebezhetőséget jóval korábban ismerték, de a segédprogram fejlesztői az elsők, akiknek sikerült minden feltételt megvalósítaniuk ehhez a támadáshoz. Ugyanis:
Itt található azoknak a különféle technológiáknak és böngészőbővítményeknek a listája, amelyek ügynökinjektálást hajthatnak végre az áldozat böngészőjében: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API és Silverlight WebClient API.
RC4 attack2013-ban Szingapúrban konferenciát tartottak, ahol Dan Bernstein professzor bemutatta az SSL/TLS protokollok feltörésére szolgáló új technikát az RC4 titkosítással, amelyet 2011-ben javasoltak a BEAST elleni védekezésként. Az RC4-ben talált sebezhetőség az üzenetet kódoló bitfolyam véletlenszerűségének hiányával kapcsolatos. Miután ugyanazt az üzenetet sokszor átvezettük rajta, elegendő számú ismétlődő minta került elő az eredeti szöveg visszaállításához. Egy támadáshoz hatalmas mennyiségű adatot kell átvinni a titkosításon. A bemutatott megvalósításban a hackelés akár 32 órát is igénybe vett, de nem volt kizárva a folyamat optimalizálásának lehetősége sem. De ezt a támadást nehéz megvalósítani a gyakorlatban. Az alkotók azt állítják, hogy 256 rejtjelezett szövegre van szükség a 256 -ból 80 bájt helyreállításához .
Rejtjelek feltárásaMint tudják, az SSL különféle kriptográfiai paraméterektől függ. RSA nyilvános kulcsú titkosítás szükséges a kulcsátvitelhez és a szerver/kliens hitelesítéshez. Rejtjelként azonban különféle kriptográfiai algoritmusokat használnak. Így, ha sikeres támadást hajtanak végre ezen algoritmusok ellen, akkor az SSL többé nem tekinthető biztonságosnak. Bizonyos kommunikációs munkamenetek elleni támadás a munkamenet rögzítésével történik, majd idővel kiválasztják a munkamenet-kulcsot vagy az RSA-kulcsot.
Man-in-the-middle támadásMás néven MitM (Man-in-the-Middle) támadás. Ez három fél részvételével jár: a szerver, az ügyfél és a támadó között. Ebben a helyzetben a támadó elfoghat minden üzenetet, amely mindkét irányban következik, és lecserélheti azokat. Úgy tűnik, hogy a támadó a kiszolgáló az ügyfél számára, az ügyfél pedig a szerver számára. Diffie-Hellman kulcscsere esetén ez a támadás hatékony, mivel a kapott információ sértetlensége és forrása nem ellenőrizhető. Ilyen támadás azonban nem lehetséges az SSL protokoll használatával [32] , mivel a hitelesítő hatóság [33] által hitelesített tanúsítványok segítségével hitelesítik a forrást (általában a szervert) .
A támadás akkor lesz sikeres, ha:
Ez a fajta támadás a Microsoft Forefront TMG tűzfalat vagy a Blue Coat Proxy SG proxyszervert használó nagy szervezeteknél fordul elő . Ebben az esetben a „behatoló” a szervezet hálózatának szélén helyezkedik el, és lecseréli az eredeti tanúsítványt a sajátjára. Ez a támadás annak köszönhető, hogy magát a proxykiszolgálót megbízható hitelesítési hatóságként (vagy gyökérként, vagy a vállalati gyökér utódjaként) lehet megadni. Általában egy ilyen megvalósítási eljárás átlátható a felhasználó számára a vállalati felhasználók Active Directory környezetben végzett munkája miatt. Ez az eszköz használható mind a továbbított információk ellenőrzésére, mind a biztonságos HTTPS-kapcsolaton keresztül továbbított személyes adatok ellopására.
A legvitatottabb kérdés az, hogy a felhasználó tisztában van-e az adatelfogás lehetőségével, hiszen gyökértanúsítvány-csere esetén nem jelennek meg biztonsági üzenetek, és a felhasználó elvárja a továbbított adatok bizalmas kezelését.
Ezen túlmenően, ha a Forefront TMG-t SSL-proxyként használja, lehetőség van egy második MitM-támadásra az internetes oldalon, mivel az eredeti tanúsítvány nem kerül át a felhasználóhoz, és a Forefront TMG beállítható úgy, hogy elfogadja, majd lecserélje önmagát. -aláírt vagy visszavont tanúsítványok. Az ilyen támadások elleni védelem érdekében teljesen meg kell tiltani az olyan webszerverekkel való munkát, amelyek tanúsítványai hibákat tartalmaznak, ami minden bizonnyal ahhoz vezet, hogy sok webhelyen nem lehet HTTPS protokollal dolgozni.
A Blue Coat Proxy SG védett a második MitM támadás ellen: a rendszer lehetővé teszi a házirend konfigurálását úgy, hogy egy nem megbízható webszerver-tanúsítvány esetén a rendszer egy olyan tanúsítványt is adjon ki, amelyet nem egy megbízható lánc, hanem egy ideiglenes ön ír alá. - írt alá egyet.
THC-SSL-DOS2011. október 24-én a The Hacker's Choice (THC) kiadta a THC-SSL-DOS segédprogramot, amellyel DoS támadásokat lehet végrehajtani SSL szervereken. Ez a segédprogram az SSL újratárgyalási funkciójában található biztonsági rést használja ki, amelyet eredetileg az SSL biztonságosabbá tételére terveztek. Az újraérvényesítés lehetővé teszi a szerver számára, hogy új privát kulcsot hozzon létre egy meglévő SSL-kapcsolaton keresztül. Ez a funkció alapértelmezés szerint engedélyezve van a legtöbb szerveren. A biztonságos kapcsolat létrehozása, valamint az SSL újraellenőrzés végrehajtása többszörösen több erőforrást igényel a szerver oldalon, mint a kliens oldalon, vagyis ha a kliens sok SSL újraérvényesítési kérelmet küld, az lemeríti a szerver rendszer erőforrásait.
A THC egyik résztvevője szerint a sikeres támadáshoz olyan laptopra van szükség, amelyre telepítve van a segédprogram, és internet-hozzáférésre van szükség. A program nyilvánosságra került, mert pár hónapja megjelent a hálózaton. A fejlesztők szerint támadás akkor is végrehajtható, ha a szerver nem támogatja az újraérvényesítési funkciót, bár ehhez módosítani kell a támadási módot. Ebben az esetben sok TCP-kapcsolat jön létre az új SSL-kézfogáshoz, de több botra van szükség a hatékony támadáshoz.
Védekezésképpen egyes szoftverfejlesztők speciális szabályok felállítását javasolják egy olyan ügyféllel való kapcsolat megszakításához, amely másodpercenként többször hajt végre újraérvényesítési műveletet.
2009-ben egy Black Hat konferencián Washington DC-ben Moxie Marlinspike, egy független hacker bemutatott egy új eszközt , az SSLstrip-et, amely fontos információkat tud kinyerni azáltal, hogy elhiteti a felhasználókkal, hogy biztonságos oldalon vannak, miközben nem. Ezt úgy érhetjük el, hogy a normál SSL-biztonságú oldalakat nem biztonságos megfelelőikké alakítjuk, megtévesztve a szervert és a klienst is. A segédprogram azért működik, mert sok SSL-védelmet használó webhely nem biztonságos kezdőlappal rendelkezik. Csak azokat a részeket titkosítják, ahol fontos információkat továbbítanak. És amikor a felhasználó az engedélyezési oldalra kattint, a segédprogram lecseréli a webhely válaszát a https http-re cserélésével. Az SSLstrip a következő technikákat használja: egyrészt egy proxyszervert telepítenek a helyi hálózatra, amely érvényes tanúsítvánnyal rendelkezik - innentől a felhasználó továbbra is https-t lát a címsorban, másodszor egy technikát használnak hosszú URL -ek létrehozására , amelyek hamis '/ ' a címsorban – ez azért szükséges, hogy elkerüljük a böngészők karakterkonverzióját. A rendszer működésének bizonyítására Moxxi SSLstrip-et futtatott a Tor hálózatot kiszolgáló szerveren , és 24 óra alatt 254 jelszót halászott ki a Yahoo , a Gmail , a Ticketmaster, a PayPal és a LinkedIn felhasználóitól .
Az SSL protokollban a hibakezelés nagyon egyszerű. Ha hibát észlel, az, aki felfedezte, üzenetet küld a partnerének. A végzetes hibák megkövetelik, hogy a szerver és a kliens bezárja a kapcsolatot [35] . Az SSL protokoll a következő hibákat határozza meg:
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |
| Internet biztonsági mechanizmusok | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Titkosítás és forgalomszűrés _ |
| ||||||||||||||
| Hitelesítés | |||||||||||||||
| Számítógép védelem |
| ||||||||||||||
| IP telefonbiztonság |
| ||||||||||||||
| Forgalom anonimizálása | |||||||||||||||
| Vezetéknélküli Biztonság | |||||||||||||||