SSL/TLS — mi ez, protokollok és a titkosítás működési elve

Mi az SSL/TLS?

SSL (Secure Sockets Layer) — a Netscape által 1995-ben kifejlesztett protokoll a webes forgalom védelmére. Az SSL 1.0 első verziója soha nem jelent meg, az SSL 2.0 (1995) és SSL 3.0 (1996) a 2000-es évek elejéig használatban volt, de kritikus biztonsági réseket tartalmaztak. Az SSL helyébe a TLS (Transport Layer Security) lépett — egy továbbfejlesztett verzió, amelyet az IETF szabványosított. A TLS 1.0 (1999) az SSL 3.0-ra épült, a későbbi verziók (TLS 1.1 (2006), TLS 1.2 (2008) és TLS 1.3 (2018)) fokozatosan eltávolodtak az eredeti architektúrától, új titkosítási algoritmusokat adva hozzá és kiküszöbölve a biztonsági réseket. Ma az SSL elavultnak számít, és minden modern rendszer TLS-t használ, bár a megszokás miatt mindkét protokollt gyakran együtt említik SSL/TLSként.

A protokoll létrejöttének története

Az SSL/TLS története a biztonságos adatátvitel iránti igénnyel kezdődött a korai weben. 1994-ben a Netscape kifejlesztette az SSL 1.0-t a Navigator böngészőjéhez, de a protokoll súlyos biztonsági problémák miatt soha nem jelent meg. Az SSL 2.0 1995-ben jelent meg és gyakorlatban is használták, de számos sebezhetőséget tartalmazott: nem védett a Man-in-the-Middle támadások ellen, gyenge titkosítási algoritmusokat használt, és sebezhető volt a truncation támadásokkal szemben. Az SSL 3.0 (1996) a legtöbb problémát kijavította, de 2014-re felfedezték benne a POODLE sebezhetőséget, ami után az IETF hivatalosan is elavulttá nyilvánította az SSL összes verzióját. A TLS 1.0–1.3 egymást követően javították a kriptográfiai erősséget, teljesítményt és titkosságot, a TLS 1.3 pedig a handshake-et két round-trip-ről egyre csökkentette, ami kritikus fontosságú a bizonytalan kapcsolattal rendelkező mobilalkalmazások számára.

Hogyan működik az SSL/TLS Handshake

Handshake — a biztonságos kapcsolat létrehozásának folyamata a kliens és a szerver között. Több egymást követő lépésből áll, amelyek során a felek egyeztetik a protokoll verzióját, kiválasztják a titkosítási algoritmusokat, kulcsokat cserélnek és hitelesítik egymást. A TLS 1.3-ban a handshake csak egy hálózati interakciót (1-RTT) igényel, míg a TLS 1.2-ben kettőt (2-RTT).

Első lépésként a kliens ClientHello üzenetet küld — amely tartalmazza a támogatott TLS-verziók listáját, a cipher suite-okat és egy véletlenszámot. A szerver ServerHello-val válaszol a kiválasztott verzióval és titkosítóval, saját X.509 tanúsítványával és digitális aláírásával. A kliens ellenőrzi a tanúsítványt a hitelesítésszolgáltatók (CA) láncán keresztül, létrehoz egy munkamenet-kulcsot, és elküldi azt a szerver tanúsítványában lévő nyilvános kulccsal titkosítva. A szerver megerősítése után megkezdődik a biztonságos adatátvitel. A teljes handshake 1–3 ezredmásodperc alatt végbemegy a modern eszközökön, ami láthatatlanná teszi a felhasználó számára.

X.509 tanúsítványok és a bizalmi lánc

A TLS-hitelesítés alapja a nyilvános kulcsú infrastruktúra (PKI), amely X.509 formátumú tanúsítványokra épül. Minden tanúsítvány tartalmazza: a domain nevet (Common Name vagy Subject Alternative Name), a szerver nyilvános kulcsát, a kibocsátó nevét (Certificate Authority), az érvényességi időtartamot és a CA digitális aláírását. A kliens ellenőrzi a szerver tanúsítványát a bizalmi láncon keresztül: a szerver tanúsítványától a gyökér CA-ig, amelynek tanúsítványa be van építve az operációs rendszerbe. Android-eszközökön a gyökér tanúsítványok a rendszertárban tárolódnak, amely a Google Play Services-en keresztül frissül; iOS-ben — az iOS Updates-en keresztül. A lánc bármely szakaszának megsértése esetén (lejárt tanúsítvány, domain eltérés, ismeretlen CA) a kliens megszakítja a kapcsolatot. Az önaláírt tanúsítványokhoz (amelyeket fejlesztés során használnak) kifejezett bizalom szükséges — Androidban a Network Security Config-on keresztül, iOS-ben az Info.plist-ben lévő NSExceptionDomains-en keresztül. A tanúsítványlánc érvényesítési folyamata magában foglalja a visszavonási állapot ellenőrzését is CRL (Certificate Revocation List) vagy OCSP (Online Certificate Status Protocol) segítségével, bár mobileszközökön az OCSP-kéréseket gyakran kihagyják a kapcsolat gyorsítása érdekében — ez egy kompromisszum a biztonság és a teljesítmény között, amelyet az építészeknek figyelembe kell venniük.

SSL vs TLS: főbb különbségek

Bár az SSL és TLS kifejezéseket gyakran szinonimaként használják, alapvető technikai különbségek vannak közöttük, amelyek befolyásolják a mobilalkalmazások biztonságát és teljesítményét.

A TLS 1.3 fő különbsége elődeihez képest — a Perfect Forward Secrecy (PFS) kötelező használata az ECDHE protokollon keresztül. Ez azt jelenti, hogy még ha egy támadó hozzá is fér a szerver privát kulcsához, nem tudja visszafejteni a korábban elfogott forgalmat. Azoknál a mobilalkalmazásoknál, ahol a szerver feltörése valós fenyegetés, a TLS 1.3 PFS-sel kötelező biztonsági követelmény.

Az régebbi verziók ismert sebezhetőségei

Az SSL és TLS elavult verziói dokumentált sebezhetőségekkel rendelkeznek, amelyek alkalmatlanná teszik őket éles használatra. A POODLE (CVE-2014-3566) az SSL 3.0-t támadja padding oracle-en keresztül, lehetővé téve a munkamenet cookie visszafejtését 256 kérés alatt. A BEAST (CVE-2011-3389) a TLS 1.0 sebezhetőségét használja ki CBC módban kiszámítható IV-n keresztül. A Heartbleed (CVE-2014-0160) — nem protokoll sebezhetőség, hanem hiba az OpenSSL implementációjában, amely lehetővé teszi a szerver memóriájának olvasását: a Netcraft szerint 2014-ben több mint 500 ezer szerver volt sebezhető. Az Android 10 (API 29) és iOS 13 óta az összes említett protokoll rendszerszinten le van tiltva. Ennek ellenére a fejlesztőknek ellenőrizniük kell a szerver konfigurációját az SSL Labs Test (qualys.com) segítségével az alkalmazás elindítása előtt, hogy megbizonyosodjanak arról, hogy nincsenek elavult cipher suite-ok, és a TLS 1.3 támogatott.

Hogyan védi az SSL/TLS az adatokat mobilalkalmazásokban

A mobilalkalmazásokban a TLS három szinten védi az adatokat: a tartalom titkosítása (senki sem olvashatja az adatokat a szerveren kívül), az integritás ellenőrzése (az adatok nem módosíthatók útközben) és a szerver hitelesítése (a kliens biztos abban, hogy a megfelelő szerverhez csatlakozik). A hitelesítés különösen kritikus: enélkül a támadó DNS-spoofing vagy hamis Wi-Fi hozzáférési pont segítségével helyettesítheti a szervert.

A Google Play Protect (2024) kutatása szerint az Android-alkalmazások 76%-a helyesen használja a TLS-t tanúsítvány-ellenőrzéssel. A fennmaradó 24% hibákat követ el: kikapcsolja a tanúsítvány-ellenőrzést teszteléshez (és elfelejti bekapcsolni élesben), önaláírt tanúsítványokat használ érvényesítés nélkül, vagy engedélyezi az elavult SSL 3.0 és TLS 1.0 protokollokat. Az Apple App Transport Security (ATS) iOS-ben 2017 óta legalább TLS 1.2-t ír elő, és iOS 15-től kezdve alapértelmezetten TLS 1.3-at használ minden hálózati kéréshez. További védelemként a Certificate Pinning — a szerver konkrét tanúsítványához való rögzítés — implementálása is ajánlott.

SSL/TLS implementálása mobilalkalmazásokban

Nézzünk egy példát a biztonságos HTTPS-kapcsolat beállítására Android rendszeren az OkHttp — az egyik legnépszerűbb hálózati könyvtár — használatával. A helyes konfiguráció magában foglalja a TLS 1.3 kötelező használatát és a tanúsítványok ellenőrzését.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

Ebben a példában a támogatott TLS verziók körét csak az 1.3 és 1.2 protokollokra korlátozzuk, kizárva az elavult TLS 1.0/1.1-et. A cipher suite-ok a modern algoritmusokból kerülnek kiválasztásra AEAD móddal és kötelező Perfect Forward Secrecy-vel. A HostnameVerifier ellenőrzi a gazdagépnév és a tanúsítvány egyezését. iOS esetében hasonló beállítás történik az URLSession konfigurációján keresztül a tlsMinimumSupportedProtocolVersion paraméterrel, ahol a .TLSv13 van megadva. Ezenkívül iOS-ben beállítható a tlsMaximumSupportedProtocolVersion a verziók felső határának korlátozására — ez hasznos a régebbi szerverekkel való kompatibilitáshoz, amelyek még nem váltottak TLS 1.3-ra. Egy ilyen konfiguráció garantálja a maximális biztonsági szintet az adatok mobilalkalmazásban történő továbbítása során.