SSL/TLS: kulcsfogalmak és protokollok a programozásban

Mi az SSL/TLS?

SSL (Secure Sockets Layer) és TLS (Transport Layer Security) — kriptográfiai protokollok, amelyek biztonságos adatátvitelt garantálnak a hálózaton keresztül. Az SSL-t, amelyet a Netscape fejlesztett ki az 1990-es években, a 3.0-s verzió után elavultnak nyilvánították a POODLE és BEAST sérülékenységek miatt. A TLS, az utódja, az 1.0, 1.1, 1.2 és 1.3 verziókon ment keresztül — jelenleg csak a TLS 1.2 és TLS 1.3 számít aktuálisnak. Minden modern mobilplatform megköveteli a TLS használatát a hálózati kapcsolatokhoz, és az App Store és a Google Play ezt az ellenőrzési szakaszban vizsgálja.

Miért van szükség TLS-re a mobilalkalmazásoknak

TLS nélkül az alkalmazás és a szerver közötti forgalom egyszerű szövegként kerül továbbításra — bárki ugyanazon a Wi-Fi hálózaton elfoghatja a felhasználóneveket, jelszavakat, tokeneket és személyes adatokat a Wireshark vagy tcpdump segítségével. A TLS titkosítja az összes továbbított adatot (transzport szintű titkosítás), és ellenőrzi a szerver hitelességét az X.509 tanúsítványláncon keresztül. A IETF (2018) adatai szerint a TLS 1.3 csak modern AEAD titkosításokat (AES-GCM, ChaCha20-Poly1305) használ, kizárva az olyan elavult algoritmusokat, mint az RC4 és a 3DES.

HTTPS és TLS

A HTTPS (HTTP Secure) — a HTTP TLS felett. Amikor egy mobilalkalmazás https://-n keresztül küld kérést, először TLS-kapcsolatot létesít a szerverrel, majd a HTTP-fejléceket és a kérés törzsét a titkosított csatornán keresztül továbbítja. HTTPS nélkül egyetlen komoly API-nak sem szabadna működnie — ez az alapvető biztonsági higiénia. A OWASP (2026) adatai szerint a nem biztonságos kapcsolatok a mobilalkalmazások top 3 sérülékenysége közé tartoznak.

Hogyan működik a TLS kézfogás

TLS kézfogás — a biztonságos kapcsolat létrehozásának folyamata a kliens és a szerver között. A felek egyeztetik a protokoll verzióját, kiválasztják a titkosítási csomagot (cipher suite), aszimmetrikus kriptográfián keresztül kulcsokat cserélnek, és ellenőrzik a tanúsítványokat. TLS 1.2-ben a kézfogás 2 Round Trip Time-ot (2 RTT) igényel: kliens → szerver ClientHello-val, szerver → kliens ServerHello-val és Certificate-tel, majd a Finished üzenetekkel. A TLS 1.3 ezt a folyamatot 1 RTT-re csökkenti.

A TLS 1.2 kézfogás részletes szakaszai

Első szakasz: ClientHello — a kliens elküldi a támogatott TLS-verziókat, a titkosítási csomagok listáját és egy véletlenszámot. A szerver ServerHello-val válaszol, kiválasztja a verziót és a titkosítási csomagot, elküldi az X.509 tanúsítványát (Certificate) és a ServerHelloDone üzenetet. A kliens ellenőrzi a tanúsítványt a megbízható hitelesítésszolgáltatók (CA) láncán keresztül, létrehozza a pre-master secretet, titkosítja a tanúsítványban lévő nyilvános kulccsal, és elküldi a szervernek a ClientKeyExchange-ben. Ezt követően mindkét fél létrehozza a munkamenet-kulcsokat, és kicseréli a ChangeCipherSpec és Finished üzeneteket. Ettől a pillanattól kezdve minden adat szimmetrikusan titkosított.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Példa a URLAuthenticationChallenge kezelésére iOS-en a URLSessionDelegate-en keresztül. Ez a metódus minden TLS kézfogásnál meghívódik, lehetővé téve az alkalmazás számára a szervertanúsítvány egyedi ellenőrzését. Éles használathoz adja hozzá a tanúsítvány ellenőrzését a SecTrustEvaluateWithError segítségével, és hasonlítsa össze az előre elmentett ujjlenyomattal — csak ezután hívja meg a useCredential-t.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — a protokoll első nagy frissítése 10 év alatt. Főbb fejlesztések: a kézfogás 1 RTT-re csökkentve (0 RTT újracsatlakozásokhoz), elavult titkosítási csomagok (RSA key exchange, CBC-mode) eltávolítva, kötelező forward secrecy (PFS) és védelem downgrade-támadások ellen signed transcript segítségével. A Qualys SSL Labs (2026) adatai szerint a TLS 1.3 a PFS-nek köszönhetően még a hosszú távú szerver kulcs kompromittálódása esetén is védelmet nyújt.

0-RTT (Zero Round Trip Time) — a TLS 1.3 funkciója, amely lehetővé teszi a kliens számára, hogy újracsatlakozáskor a PSK (Pre-Shared Key) segítségével azonnal a ClientHello-val együtt küldjön adatokat. Ez felgyorsítja a következő képernyők betöltését a mobilalkalmazásokban, különösen gyakori, ugyanazon szerverhez intézett kérések esetén. A 0-RTT adatok azonban nem védettek a replay-támadások ellen — elfoghatók és újraküldhetők. A 0-RTT-t csak idempotens kérésekhez (GET, PUT) használja mellékhatások nélkül.

TLS iOS-en: App Transport Security

App Transport Security (ATS) — Apple mechanizmus, amely TLS 1.2 vagy magasabb HTTPS-kapcsolatokat követel meg, alapértelmezetten engedélyezve iOS 9-től. Az ATS blokkolja az összes HTTP-kapcsolatot és a TLS 1.2 alatti HTTPS-t. A fejlesztő az Info.plist-ben a NSAppTransportSecurity segítségével konfigurálhat kivételeket meghatározott domainekhez, de az Apple ajánlja a kivételek minimalizálását és a HTTPS használatát mindenhol. Az ATS követelmények megsértése az alkalmazás elutasításának oka az App Store ellenőrzésénél.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

ATS konfiguráció az Info.plist-ben. Az NSAllowsArbitraryLoads false értékre van állítva — minden kapcsolatnak HTTPS-t kell használnia. A cdn.example.com domainhez minimális TLS 1.2 verzió van beállítva, az NSAllowsLocalNetworking=true engedélyezi a HTTP-t a helyi hálózathoz (hasznos fejlesztői szerverekhez). Az Apple erősen ajánlja, hogy ne kapcsolja be az NSAllowsArbitraryLoads-t NSExceptionDomains nélkül — ennek kivételnek kell lennie, nem általános szabálynak.

TLS Androidon: Network Security Config

Network Security Config — Android mechanizmus a HTTPS és TLS konfigurálásához a Java/Kotlin kód módosítása nélkül. A konfiguráció a network_security_config.xml XML-fájlban van meghatározva, és az AndroidManifest-ben az android:networkSecurityConfig attribútumon keresztül csatlakozik. Támogatja a megbízható tanúsítványok (user és system CA), a Certificate Pinning, a cleartext HTTP letiltásának, a debug felülírásoknak és a forgalomátirányításnak a konfigurálását.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config Androidhoz. A Base-config tiltja a cleartext forgalmat, és csak a rendszer CA-tanúsítványainak bízik (felhasználói tanúsítványok nélkül — védelem a felhasználó általi MitM tanúsítványok telepítése ellen). Az api.example.com Domain-config pin-set-et tartalmaz a tanúsítvány SHA-256 ujjlenyomatával. Ha a szervertanúsítvány a megadott lejárati dátum előtt megváltozik, a kapcsolat elutasításra kerül — ez a Certificate Pinning szigorú formája.

Certificate Pinning és biztonság

Certificate Pinning — a szerver tanúsítványának vagy nyilvános kulcsának rögzítési technikája az alkalmazás kódjában. Minden TLS kézfogásnál a kliens összehasonlítja a szerver tanúsítványát az előre elmentett ujjlenyomattal (SHA-256 hash). Még ha a támadó meg is szerez egy megbízható CA-tanúsítványt vagy kompromittálja a hitelesítésszolgáltatót, nem tud MitM-támadást végrehajtani — az alkalmazás a konkrét ujjlenyomatot ellenőrzi, nem a CA-láncot. Ez különösen fontos pénzügyi alkalmazások és érzékeny adatokat kezelő alkalmazások esetében.

A Pinning kockázatai és alternatívái

Certificate Pinning óvatosságot igényel: a tanúsítvány szerveren történő megváltozásakor az alkalmazás minden régi verziója nem tud csatlakozni. Ajánlott több tartalék ujjlenyomatot tárolni (elsődleges + tartalék), megadni a pin-set lejárati dátumát, és egy fallback mechanizmust implementálni a szabványos CA-ellenőrzésen keresztül. Alternatíva — Trust On First Use (TOFU), amikor az alkalmazás az első kapcsolatkor megjegyzi a tanúsítványt, és figyelmezteti a felhasználót annak megváltozásakor. Az OWASP (2026) szerint a Certificate Pinning hiánya a mobilalkalmazások top 3 sérülékenysége közé tartozik (M3: Insecure Communication).

A Pinning implementálása Alamofire-ben

Az Alamofire 5+ -ban a Certificate Pinning a ServerTrustManager segítségével konfigurálható PinnedCertificatesTrustEvaluator (teljes tanúsítvány ellenőrzése) vagy PublicKeysTrustEvaluator (csak nyilvános kulcs) használatával. A nyilvános kulcs előnyösebb — nem változik a tanúsítvány ugyanazon CA-nál történő frissítésekor. Hozzon létre egy ServerTrustManager-t [host: evaluator] szótárral, adja át a Session-nek, és használja minden védett API-hoz intézett kéréshez.