Általános

Az SSL (és annak utódja, TLS ) egy protokoll, amely közvetlenül a TCP tetején működik (bár vannak olyan datagram alapú protokollok megvalósításai is, mint az UDP). Így a magasabb rétegeken (például a HTTP-n) lévő protokollok változatlanok maradhatnak, míg az s amíg biztonságos kapcsolatot biztosít. Az SSL réteg alatt a HTTP megegyezik a HTTPS-szel.

Az SSL / TLS megfelelő használatakor a támadók a kábelen csak azt láthatják, hogy melyik IP-hez és porthoz csatlakozol, nagyjából mennyi adatot küldesz. , és milyen titkosítást és tömörítést használnak. Megszakíthatja a kapcsolatot is, de mindkét fél tudja, hogy a kapcsolatot megszakította egy harmadik fél.

Tipikus használat esetén a támadó képes lesz kitalálni, hogy melyik gazdagépnévhez csatlakozik (de az URL többi részét nem): bár maga a HTTPS nem fedi fel a hosztnevet, a böngészőjének általában először DNS-kérelmet kell benyújtania, hogy megtudja, milyen IP-címre küldje el a kérést.

Magas a protokoll szintjének leírása

A TCP kapcsolat kiépítése után az ügyfél elindítja az SSL kézfogást. Az ügyfél (amely lehet böngésző, valamint bármely más program, például a Windows Update vagy a PuTTY) számos specifikáció:

• mely az SSL / TLS verziója fut,
• milyen rejtjelezõket akar használni, és
• mit tömörítési módszerek használni kívánt.

A szerver azonosítja a legmagasabb SSL / TLS verziót, amelyet mind az ügyfél, mind az ügyfél támogat, kiválaszt egy titkoslapot az ügyfél egyik opciójából (ha egyet támogat), és opcionálisan kiválaszt egy tömörítési módszert.

Ezek után az alapbeállítás elkészül, a szerver elküldi tanúsítványát. Ebben a tanúsítványban magának az ügyfélnek vagy egy félnek kell megbíznia. Például, ha az ügyfél megbízik a GeoTrustban, akkor az ügyfél megbízhat a Google.com tanúsítványában, mert a GeoTrust rejtjelesen aláírt Google tanúsítvány.

Miután ellenőrizte a tanúsítványt, és megbizonyosodott arról, hogy ez a szerver valóban az, akinek állítja magát (és nem egy férfi a közepén), kulcsot cserél. Ez lehet nyilvános kulcs, egy ” PreMasterSecret ” vagy egyszerűen semmi, a választott rejtjelkészlettől függően. A kiszolgáló és az ügyfél is kiszámíthatja a kulcsot az > szimmetrikus titkosítás ^{miért nem PKE?} . Az ügyfél azt mondja a szervernek, hogy ezentúl minden kommunikáció titkosításra kerül, és egy titkosított és hitelesített üzenetet küld a szervernek.

A szerver ellenőrzi, hogy a MAC (hitelesítésre használt) helyes-e és az üzenet helyesen visszafejthető-e. Ezután visszaküld egy üzenetet, amelyet az ügyfél ellenőriz mint jól.

A kézfogás befejeződött, és a két gép biztonságosan kommunikálhat. További információ: technet.microsoft.com/en-us/library/cc785811 és hu.wikipedia .org / wiki / Secure_Sockets_Layer .

A kapcsolat bezárásához close_notify “riasztást” használnak. Ha egy támadó a TCP-kapcsolat befejezésével (FIN csomag beadásával) próbálja megszakítani a kapcsolatot, akkor mindkét fél tudni fogja, hogy a kapcsolatot helytelenül bontották meg. A kapcsolatot ez azonban nem veszélyeztetheti, csupán megszakíthatja.

További részletek

Miért bízhat meg a Google.com-ban a GeoTrust megbízásával?

Egy webhely biztonságosan akar kommunikálni veled. A személyazonosságának igazolásához és annak biztosításához, hogy ne támadó legyen, rendelkeznie kell a szerver “s nyilvános kulcsával . Azonban alig tárolhatja az összes kulcsot az összes földi weboldalról az adatbázis hatalmas lenne, és óránként frissítéseket kellene futtatni!

Erre a megoldás a Certificate Authorities, vagy röviden a CA.Az operációs rendszer vagy a böngésző telepítésekor valószínűleg a megbízható CA-k listája is érkezett hozzá. Ez a lista tetszés szerint módosítható; eltávolíthatja azokat, akikben nem bízik, másokat hozzáadhat, vagy akár saját hitelesítésszolgáltatót is létrehozhat (bár ebben a hitelesítésszolgáltatóban egyedül te fogsz megbízni, ezért nem sokat használ a nyilvános weboldalak számára). Ebben a CA listában a CA nyilvános kulcsa is van tárolva.

Amikor a Google szervere elküldi Önnek a tanúsítványát, megemlíti azt is, hogy a GeoTrust aláírta. Ha megbízik a GeoTrustban, ellenőrizheti (a GeoTrust nyilvános kulcsának használatával), hogy a GeoTrust valóban aláírta-e a szerver tanúsítványát. A tanúsítvány önálló aláírásához szüksége van a privát kulcsra, amelyet csak a GeoTrust ismer. Így a támadó nem tudja aláírni a tanúsítványt, és helytelenül állíthatja magát a Google.com-nak. Amikor a tanúsítványt akár egy bit is módosította, a jel hibás lesz, és az ügyfél elutasítja.

Tehát, ha tudom a nyilvános kulcsot, a szerver képes igazolja személyazonosságát?

Igen. Általában a nyilvános kulcs titkosítja, a titkos kulcs pedig visszafejt. Titkosítson egy üzenetet a szerver nyilvános kulcsával, küldje el, és ha a szerver meg tudja ismételni az eredeti üzenetet, az csak bebizonyította, hogy a privát kulcsot a kulcs felfedése nélkül kapta meg.

Ez az oka annak, hogy annyira fontos, hogy megbízhassunk a nyilvános kulcsban: bárki létrehozhat magán / nyilvános kulcs párokat, támadó is. Nem akarja, hogy a támadó nyilvános kulcsát használja!

Ha Az egyik hitelesítésszolgáltató, amelyben megbízik, sérül, a támadó az ellopott titkos kulcs segítségével aláírhatja tanúsítványát minden tetsző webhelyhez. Amikor a támadó hamisított tanúsítványt küldhet az ügyfelének, amelyet ő maga ír alá a megbízható hitelesítésszolgáltató magánkulcsával, az ügyfele nem tudja, hogy a nyilvános kulcs hamisított, ellopott titkos kulccsal aláírva.

De egy hitelesítésszolgáltató meg tudja bízni, hogy bármelyik kiszolgálóban bízzak!

Igen, és itt jön a bizalom Meg kell bízni a CA-ban, hogy ne készítsen tanúsítványokat, ahogy tetszik. Amikor azonban az olyan szervezetek, mint a Microsoft, az Apple és a Mozilla megbíznak egy CA-ban, a CA-nak ellenőriznie kell; egy másik szervezet rendszeresen ellenőrzi őket, hogy megbizonyosodjon arról, hogy minden továbbra is megfelelően működik-e. a szabályoknak.

A tanúsítvány kiadása akkor és csak akkor történik meg, ha a regisztráló be tudja bizonyítani, hogy birtokában van annak a domainnek, amelyre a tanúsítványt kiállították.

Mi ez a MAC az üzenet hitelesítéséhez?

Minden üzenetet úgynevezett üzenet hitelesítési kóddal írnak alá , vagy Röviden MAC. Ha megegyezünk egy kulcsban és egy hash-rejtjelben, akkor ellenőrizheti, hogy az üzenetem tőlem származik-e, és hogy az üzenet tőletek származik-e.

Például a helyes ló akkumulátor kapcsok ” és az ” példa ” üzenet, Kiszámolhatom a MAC ” 58393 “. Amikor ezt az üzenetet elküldöm Önnek a MAC-mal (Ön már ismeri a kulcsot), akkor ugyanazt a számítást végezheti el, és egyeztetheti a kiszámított MAC-ot az általam elküldött MAC-szal.

A támadó módosíthatja az üzenetet de nem ismeri a kulcsot. Nem tudja kiszámítani a megfelelő MAC-ot, és tudni fogja, hogy az üzenet nem hiteles.

Ha a MAC kiszámításakor sorszámot ad meg, kiküszöbölheti a visszajátszást támadások . Az SSL ezt csinálja.

Azt mondta, hogy az ügyfél küld egy kulcsot, amelyet a beállításhoz használnak szimmetrikus titkosítás. Mi akadályozza a támadókat abban, hogy használják?

A szerver nyilvános kulcsa igen. Mivel meggyőződtünk arról, hogy a nyilvános kulcs valóban a szerveré, és senki másé, titkosítani tudja a kulcsot a nyilvános kulccsal. Amikor a szerver megkapja, akkor titkosíthatja a privát kulccsal. Amikor bárki más megkapja, nem tudja visszafejteni.

Ezért is fontos a kulcs mérete: Minél nagyobb a nyilvános és a magánkulcs, annál nehezebb feltörni azt a kulcsot, amelyet az ügyfél a szervernek küld.

Az SSL feltörése

Összefoglalva :

• Próbálja meg, ha a felhasználó figyelmen kívül hagyja a tanúsítványra vonatkozó figyelmeztetéseket;
• Az alkalmazás adatokat tölthet le innen: titkosítatlan csatorna (pl. HTTP), amelyet meg lehet hamisítani;
• A HTTPS-hez beküldött védtelen bejelentkezési oldal módosítható úgy, hogy a HTTP-nek is beküldje magát;
• a nem javított alkalmazások sebezhető az olyan kizsákmányolások miatt, mint a BEAST és a CRIME;
• más módszerekhez folyamodik h mint fizikai támadás;
• Használja ki az mellékcsatornákat , mint az üzenet hossza és az idő az üzenet kialakításához;
• várja meg a kvantum támadásokat .

Lásd még: Ivan Ristic SSL elleni sok támadási vektort tartalmazó sémája ^(png)

Részletesen:

Nincs egyszerű és egyértelmű út; Az SSL biztonságos, ha helyesen végzett. A támadó megpróbálhatja, ha a felhasználó figyelmen kívül hagyja a tanúsítványra vonatkozó figyelmeztetéseket , ami azonnal megsértené a biztonságot. Amikor a felhasználó ezt megteszi, a támadónak nincs szüksége egy hitelesítésszolgáltatótól származó magánkulcsra a tanúsítvány hamisításához, csupán saját tanúsítványt kell küldenie.

Egy másik módszer a alkalmazás (kiszolgáló- vagy kliens-oldal). Könnyű példa erre a weboldalak: ha a webhely által használt erőforrások (például kép vagy szkript) egyikét HTTP-n keresztül töltik be, akkor a titoktartás már nem garantálható. ne küldje el a HTTP Referer fejlécet, ha nem biztonságos erőforrásokat igényel egy biztonságos oldalról ( forrás ), akkor is lehetséges, hogy valaki lehallgatja a forgalmat, és kitalálja, hol van innen látogat el; Például, ha tudják, hogy az X, Y és Z képeket egy oldalon használják, akkor sejthetik, hogy az adott oldalt látogatja, amikor látja, hogy a böngésző egyszerre kéri ezt a három képet. Ezenkívül a Javascript betöltésekor az egész oldal sérülhet. A támadó bármilyen szkriptet végrehajthat az oldalon, módosítva például azt, hogy kinek fog menni a banki tranzakció.

Amikor ez megtörténik (az erőforrás HTTP-n keresztül töltődik be), a böngésző vegyes tartalmú figyelmeztetést ad: Chrome , Firefox , Internet Explorer 9

A HTTP másik trükkje az, ha a bejelentkezési oldal nincs biztonságban, és beküldik egy https oldalnak. ” Remek, ” valószínűleg a fejlesztő gondolta, ” most elmentem a szerver terhelését és a a jelszót továbbra is titkosítva küldjük! ” A probléma sslstrip , egy eszköz, amely a nem biztonságos bejelentkezési oldalt úgy módosítja, hogy az beküld valahova, hogy a támadó el tudja olvasni.

Az elmúlt években különféle támadások is történtek, például a TLS újratárgyalási sebezhetőség , sslsniff , BEAST , és nemrégiben, BŰNÖZÉS . Valamennyi gyakori böngésző védett mindezen támadások ellen, így ezek a biztonsági rések nem jelentenek kockázatot, ha naprakész böngészőt futtat.

Végül, de nem utolsósorban más módszereket is igénybe vehet a beszerzéshez. az SSL által megtagadott információkat. Ha már látja és megváltoztatja a felhasználó kapcsolatát, akkor nem biztos, hogy olyan nehéz helyettesíteni az egyik .exe letöltését egy billentyűzárral, vagy egyszerűen csak fizikailag megtámadni az illetőt. A titkosítás meglehetősen biztonságos, de az emberek és az emberi tévedés még mindig gyenge tényező. a Verizon közleménye szerint az adatsértések 10% -a fizikai támadással járt (lásd a 3. oldalt), tehát ” s minden bizonnyal szem előtt tartandó dolog.

Megjegyzések

• Érdekelne egy kis további magyarázat a ” kulcsot cserélnek ” a szimmetrikus kulcsra. Hogyan történhet ez meg úgy, hogy valaki, akinek csomagszippantója van, nem tud hozzáférni.
• @Yehosef Jó kérdés! Ezt elfelejtettem elmagyarázni a válaszomban. Körülnézve kiderül, hogy tulajdonképpen van erre vonatkozó kérdés: security.stackexchange.com/q/6290/10863
• @ Iwazaru Az összes CA ezt teszi az első nap óta. A tanúsítvány lényege, hogy megadja az adott domain nyilvános kulcsát, és annak aláírásával igazolja, hogy valóban a megfelelő kulcs a tartományhoz. Hagyja, hogy a ‘ s Encrypt pontosan azt tegye, amire kellene: igazolja, hogy Ön a domain tulajdonosa, és ha bizonyítani tudja, írja alá a tanúsítványt (kulccsal). Most mindenki, aki bízik a Let ‘ s Encrypt programban, amely gyakorlatilag minden böngésző, megbízik ebben a tanúsítványban.
• Er, nem. A TLS valóban csak a TCP tetején van megvalósítva.
• Nagyon egyértelműnek találta ezt a grafikus SSL kézfogási folyamatot.

Mivel az SSL általános fogalmát már más kérdések is lefedték (pl. ez és az egyik ), ezúttal a részletekért folytatom. A részletek fontosak. Ez a válasz kissé bonyolult lesz.

Előzmények

Az SSL nagy múltú és több verziójú protokoll.Az első prototípusok a Netscape-től származnak, amikor fejlesztették zászlóshajó böngészőjük, a Netscape Navigator első verzióit (ez a böngésző megölte Mozaik a Böngészőháborúk korai szakaszában, amelyek még mindig tombolnak, bár új versenytársakkal). Az 1. verziót soha nem hozták nyilvánosságra, ezért nem tudjuk, hogy nézett ki. Az SSL 2. verzióját egy vázlat írja le, amely ott olvasható; számos gyengesége van, némelyik meglehetősen súlyos, ezért elavult és az újabb SSL / TLS implementációk nem támogatják (míg a régebbi alapértelmezés szerint deaktiváltak). Az SSL 2-es verzióról nem beszélek tovább, csak alkalmi hivatkozásként.

Az SSL 3-as verzió (amelyet “SSLv3-nak fogok nevezni) egy továbbfejlesztett protokoll volt, amely ma is működik és széles körben támogatott. Noha a Netscape Communications továbbra is a tulajdona (vagy bárki, akinek manapság ez a tulajdonosa), a protokollt “történelmi RFC-ként” ( RFC 6101 ) tették közzé. Időközben a protokollt szabványosították, a jogi problémák elkerülése érdekében új névvel ; az új név TLS .

A TLS-nek eddig három verziója készült, mindegyik a dedikált RFC: TLS 1.0 , TLS 1.1 és TLS 1.2 . Belsőleg nagyon hasonlítanak egymásra és az SSLv3-ra, olyan mértékben, hogy egy megvalósítás könnyen támogathatja az SSLv3-at és mindhárom TLS-verziót, a kód legalább 95% -a közös. Mégis, belsőleg, az összes verziót egy major.minor formátumú verziószám jelöli; Az SSLv3 ekkor 3.0, míg a TLS verziók 3.1, 3.2 és 3.3. Így nem csoda, hogy a TLS 1.0-t néha SSL 3.1-nek hívják (és ez sem hibás). Az SSL 3.0 és a TLS 1.0 csak néhány részletben különbözik egymástól. A TLS 1.1 és 1.2 még nem támogatott széles körben, bár erre van lendület a lehetséges gyengeségek miatt (lásd alább, a “BEAST támadás”). Az SSLv3 és a TLS 1.0 “mindenhol” támogatott (még az IE 6.0 is ismeri őket).

Context

Az SSL célja egy biztonságos kétirányú alagút biztosítása tetszőleges adatok számára. Tekintsük a TCP -et, az interneten keresztüli adatküldés jól ismert protokollját. A TCP az IP “csomagokon” keresztül működik, és kétirányú alagutat biztosít a bájtok számára; minden bájtértéknél működik, és két adatfolyamba küldi őket, amelyek egyszerre működhetnek. A TCP elvégzi azt a nehéz munkát, hogy az adatokat csomagokra bontja, nyugtázza, visszaállítja a megfelelő sorrendbe, miközben eltávolítja az ismétlődéseket és visszahozza az elveszett csomagokat. A TCP-t használó alkalmazás szempontjából csak két adatfolyam van, és a csomagok láthatatlanok; Különösen a folyamok nem oszlanak “üzenetekre” (az alkalmazás feladata, hogy saját kódolási szabályokat fogadjon el, ha üzeneteket szeretne kapni, és ez pontosan az, ami HTTP nem).

A TCP megbízható “balesetek”, azaz átviteli hibák esetén, amelyek a pelyhes hardverből, a hálózati torlódásokból, az okostelefonos emberekből származnak, akik kijönnek az adott bázisállomás hatótávolságából. és más nem rosszindulatú események. Azonban egy rossz szándékú egyén (a “támadó”), akinek valamilyen hozzáférése van a szállítóeszközhöz, elolvashatja az összes továbbított adatot és / vagy szándékosan megváltoztathatja azokat, és a TCP nem véd ez ellen. SSL.

Az SSL feltételezi , hogy TCP-szerű protokollon keresztül működik, amely megbízható adatfolyamot nyújt; Az SSL nem valósítja meg az elveszett csomagok és hasonló dolgok újbóli kibocsátását. A támadó állítólag hatalmában áll, hogy elkerülhetetlen módon teljesen megzavarja a kommunikációt (például levághatja a kábeleket), így az SSL feladata:

• észlel változásokat (a támadónak nem kell képesnek lennie az adatok némán megváltoztatására);
• biztosítsa az adatok titkosságát (a a támadónak nem szabad ismereteket szereznie a kicserélt adatokról).

Az SSL ezeket a célokat nagy (de nem abszolút) mértékben teljesíti.

Records

Az SSL rétegzett és az alsó réteg a rekord protokoll . Az SSL alagútban küldött adatokat rekordokra osztják fel. A vezetéken (az alapul szolgáló TCP foglalaton vagy TCP-szerű adathordozón) keresztül a rekord így néz ki:

HH V1:V2 L1:L2 adatok

ahol:

• HH egyetlen bájt, amely jelzi a rekordban szereplő adatok típusát.Négy típus van meghatározva: change_cipher_spec (20), alert (21), kézfogás (22) és application_data ( 23).
• V1: V2 a protokoll verziója, két bájt felett. Az összes jelenleg definiált verzió esetében a V1 értéke 0x03, míg a V2 értéke 0x00 az SSLv3, 0x01 a TLS 1.0, 0x02 a TLS 1.1 esetén és 0x03 a TLS 1.2 esetén.
• L1: L2 a data hossza bájtokban (a nagy endián konvenció használt: a hossza 256 * L1 + L2). A data teljes hossza nem haladhatja meg az 18432 bájtot, de a gyakorlatban még ezt az értéket sem érheti el.

Tehát egy rekordnak öt- bájt fejléc, amelyet legfeljebb 18 kB adat követ. A data szimmetrikus titkosítást és integritás-ellenőrzést végez. Ha rekordot bocsátanak ki, a feladónak és a vevőnek egyaránt meg kell állapodnia arról, hogy mely kriptográfiai algoritmusokat alkalmazzák jelenleg és mely kulcsokkal; ezt a megállapodást a következő részben ismertetett kézfogási protokollon keresztül érik el. A tömörítést, ha van ilyen, ezen a ponton is alkalmazzák.

Teljes részletességgel a rekord felépítése így működik:

• Kezdetben van néhány bájt, amelyet át kell vinni ; ezek az alkalmazások adatai vagy más típusú bájtok. Ez a hasznos teher legfeljebb 16384 bájtból áll, de lehet, hogy kevesebb (a 0 hosszú hasznos terhelés törvényes, de kiderült, hogy az Internet Explorer 6.0 nem szereti ezt egyáltalán ) .
• Ezután a hasznos teher tömörítésre kerül a jelenleg elfogadott tömörítési algoritmusokkal. A tömörítés állapotfüggő, és ezért a korábbi rekordok tartalmától függhet. A gyakorlatban a tömörítés vagy “null” (nincs tömörítés), vagy “Deflate” ( RFC 3749 ), az utóbbi jelenleg udvariasan, de határozottan mutatja a kijáratot ajtót a webes környezetben, a legutóbbi BŰNCSELEKMÉNY támadás miatt . A tömörítés célja az adatok rövidítése, de bizonyos kedvezőtlen helyzetekben szükségszerűen kissé bővítenie kell azokat (a galamblyuk elv miatt). Az SSL legfeljebb 1024 bájtos bővítést tesz lehetővé. Természetesen a null tömörítés soha nem bővül (de soha nem is rövidül); A deflate legfeljebb 10 bájttal bővül, ha a megvalósítás megfelelő.
• A tömörített hasznos terhet ezután megvédik a módosításoktól és titkosítják. Ha a jelenlegi titkosítási és integritási algoritmusok nullák, akkor ez a lépés nem működik. Ellenkező esetben egy MAC kerül hozzá, majd néhány kitöltés (a titkosítási algoritmustól függően), és az eredmény titkosításra kerül. Ezek a lépések ismét némi kiterjesztést indukálnak, amelyet az SSL szabvány 1024 extra bájtra korlátoz (a tömörítési lépés maximális kiterjesztésével kombinálva ezzel elérkezünk az 18432 bájthoz, amelyhez hozzá kell adnunk az 5 bájtos fejlécet).

A MAC általában HMAC a szokásos hash funkciók egyikével (főleg MD5, SHA-1 vagy SHA-256). (az SSLv3 esetében ez nem az “igazi” HMAC, hanem valami nagyon hasonló, és legjobb tudomásunk szerint olyan biztonságos, mint a HMAC). A titkosítás vagy egy blokkos titkosítást használ CBC módban , vagy az RC4 adatfolyam titkosítást. Megjegyezzük, hogy elméletileg másfajta módok vagy algoritmusok is alkalmazhatók, például ezen remek üzemmódok egyike, amelyek kombinálják a titkosítást és az integritás ellenőrzését; ehhez még is van némi RFC . A gyakorlatban azonban a telepített implementációk még nem tudnak ezekről, ezért ismerik a HMAC-ot és a CBC-t. Alapvető fontosságú, hogy a MAC először kiszámításra kerül és az adatokhoz legyen csatolva, és az eredmény titkosításra kerül. Ez MAC-titkosítás, és valójában nem túl jó ötlet . A MAC kiszámítása a (tömörített) hasznos teher és egy sorszám összefűzésével történik, így egy szorgalmas támadó nem cserélhet rekordokat.

Kézfogás

A kézfogás egy olyan protokoll, amelyet a rekordprotokollon belül játszanak le. Célja a rekordokhoz használandó algoritmusok és kulcsok meghatározása. üzenetekből áll. Minden kézfogási üzenet négy bájtos fejléccel kezdődik, egy bájt írja le az üzenet típusát, majd három bájt az üzenet hosszára (big-endian konvenció). Az egymást követő kézfogási üzeneteket ezután a “kézfogás” típusú címkével ellátott rekordokkal küldjük (az egyes rekordok fejlécének első bájtja 22-es értékű).

Vegye figyelembe a rétegeket: a kézfogás üzeneteit négy- bájt fejlécet, majd rekordként küldjük el, és minden rekordnak is megvan a saját fejléce. Ezenkívül ugyanazon a rekordon belül több kézfogási üzenetet lehet elküldeni, és egy adott kézfogás üzenetet fel lehet osztani több rekordra.A kézfogás üzeneteit létrehozó modul szempontjából a “rekordok” csak egy adatfolyam, amelyre bájtok küldhetők; nem vesz tudomást az adott adatfolyam rekordokra történő felosztásáról.

Teljes kézfogás

Kezdetben az ügyfél és a kiszolgáló “megegyezik” a null titkosításban MAC és null tömörítés nélkül. Ez azt jelenti, hogy az általuk először küldött rekordot tiszta szövegként és védelem nélkül küldjük.

A kézfogás első üzenete egy ClientHello. Ez az az üzenet, amellyel az ügyfél kijelenti, hogy valamilyen SSL-t kíván létrehozni. Vegye figyelembe, hogy az “ügyfél” szimbolikus szerep; jelentése: “az a párt, amelyik először szól”. Így történik, hogy a HTTPS kontextusban, amely HTTP-belül-SSL-a TCP-n belül, mindhárom rétegben szerepel az “ügyfél” és a “kiszolgáló” fogalom, és mindannyian egyetértenek (a TCP-kliens egyben az SSL-kliens és a HTTP kliens), de ez egyfajta egybeesés.

A ClientHello üzenet a következőket tartalmazza:

• a maximális protokoll verzió, amelyet az ügyfél támogatni kíván;
• az “ügyfél véletlenszerű” (32 bájt, ebből 28 állítólag kriptográfiailag erős számgenerátorral jön létre);
• a ” session ID “(abban az esetben, ha az ügyfél rövidített kézfogással akarja folytatni a munkamenetet, lásd alább);
• az ügyfél által preferált” titkosító csomagok “listája, amelyekről az ügyfél tud;
• az ügyfél által ismert, az ügyfél által preferált tömörítési algoritmusok listája;
• néhány választható kiterjesztés.

A rejtjelcsomag egy 16 bites szimbolikus azonosító egy kriptográfia-készlethez c algoritmusok. Például a TLS_RSA_WITH_AES_128_CBC_SHA rejtjelkészlet értéke 0x002F, ami azt jelenti, hogy “a rekordok HMAC / SHA-1 és AES titkosítást használnak 128 bites kulccsal, és a kulcscsere titkosítással történik véletlenszerű kulcs a kiszolgáló RSA nyilvános kulcsával.

A szerver a ClientHello -re ServerHello amely a következőket tartalmazza:

• az ügyfél és a szerver által használt protokoll verziója;
• a “szerver random” (32 bájt, 28 véletlen byte-ok);
• a kapcsolat munkamenet-azonosítója;
• a használni kívánt titkosító csomag;
• a használni kívánt tömörítési algoritmus;
• opcionálisan néhány kiterjesztés.

A teljes kézfogás így néz ki:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Ez a séma szégyentelenül másolták az RFC-ből.)

Látjuk a ClientHello és ServerHello fájlokat. Ezután a szerver elküldi néhány más üzenet, amelyek a titkosító csomagtól és néhány más paramététől függenek rs:

• Tanúsítvány: a szerver tanúsítványa, amely tartalmazza a nyilvános kulcsát. Bővebben erről alább. Ezt az üzenetet szinte mindig elküldjük, kivéve, ha a rejtjelkészlet tanúsítvány nélküli kézfogást ír elő.
• ServerKeyExchange: néhány extra érték a kulcscseréhez, ha a tanúsítványban szereplő nem elegendő. Különösen a “DHE” titkosítócsomagok használnak egy efemer Diffie-Hellman kulcscserét, amelyhez ez az üzenet szükséges.
• CertificateRequest: egy üzenet, amelyben azt kéri, hogy az ügyfél szintén azonosítsa magát egy saját tanúsítvánnyal. Ez az üzenet tartalmazza a megbízhatósági horgonyok (más néven “gyökértanúsítványok”) listáját, amelyeket a szerver az ügyféltanúsítvány érvényesítéséhez fog használni.
• ServerHelloDone: egy marker üzenet (hossza nulla), amely azt mondja, hogy a szerver kész, és az ügyfélnek most beszélnie kell.

Ezután az ügyfélnek válaszolnia kell a következővel:

• Tanúsítvány: az ügyféltanúsítvány, ha a szerver kért egyet. Finom variációk vannak a verziók között (SSLv3 esetén az ügyfélnek el kell hagynia ezt az üzenetet, ha nincs tanúsítványa; TLS 1.0+ esetén ugyanabban a helyzetben Certificate üzenet a tanúsítványok üres listájával).
• ClientKeyExchange: a tényleges kulcscsere kliens része (pl. a kiszolgáló RSA kulcsával titkosított néhány véletlenszerű érték).
• CertificateVerify: a digitális aláírás az ügyfél által kiszámított összes korábbi kézfogási üzenetre. Ezt az üzenetet akkor küldjük el, amikor a szerver ügyféltanúsítványt kért, és az ügyfél eleget tett. Az ügyfél így bizonyítja a szervernek, hogy valóban “birtokolja” a nyilvános kulcsot, amelyet az elküldött tanúsítvány kódol.

Ezután az ügyfél elküld egy ChangeCipherSpec üzenet, amely nem kézfogás: saját rekordtípusú, ezért saját rekordban küldi el.Tartalma tisztán szimbolikus (az 1. érték egyetlen bájtja). Ez az üzenet azt a pontot jelöli, amikor az ügyfél átvált az újonnan megtárgyalt rejtjelkészletre és kulcsokra. Ezután az ügyfél későbbi rekordjai titkosításra kerülnek.

A Befejezett üzenet egy kriptográfiai ellenőrző összeg kiszámítva az összes korábbi kézfogási üzenet felett (mind az ügyféltől, mind a szervertől). Mivel a ChangeCipherSpec után bocsátják ki, az integritás-ellenőrzés és a titkosítás is lefedi. Amikor a szerver megkapja az üzenetet, és ellenőrzi annak tartalmát, bebizonyítja, hogy valóban végig ugyanazzal az ügyféllel beszélt. Ez az üzenet megvédi a kézfogást a módosításoktól (a támadó nem tudja módosítani a kézfogás üzeneteit, és továbbra is megkapja a Finished üzenetet).

A szerver végül a sajátjával válaszol ChangeCipherSpec majd Finished. Ekkor a kézfogás befejeződik, és az ügyfél és a kiszolgáló kicserélheti az alkalmazás adatait (az ilyenként címkézett titkosított rekordokban).

Ne feledje: az ügyfél javasolja , de a szerver választ . A titkosító csomag a szerver kezében van. Az udvarias kiszolgálóknak állítólag követniük kell az ügyfél preferenciáit (ha lehetséges), de megtehetik másként is, és egyesek valóban (pl. A BEAST elleni védelem részeként).

Rövidített kézfogás

A teljes kézfogás során a szerver “munkamenet-azonosítót” (azaz legfeljebb 32 bájtos csokrot) küld az ügyfélnek. Később az ügyfél visszatérhet és elküldheti ugyanazt a munkamenet-azonosítót a ClientHello részeként. Ez azt jelenti, hogy az ügyfél továbbra is emlékszik a rejtjelkészletre és a kulcsokra az előző kézfogásból, és szeretné újra felhasználni ezeket a paramétereket. Ha a kiszolgáló is emlékszik a rejtjelkészletre és a kulcsokra, akkor az adott munkamenet-azonosítót átmásolja a ServerHello mezőbe, majd követi a rövidített kézfogás :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

A rövidített kézfogás rövidebb: kevesebb üzenet, nem aszimmetrikus rejtjelezési üzlet, és ami a legfontosabb: csökkent késleltetés . A böngészők és a szerverek sokat tesznek. Egy tipikus webböngésző teljes kézfogással nyit meg egy SSL-kapcsolatot, majd rövidített kézfogásokat hajt végre ugyanazon szerver összes többi kapcsolatához: a párhuzamosan megnyíló többi kapcsolathoz, valamint a későbbi kapcsolatokhoz ugyanahhoz a szerverhez. Valójában a tipikus webszerverek 15 másodperc inaktivitás után bezárják a kapcsolatokat, de sokkal hosszabb ideig (esetleg órákig vagy akár napokig) emlékeznek a session ekre (a rejtjelcsomagra és a kulcsokra).

Kulcscsere

Az SSL számos kulcscsere-algoritmust használhat. Ezt a rejtjelkészlet határozza meg; minden kulcscsere algoritmus működik bizonyos típusú szerver nyilvános kulccsal. A leggyakoribb kulcscsere-algoritmusok a következők:

• RSA: A kiszolgáló kulcsa RSA típusú. Az ügyfél véletlenszerű értéket generál (a ” pre-master titok “48 bájtból, ebből 46 véletlenszerű), és a szerver nyilvános kulcsával titkosítja. Nincs ServerKeyExchange.
• DHE_RSA: a kiszolgáló kulcsa RSA típusú, de csak aláírás. A tényleges kulcscsere Diffie-Hellman-t használ. A szerver egy ServerKeyExchange üzenetet küld, amely tartalmazza a DH paramétereket (modulus, generátor) és egy újonnan létrehozott nyilvános DH kulcsot, ráadásul a szerver aláírja ezt az üzenetet. Az ügyfél egy ClientKeyExchange üzenettel válaszol, amely egy újonnan létrehozott nyilvános nyilvános kulcsot is tartalmaz. “.
• DHE_DSS: like DHE_RSA, de a szerver rendelkezik DSS kulccsal (a” DSS “is ismert mint “DSA” ). A DSS csak aláírás-algoritmus.

A ritkábban használt kulcscsere-algoritmusok a következők:

• DH: a szerver kulcsa Diffie-Hellman típusú (beszélünk egy tanúsítványról , amely tartalmaz egy DH gomb). Ez korábban közigazgatásilag “népszerű” volt (az Egyesült Államok szövetségi kormánya előírta használatát), amikor az RSA szabadalom még mindig aktív volt (ez az előző évszázadban volt). A bürokratikus erőfeszítések ellenére soha nem volt olyan széles körben telepítve, mint az RSA.
• DH_anon: mint a DHE lakosztályok, de a szerver aláírása nélkül. Ez tanúsítvány nélküli titkosító csomag. Konstrukciója szerint kiszolgáltatott a Közép-ember támadásoknak , így egyáltalán nagyon ritkán engedélyezett.
• PSK: előre megosztott kulcs titkosítócsomagok. A csak szimmetrikus kulcscsere, előre meghatározott közös titokra építve.
• SRP: a SRP protokoll alkalmazása, amely Jelszóval hitelesített kulcscsere protokoll. A kliens és a szerver hitelesíti egymást egy megosztott titok vonatkozásában, amely lehet alacsony entrópiaú jelszó (míg a PSK nagy entrópiaú megosztott titkot igényel). Nagyon ügyes. Még nem támogatott széles körben.
• Ephemer RSA kulcs: például DHE, de újonnan létrehozott RSA kulcspárral. Mivel az RSA kulcsok előállítása drága, ez nem egy népszerű lehetőség, és csak az “export” titkosító csomagok részeként került megadásra, amelyek megfeleltek a 2000 előtti amerikai rejtjelezési exportszabályoknak (azaz legfeljebb 512 bit RSA kulcsok). Manapság ezt senki sem teszi.
• A DH* algoritmusok változatai elliptikus görbékkel . Nagyon divatos. A nak a jövőben általánossá kell válnia.

Tanúsítványok és hitelesítés

A digitális tanúsítványok az aszimmetrikus kulcsok edényei. A kulcselosztás megoldására szolgálnak. Az ügyfél ugyanis a kiszolgáló nyilvános kulcsát akarja használni. A támadó megpróbálja elérni, hogy az ügyfél használja a támadó s nyilvános kulcsot. Tehát az ügyfélnek meg kell tudnia bizonyosodni arról, hogy a megfelelő kulcsot használja-e.

Az SSL állítólag a X.509 fájlt használja. Ez a tanúsítványok szabványa. Minden tanúsítványt aláír egy tanúsító hatóság . Az ötlet az, hogy a kliens eredendően ismeri egy maroknyi CA nyilvános kulcsait (ezek a “bizalmi horgonyok” vagy a “gyökértanúsítványok”). Ezekkel a kulcsokkal az ügyfél ellenőrizheti a CA által kiszámított aláírást a szervernek kiadott tanúsítványon keresztül. Ez a folyamat rekurzívan meghosszabbítható: a hitelesítésszolgáltató kiadhat egy tanúsítványt egy másik hitelesítésszolgáltató számára (azaz aláírja a tanúsítvány szerkezetét, amely tartalmazza a másik hitelesítésszolgáltató nevét és kulcsát). A tanúsítványlánc gyökér-CA-val kezdődik és a kiszolgáló tanúsítványával végződik, köztük közbenső CA-tanúsítvánnyal, mindegyik tanúsítványt az előző tanúsítványban kódolt nyilvános kulcshoz viszonyítva írják alá, elképzelhetetlenül tanúsítványlánc .

Tehát az ügyfélnek a következőket kell tennie:

• Szerezzen be egy tanúsítványláncot, amely a szerver tanúsítványával végződik. A szerverről érkező Certificate üzenetnek pontosan egy ilyen láncot kell tartalmaznia.
• Validálja a láncot, vagyis ellenőrizze az összes aláírások és nevek, valamint a különféle X.509 bitek. Ezenkívül az ügyfélnek ellenőriznie kell a lánc összes tanúsítványának visszavonási állapotát , amely összetett és nehéz (a webböngészők most ezt csinálják, többé-kevésbé, de egy újabb fejlemény).
• Ellenőrizze, hogy a tervezett kiszolgáló neve valóban be van-e írva a szerver tanúsítványába. Mivel az ügyfél nem csak érvényesített nyilvános kulcsot akar használni, emellett egy adott szerver nyilvános kulcsát is szeretné használni. Lásd az RFC 2818 részleteket arról, hogy ez hogyan történik HTTPS kontextusban. .

Az X.509 tanúsítvánnyal rendelkező tanúsítási modellt gyakran kritizálták, nem igazán technikai okokból, hanem inkább politikai-gazdasági okokból. Néhány játékos kezébe koncentrálja az érvényesítési hatalmat. , akik nem feltétlenül jó szándékúak, vagy legalábbis nem mindig kompetensek . Most és újra más rendszerekre vonatkozó javaslatokat tesznek közzé (pl. Konvergencia vagy

Utána az SSL hosszadalmas bemutatása a előző válaszban , engedjük át a szórakoztató dolgokat, nevezetesen:

Támadások az SSL-re

Sok támadást hajtottak végre az SSL ellen, némelyik a megvalósítási hibákra épült, mások az igazi protokollgyengeségekre.

Nem szabad megfeledkezni arról, hogy bár az SSL az egyik leginkább támadott protokoll (mivel nagyon nagy jelentőségű: az SSL-hez való sikeres alkalmazás egy kutatási cikk absztraktjában nagyon szép nek tűnik), Az SSL egyben a legtöbb javított protokoll is.Pontosan azért tekinthető robusztusnak, mert a szállítási protokollok megtámadásának minden ismert módját kipróbálták az SSL-en, és az SSL-t adott esetben javították.

Verzió visszaállítás

Az SSLv3 kezdeti napjaiban az SSLv2 még mindig széles körben használt volt, és ezért az ügyfelek gyakran SSLv2-kompatibilis >