Robert Heaton

A HTTPS egyszerűen a szokásos HTTP protokoll egy bőséges réteg finom SSL/TLS titkosítási jósággal megspékelve. Hacsak valami nem megy borzalmasan rosszul (és ez megtörténhet), megakadályozza, hogy olyan emberek, mint a hírhedt Eve, megnézzék vagy módosítsák a kéréseket, amelyek a böngészési élményt alkotják; ez az, ami biztonságban tartja a jelszavakat, kommunikációs és hitelkártyaadatokat a számítógéped és a szerverek között, amelyeknek ezeket az adatokat el akarod küldeni. Bár a kis zöld lakat és a “https” betűk a címsorában nem jelentik azt, hogy nincs még bőven kötél arra, hogy mind Ön, mind az Ön által megtekintett webhely máshol akassza fel magát, de legalább segítenek abban, hogy biztonságosan kommunikáljon, miközben ezt teszi.

Mi a HTTPS és mit csinál?

A HTTPS a jól ismert és ismert HTTP protokollt veszi alapul, és egyszerűen egy SSL/TLS (a továbbiakban egyszerűen “SSL”) titkosítási réteget helyez rá. A kiszolgálók és az ügyfelek továbbra is pontosan ugyanazt a HTTP-t beszélik egymással, de egy biztonságos SSL-kapcsolaton keresztül, amely titkosítja és visszafejti a kéréseiket és válaszaikat. Az SSL rétegnek 2 fő célja van:

• Egyértelművé teszi, hogy közvetlenül azzal a szerverrel beszélsz, akivel azt hiszed, hogy beszélsz
• biztosítja, hogy csak a szerver tudja elolvasni, amit küldesz neki, és csak te tudod elolvasni, amit visszaküld

Az igazán, igazán okos része az, hogy bárki lehallgathat minden egyes üzenetet, amit egy szerverrel váltasz, beleértve azokat is, amelyekben megállapodtok a kulcs és a titkosítási stratégia használatáról, és mégsem tudod elolvasni a tényleges adatokat, amelyeket küldesz.

Hogyan jön létre az SSL-kapcsolat

A kliens és a kiszolgáló közötti SSL-kapcsolat egy kézfogással jön létre, amelynek céljai a következők:

• A kliens meggyőződjön arról, hogy a megfelelő szerverrel beszél (és opcionálisan fordítva)
• A felek megállapodjanak egy “titkosítási csomagban”, amely tartalmazza, hogy milyen titkosítási algoritmust fognak használni az adatcseréhez
• A felek megállapodnak az algoritmushoz szükséges kulcsokról

A kapcsolat létrehozása után mindkét fél használhatja az elfogadott algoritmust és kulcsokat, hogy biztonságosan küldjenek üzeneteket egymásnak. A kézfogást 3 fő fázisra bontjuk: Hello, tanúsítványcsere és kulcscsere.

1. Hello – A kézfogás azzal kezdődik, hogy az ügyfél elküldi a ClientHello üzenetet. Ez tartalmazza az összes olyan információt, amelyre a kiszolgálónak szüksége van ahhoz, hogy SSL-en keresztül csatlakozhasson az ügyfélhez, beleértve a különböző titkosítókészleteket és az általa támogatott maximális SSL-verziót. A kiszolgáló egy ServerHello üzenettel válaszol, amely az ügyfél által igényelt hasonló információkat tartalmazza, beleértve az ügyfél preferenciáin alapuló döntést arról, hogy melyik titkosítási csomagot és az SSL melyik verzióját fogja használni.

2. Tanúsítványcsere – Most, hogy a kapcsolatfelvétel megtörtént, a kiszolgálónak bizonyítania kell a személyazonosságát az ügyfélnek. Ezt az SSL-tanúsítványával éri el, ami egy nagyon aprócska kicsit olyan, mint az útlevél. Az SSL-tanúsítvány különböző adatokat tartalmaz, többek között a tulajdonos nevét, a hozzá tartozó tulajdont (pl. domain), a tanúsítvány nyilvános kulcsát, a digitális aláírást és a tanúsítvány érvényességi idejére vonatkozó információkat. Az ügyfél ellenőrzi, hogy vagy hallgatólagosan megbízik-e a tanúsítványban, vagy a tanúsítványt több olyan tanúsítványhivatal (CA) egyike ellenőrzi és bízik benne, amelyben szintén hallgatólagosan megbízik. Erről rövidesen bővebben. Megjegyzendő, hogy a kiszolgáló is kérhet tanúsítványt az ügyfél személyazonosságának igazolására, de ez jellemzően csak nagyon érzékeny alkalmazásokban fordul elő.

3. Kulcscsere – Az ügyfél és a kiszolgáló által kicserélt tényleges üzenetadatok titkosítása egy szimmetrikus algoritmus segítségével történik, amelynek pontos jellegéről már a Hello fázisban megállapodtunk. A szimmetrikus algoritmus egyetlen kulcsot használ mind a titkosításhoz, mind a visszafejtéshez, ellentétben az aszimmetrikus algoritmusokkal, amelyek nyilvános/magán kulcspárt igényelnek. Mindkét félnek meg kell állapodnia erről az egyetlen szimmetrikus kulcsról, amely folyamatot biztonságosan az aszimmetrikus titkosítás és a kiszolgáló nyilvános/magán kulcsainak használatával valósítjuk meg.

A kliens generál egy véletlenszerű kulcsot, amelyet a fő szimmetrikus algoritmushoz használunk. Ezt titkosítja a Hello fázisban szintén elfogadott algoritmussal és a kiszolgáló nyilvános kulcsával (amely az SSL-tanúsítványán található). Ezt a titkosított kulcsot elküldi a kiszolgálónak, ahol a kiszolgáló privát kulcsával visszafejti, és a kézfogás érdekes részei befejeződnek. A felek kellőképpen elégedettek azzal, hogy a megfelelő személlyel beszélnek, és titokban megállapodtak egy kulcsban, amellyel szimmetrikusan titkosítják az egymásnak küldendő adatokat. A HTTP-kérelmek és -válaszok most már elküldhetők egy egyszerű szöveges üzenet létrehozásával, majd titkosításával és elküldésével. Ezt az üzenetet csak a másik fél tudja visszafejteni, így a Man In The Middle támadók nem tudják elolvasni vagy módosítani a lehallgatott kéréseket.

Tanúsítványok

A legalapvetőbb szinten az SSL-tanúsítvány egyszerűen egy szöveges fájl, és bárki, akinek van egy szövegszerkesztője, létrehozhat egyet. Valójában triviálisan létrehozhat egy olyan tanúsítványt, amely azt állítja, hogy Ön a Google Inc. és a gmail.com domain felett rendelkezik. Ha ez lenne az egész történet, akkor az SSL egy vicc lenne; a személyazonosság ellenőrzése lényegében abból állna, hogy az ügyfél megkérdezi a kiszolgálót: “Te vagy a Google?”, a kiszolgáló válaszol: “Ööö, igen, persze, itt van egy darab papír, amire rá van írva, hogy “Én vagyok a Google”, az ügyfél pedig azt mondja: “OK, remek, itt van az összes adatom”. A varázslat, amely megakadályozza ezt a bohózatot, a digitális aláírás, amely lehetővé teszi az egyik fél számára, hogy ellenőrizze, hogy a másik fél papírja valóban legális.

2 ésszerű oka van annak, hogy miért bízhatunk meg egy tanúsítványban:

• Ha szerepel egy olyan tanúsítványok listáján, amelyekben hallgatólagosan megbízunk
• Ha képes bizonyítani, hogy a fenti listán szereplő tanúsítványok valamelyikének kezelője megbízik benne

Az első kritérium könnyen ellenőrizhető. A böngészője rendelkezik egy előre telepített listával a tanúsítványhatóságok (CA-k) megbízható SSL-tanúsítványairól, amelyet megtekinthet, hozzáadhat és eltávolíthat belőle. Ezeket a tanúsítványokat (elméletben és általában a gyakorlatban is) rendkívül biztonságos, megbízható és megbízható szervezetek, például a Symantec, a Comodo és a GoDaddy központosított csoportja ellenőrzi. Ha egy szerver bemutat egy tanúsítványt ebből a listából, akkor tudja, hogy megbízhat benne.

A második kritérium sokkal nehezebb. Könnyű egy szerver számára azt mondani, hogy “ööö igen, a nevem ööö, Microsoft, megbízol a Symantecben és ööö, ők teljesen megbíznak bennem, szóval minden rendben van”. Egy valamennyire okos ügyfél ezután odamehet és megkérdezheti a Symantecet, hogy “van itt egy Microsoft, aki azt mondja, hogy megbízol bennük, ez igaz?”. De még ha a Symantec azt mondja is, hogy “igen, ismerjük őket, a Microsoft legális”, akkor sem tudhatja, hogy a magát Microsoftnak kiadó szerver valóban Microsoft-e, vagy valami sokkal rosszabb. Itt jönnek a képbe a digitális aláírások.

3.2 Digitális aláírások

Amint már említettük, az SSL tanúsítványokhoz nyilvános/magán kulcspár tartozik. A nyilvános kulcsot a tanúsítvány részeként terjesztik, a magánkulcsot pedig hihetetlenül biztonságosan őrzik. Ezt az aszimmetrikus kulcspárt az SSL kézfogás során egy további kulcs cseréjére használják mindkét fél számára az adatok szimmetrikus titkosításához és visszafejtéséhez. Az ügyfél a kiszolgáló nyilvános kulcsát használja a szimmetrikus kulcs titkosítására és biztonságos elküldésére a kiszolgálónak, a kiszolgáló pedig a magánkulcsát használja a dekódoláshoz. A nyilvános kulccsal bárki titkosíthat, de a magánkulccsal csak a kiszolgáló dekódolhat.

A digitális aláírás esetében ennek az ellenkezője igaz. Egy tanúsítványt egy másik hatóság is “aláírhat”, ilyenkor a hatóság gyakorlatilag azt mondja, hogy “ellenőriztük, hogy ennek a tanúsítványnak az irányítója a tanúsítványban felsorolt ingatlant (tartományt) is irányítja”. Ebben az esetben a hatóság a saját magánkulcsával (nagyjából) titkosítja a tanúsítvány tartalmát, és ezt a titkosított szöveget digitális aláírásként csatolja a tanúsítványhoz. Ezt az aláírást bárki visszafejtheti a hatóság nyilvános kulcsával, és ellenőrizheti, hogy az eredmény a várt visszafejtett érték. De csak a hatóság képes titkosítani a tartalmat a magánkulccsal, és így csak a hatóság képes egyáltalán érvényes aláírást létrehozni.

Ha tehát jön egy kiszolgáló, amely azt állítja, hogy a Microsoft.com tanúsítványa a Symantec (vagy más hitelesítésszolgáltató) által aláírt, a böngészőnek nem kell hinnie a szavának. Ha ez legális, akkor a Symantec a saját (ultra-titkos) magánkulcsát használta a kiszolgáló SSL-tanúsítványának digitális aláírásának létrehozásához, és így a böngésző a saját (ultra-nyilvános) nyilvános kulcsát használhatja az aláírás érvényességének ellenőrzésére. A Symantec lépéseket tett annak biztosítására, hogy az általa aláírt szervezet valóban a Microsoft.com tulajdonosa legyen, és mivel az ügyfél megbízik a Symantecben, biztos lehet benne, hogy valóban a Microsoft Inc.-hez beszél.

3.3 Önaláírás

Megjegyzendő, hogy minden root CA tanúsítvány “önaláírt”, ami azt jelenti, hogy a digitális aláírás a tanúsítvány saját magánkulcsának felhasználásával készül. A gyökér CA tanúsítványában önmagában nincs semmi különleges – ha akarod, létrehozhatod a saját önaláírt tanúsítványodat, és ezt használhatod más tanúsítványok aláírására. De mivel a véletlenszerű tanúsítványa nincs előre betöltve hitelesítésszolgáltatóként egyetlen böngészőbe sem sehol, egyikük sem fog megbízni sem a saját, sem más tanúsítványok aláírásában. Ezzel gyakorlatilag azt mondod, hogy “igen, én vagyok a Microsoft, itt van egy általam kiállított és aláírt hivatalos személyazonossági tanúsítvány”, és minden megfelelően működő böngésző egy nagyon ijesztő hibaüzenetet dob ki válaszul a kétes hitelesítő adatokra.

Ez óriási terhet ró minden böngésző és operációs rendszer kiadójára, hogy csak a makulátlanul tiszta root CA-kban bízzon, mivel ezek azok a szervezetek, amelyekben a felhasználók végül megbíznak a weboldalak ellenőrzésében és a tanúsítványok biztonságában. Ez nem könnyű feladat.

3.4 Miben bízik?

Érdekes megjegyezni, hogy az ügyfél technikailag nem azt próbálja ellenőrizni, hogy bízzon-e a tanúsítványt küldő félben, hanem azt, hogy bízzon-e a tanúsítványban szereplő nyilvános kulcsban. Az SSL-tanúsítványok teljesen nyíltak és nyilvánosak, így bármely támadó megszerezheti a Microsoft tanúsítványát, elfoghatja az ügyfél Microsoft.com-hoz intézett kérését, és bemutathatja neki a legitim tanúsítványt. Az ügyfél ezt elfogadná, és boldogan megkezdené a kézfogást. Amikor azonban az ügyfél titkosítja a tényleges adattitkosításhoz használt kulcsot, akkor a valódi Microsoft nyilvános kulcsát használja ehhez a valódi tanúsítványból. Mivel a támadó nem rendelkezik a Microsoft privát kulcsával a visszafejtéshez, ezért most elakadt. Még ha a kézfogás be is fejeződik, akkor sem lesz képes visszafejteni a kulcsot, és így az ügyfél által küldött adatokat sem fogja tudni visszafejteni. A rend mindaddig fennmarad, amíg a támadó nem ellenőrzi a megbízható tanúsítvány magánkulcsát. Ha az ügyfelet valahogy ráveszik, hogy megbízzon egy olyan tanúsítványban és nyilvános kulcsban, amelynek magánkulcsa a támadó ellenőrzése alatt áll, akkor kezdődnek a bajok.

4.1 Egy kávézó megfigyelheti a HTTPS-forgalmamat a hálózatán keresztül?

Nem. A nyilvános kulcsú kriptográfia varázsa azt jelenti, hogy egy támadó az ügyfél és a kiszolgáló között kicserélt adatok minden egyes bájtját megfigyelheti, és még mindig fogalma sincs arról, hogy mit mondtok egymásnak azon túl, hogy nagyjából mennyi adatot cseréltek. A normál HTTP-forgalom azonban még mindig nagyon sebezhető egy nem biztonságos wi-fi hálózaton, és egy gyengébb weboldal is áldozatul eshet számos olyan megoldásnak, amely valahogy becsapja Önt, hogy HTTPS-forgalmat küldjön a sima HTTP-n keresztül, vagy csak teljesen rossz helyre. Például, még ha egy bejelentkezési űrlap HTTPS-en keresztül küld is be egy felhasználónév/jelszó kombinációt, ha maga az űrlap nem biztonságos HTTP-n keresztül töltődik be, akkor egy támadó elfoghatja az űrlap HTML-jét az Ön gépére vezető úton, és módosíthatja azt, hogy a bejelentkezési adatokat a saját végpontjára küldje.

4.2 A cégem figyelemmel kísérheti a HTTPS-forgalmat a hálózatán keresztül?

Ha Ön is a cége által ellenőrzött gépet használ, akkor igen. Ne feledje, hogy minden bizalmi lánc gyökerénél egy hallgatólagosan megbízható hitelesítésszolgáltató áll, és ezeknek a hatóságoknak a listáját a böngészője tárolja. A cége felhasználhatja a gépéhez való hozzáférését arra, hogy a saját maga által aláírt tanúsítványát hozzáadja ehhez a hitelesítésszolgáltatók listájához. Ezután elfoghatják az összes HTTPS-kérelmét, és olyan tanúsítványokat mutathatnak be, amelyek azt állítják, hogy a megfelelő weboldalt képviselik, amelyeket a hamis hitelesítésszolgáltatójuk írt alá, és ezért az Ön böngészője megkérdőjelezhetetlenül megbízik bennük. Mivel Ön minden HTTPS-kérését az ő hamis tanúsítványuk nyilvános kulcsával titkosítaná, a megfelelő magánkulccsal visszafejthetnék és megvizsgálhatnák (sőt módosíthatnák) a kérését, majd továbbküldhetnék azt a kívánt helyre. Valószínűleg nem teszik. De megtehetik.

Mellesleg egy iPhone-alkalmazás által küldött, egyébként hozzáférhetetlen HTTPS-kérelmeket is így lehet proxy segítségével ellenőrizni és módosítani.

4.3 Mi történt tehát a Lavabit és az FBI között?

A Lavabit volt Edward Snowden szuperbiztonságos e-mail szolgáltatója a 2013-as NSA-szivárogtatási őrület idején. Mint láttuk, semmilyen szabványos hackelés nem tette lehetővé, hogy az FBI betekintést nyerjen a Lavabit és az ügyfelei között úton lévő adatokba. A Lavabit SSL-tanúsítvány privát kulcsa nélkül az ügynökségnek cseszhette a dolgot. Egy segítőkész amerikai bíró azonban közölte a Lavabit alapítójával, Ladar Levisonnal, hogy át kell adnia ezt a kulcsot, így az FBI gyakorlatilag szabad kezet kapott, hogy kedvére szaglásszon a forgalomban. Levison hősies kísérletet tett az időhúzásra azzal, hogy átadta a 2560 karakteres kulcsot 11 nyomtatott, 4 pontos betűkkel írt oldalon, de egy olyan végzéssel sújtották, amely előírta, hogy a kulcsot használható formátumban kell átadnia, vagy 5000 dollár/nap bírsággal kell szembenéznie, amíg ezt meg nem teszi.

Mihelyt eleget tett, a GoDaddy, a Lavabit hitelesítésszolgáltatója visszavonta a tanúsítványt, mivel (helyesen) veszélyeztetettnek ítélte azt. Ezáltal a Lavabit-tanúsítvány felkerült a Certificate Revocation List (CRL) listára, amely azon hiteltelenített tanúsítványok listája, amelyekben az ügyfelek már nem bízhatnak a biztonságos kapcsolat biztosításában. A kompromittált, saját aláírású vagy más módon megbízhatatlan tanúsítványok hatására a böngészők egy nagy piros hibaüzenetet jelenítenek meg, és vagy elriasztják, vagy egyenesen megtiltják a felhasználó további műveleteit. Sajnos a böngészők mindaddig bíznak a hibás tanúsítványban, amíg ki nem húzzák a CRL legújabb frissítéseit, ami a gyakorlatban nyilvánvalóan nem tökéletes folyamat.

Következtetés

AHTTPS nem feltörhetetlen, és az SSL protokollnak folyamatosan fejlődnie kell az ellene irányuló új támadások felfedezésével és elfojtásával. De még mindig lenyűgözően robusztus módja a titkos adatok továbbításának anélkül, hogy érdekelné, ki látja az üzeneteket. Természetesen számos, itt nem említett végrehajtási részlet van, mint például a kézfogási üzenetek pontos formátuma és sorrendje, a rövidített kézfogások, amelyekkel a legutóbbi munkameneteket lehet felvenni anélkül, hogy újra kellene tárgyalni a kulcsokat és a titkosítási készleteket, valamint az egyes szakaszokban rendelkezésre álló számos különböző titkosítási lehetőség. A legfontosabb dolog, amit nem szabad elfelejteni, hogy bár a HTTPS biztonságban tartja az adatokat a vezeték útján a célállomásig, semmiképpen sem védi Önt (mint felhasználót vagy fejlesztőt) az XSS, az adatbázis-szivárgás vagy bármely más dolog ellen, ami az éjszakában történik. Örüljön, hogy ez a megoldás védi a hátát, de maradjon éber. Will Smith halhatatlan szavaival élve: “Walk in shadow, move in silence, guard against extra-terrestrial violence.”

Ha ez tetszett, akkor valószínűleg élvezni fogod a 2015-ös FREAK SSL sebezhetőség részleteit bemutató bejegyzésemet.