A biztonság már nem csak egy választható lehetőség, hanem kötelező kurzus minden internetes technológiai szakember számára. HTTP, HTTPS, SSL, TLS - Valóban érted, mi történik a színfalak mögött? Ebben a cikkben laikus és professzionális módon ismertetjük a modern titkosított kommunikációs protokollok alapvető logikáját, és egy vizuális folyamatábrával segítünk megérteni a "zárak mögött" rejlő titkokat.
Miért "nem biztonságos" a HTTP? --- Bevezetés
Emlékszel az ismerős böngészőfigyelmeztetésre?
"A kapcsolatod nem privát."
Miután egy weboldal nem használja a HTTPS-t, a felhasználói adatok egyszerű szövegként kerülnek továbbításra a hálózaton. Egy jól elhelyezett hacker megszerezheti a bejelentkezési jelszavait, bankkártyaszámait és még a privát beszélgetéseit is. Ennek kiváltó oka a HTTP titkosításának hiánya.
Hogyan teszi lehetővé a HTTPS és a mögötte álló „kapuőr”, a TLS az adatok biztonságos áramlását az interneten keresztül? Nézzük meg rétegenként.
HTTPS = HTTP + TLS/SSL --- Szerkezet és alapvető fogalmak
1. Mi is a HTTPS lényege?
HTTPS (HyperText Transfer Protocol Secure) = HTTP + titkosítási réteg (TLS/SSL)
○ HTTP: Ez felelős az adatok átviteléért, de a tartalom sima szövegként látható.
○ TLS/SSL: „Titkosítás zárolását” biztosítja a HTTP kommunikációhoz, így az adatokat egy olyan rejtvénybe fordítja, amelyet csak a jogos küldő és fogadó tud megoldani.
1. ábra: HTTP és HTTPS adatfolyam.
A böngésző címsorában található „lakat” a TLS/SSL biztonsági jelzőt jelöli.
2. Mi a kapcsolat a TLS és az SSL között?
○ SSL (Secure Sockets Layer): A legkorábbi kriptográfiai protokoll, amelyről kiderült, hogy komoly sebezhetőségeket tartalmaz.
○ TLS (Transport Layer Security): Az SSL utódja, a TLS 1.2 és a fejlettebb TLS 1.3, amelyek jelentős biztonsági és teljesítménybeli fejlesztéseket kínálnak.
Manapság az „SSL tanúsítványok” egyszerűen a TLS protokoll implementációi, csak kiterjesztéseknek nevezik őket.
Mélyen a TLS-ben: A HTTPS mögött rejlő kriptográfiai varázslat
1. A kézfogás folyamata teljesen megoldódott
A TLS biztonságos kommunikációjának alapja a beállításkor végrehajtott kézfogás. Nézzük meg a standard TLS kézfogási folyamatot:
2. ábra: Egy tipikus TLS kézfogási folyamat.
1️⃣ TCP kapcsolat beállítása
Egy kliens (pl. egy böngésző) TCP kapcsolatot kezdeményez a szerverrel (szabványos 443-as port).
2️⃣ TLS kézfogási fázis
○ Kliens üdvözlés: A böngésző elküldi a támogatott TLS-verziót, titkosítást és véletlenszámot a kiszolgálónév-jelzéssel (SNI) együtt, amely megmondja a kiszolgálónak, hogy melyik hostname-hez szeretne hozzáférni (lehetővé téve az IP-cím megosztását több webhely között).
○ Szerver üdvözlése és tanúsítványkiadás: A szerver kiválasztja a megfelelő TLS verziót és titkosítást, majd visszaküldi a tanúsítványát (nyilvános kulccsal) és véletlenszerű számokat.
○ Tanúsítványérvényesítés: A böngésző egészen a megbízható legfelső szintű hitelesítésszolgáltatóig ellenőrzi a szerver tanúsítványláncát, hogy megbizonyosodjon arról, hogy az nem hamisított.
○ Premaster kulcs generálása: A böngésző generál egy premaster kulcsot, titkosítja azt a szerver nyilvános kulcsával, és elküldi a szervernek. Két fél tárgyal a munkamenetkulcsról: Mindkét fél véletlenszámainak és a premaster kulcsnak a felhasználásával a kliens és a szerver kiszámítja ugyanazt a szimmetrikus titkosítási munkamenetkulcsot.
○ Kézfogás befejezése: Mindkét fél „Befejezett” üzeneteket küld egymásnak, és belép a titkosított adatátviteli fázisba.
3️⃣ Biztonságos adatátvitel
Minden szolgáltatási adat szimmetrikusan titkosítva van a megbeszélt munkamenetkulccsal, így még ha közben elfogják is, az csak egy csomó "zavaros kód".
4️⃣ Munkamenet újrafelhasználása
A TLS ismét támogatja a munkamenetet, ami jelentősen javíthatja a teljesítményt azáltal, hogy lehetővé teszi ugyanazon kliens számára, hogy kihagyja a fárasztó kézfogást.
Az aszimmetrikus titkosítás (mint például az RSA) biztonságos, de lassú. A szimmetrikus titkosítás gyors, de a kulcskiosztás nehézkes. A TLS egy „kétlépéses” stratégiát alkalmaz – először egy aszimmetrikus, biztonságos kulcscserét, majd egy szimmetrikus sémát az adatok hatékony titkosításához.
2. Algoritmusfejlődés és biztonságfejlesztés
RSA és Diffie-Hellman
○ Dél-afrikai Köztársaság
Először TLS kézfogás során használták széles körben a munkamenetkulcsok biztonságos elosztására. Az ügyfél generál egy munkamenetkulcsot, titkosítja azt a szerver nyilvános kulcsával, és elküldi, hogy csak a szerver tudja visszafejteni.
○ Diffie-Hellman (DH/ECDH)
A TLS 1.3-as verziójától kezdve az RSA-t már nem használják kulcscserére, helyette a biztonságosabb DH/ECDH algoritmusokat használják, amelyek támogatják a továbbított titoktartást (PFS). Még ha a privát kulcs kiszivárog is, a korábbi adatok továbbra sem oldhatók fel.
| TLS-verzió | kulcscsere algoritmus | Biztonság |
| TLS 1.2 | RSA/DH/ECDH | Magasabb |
| TLS 1.3 | csak DH/ECDH számára | Magasabb |
Gyakorlati tanácsok, amelyeket a hálózatépítő szakembereknek el kell sajátítaniuk
○ Elsőbbségi frissítés TLS 1.3-ra a gyorsabb és biztonságosabb titkosítás érdekében.
○ Engedélyezze az erős titkosításokat (AES-GCM, ChaCha20 stb.), és tiltsa le a gyenge algoritmusokat és a nem biztonságos protokollokat (SSLv3, TLS 1.0);
○ Konfigurálja a HSTS-t, az OCSP tűzést stb. az általános HTTPS-védelem javítása érdekében;
○ Rendszeresen frissítse és vizsgálja felül a tanúsítványláncot a bizalmi lánc érvényességének és integritásának biztosítása érdekében.
Konklúzió és gondolatok: Valóban biztonságos a vállalkozása?
A sima szöveges HTTP-től a teljesen titkosított HTTPS-ig a biztonsági követelmények minden protokollfrissítéssel együtt fejlődtek. A modern hálózatokban a titkosított kommunikáció sarokköveként a TLS folyamatosan fejleszti magát, hogy megbirkózzon az egyre összetettebb támadási környezettel.
Már használ a vállalkozása HTTPS-t? A kriptokonfigurációja összhangban van az iparági legjobb gyakorlatokkal?
Közzététel ideje: 2025. július 22.
