SSL/TLS: klíčové pojmy a protokoly v programování

Co je SSL/TLS?

SSL (Secure Sockets Layer) a TLS (Transport Layer Security) — kryptografické protokoly zajišťující bezpečný přenos dat po síti. SSL, vyvinutý společností Netscape v 90. letech, byl po verzi 3.0 prohlášen za zastaralý kvůli zranitelnostem POODLE a BEAST. TLS, jeho nástupce, prošel verzemi 1.0, 1.1, 1.2 a 1.3 — v současnosti jsou za aktuální považovány pouze TLS 1.2 a TLS 1.3. Všechny moderní mobilní platformy vyžadují použití TLS pro síťová připojení a App Store a Google Play to kontrolují ve fázi recenze.

Proč mobilní aplikace potřebují TLS

Bez TLS je provoz mezi aplikací a serverem přenášen jako čistý text — kdokoli ve stejné Wi-Fi síti může zachytit uživatelská jména, hesla, tokeny a osobní údaje uživatelů pomocí Wireshark nebo tcpdump. TLS šifruje všechna přenášená data (šifrování na transportní úrovni) a ověřuje pravost serveru pomocí řetězce certifikátů X.509. Podle IETF (2018) používá TLS 1.3 pouze moderní AEAD šifry (AES-GCM, ChaCha20-Poly1305) a vylučuje zastaralé algoritmy jako RC4 a 3DES.

HTTPS a TLS

HTTPS (HTTP Secure) — je HTTP přes TLS. Když mobilní aplikace odešle požadavek přes https://, nejprve naváže TLS spojení se serverem a poté přenáší HTTP hlavičky a tělo požadavku již přes šifrovaný kanál. Bez HTTPS by žádné seriózní API nemělo fungovat — to je základní bezpečnostní hygiena. Podle OWASP (2026) patří nezabezpečená připojení mezi top 3 zranitelností mobilních aplikací.

Jak funguje TLS Handshake

TLS Handshake — proces navázání bezpečného spojení mezi klientem a serverem. Strany se dohodnou na verzi protokolu, zvolí šifrovací sadu (cipher suite), vymění si klíče pomocí asymetrické kryptografie a ověří certifikáty. V TLS 1.2 vyžaduje handshake 2 Round Trip Time (2 RTT): klient → server s ClientHello, server → klient s ServerHello a Certificate, poté závěrečné zprávy Finished. TLS 1.3 tento proces zkracuje na 1 RTT.

Podrobné fáze handshake TLS 1.2

První fáze: ClientHello — klient odešle podporované verze TLS, seznam šifrovacích sad a náhodné číslo. Server odpovídá ServerHello, vybírá verzi a šifrovací sadu, odesílá svůj certifikát X.509 (Certificate) a zprávu ServerHelloDone. Klient ověří certifikát pomocí řetězce důvěryhodných certifikačních autorit (CA), vygeneruje pre-master secret, zašifruje jej veřejným klíčem z certifikátu a odešle serveru v ClientKeyExchange. Poté obě strany vygenerují session klíče a vymění si zprávy ChangeCipherSpec a Finished. Od tohoto okamžiku jsou všechna data šifrována symetricky.

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říklad zpracování URLAuthenticationChallenge na iOS přes URLSessionDelegate. Tato metoda je volána při každém TLS Handshake a umožňuje aplikaci vlastní ověření certifikátu serveru. Pro produkci přidejte ověření certifikátu přes SecTrustEvaluateWithError a porovnejte s dříve uloženým otiskem — teprve poté zavolejte useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — první velká aktualizace protokolu za 10 let. Hlavní vylepšení: handshake zkrácen na 1 RTT (0 RTT pro opětovná připojení), odstraněny zastaralé šifrovací sady (RSA key exchange, CBC-mode), povinné dokonalé utajení vpřed (PFS) a ochrana proti downgrade útokům pomocí signed transcript. Podle Qualys SSL Labs (2026) poskytuje TLS 1.3 ochranu i při kompromitaci dlouhodobého klíče serveru díky PFS.

0-RTT (Zero Round Trip Time) — funkce TLS 1.3, která umožňuje klientovi odesílat data okamžitě spolu s ClientHello při opětovném připojení přes PSK (Pre-Shared Key). To urychluje načítání následujících obrazovek v mobilních aplikacích, zejména při častých požadavcích na stejný server. Data 0-RTT však nejsou chráněna proti replay útokům — lze je zachytit a znovu odeslat. Používejte 0-RTT pouze pro idempotentní požadavky (GET, PUT) bez vedlejších účinků.

TLS na iOS: App Transport Security

App Transport Security (ATS) — mechanismus Apple vyžadující HTTPS připojení s TLS 1.2 nebo vyšším, ve výchozím nastavení zapnutý od iOS 9. ATS blokuje všechna HTTP připojení a HTTPS s TLS nižším než 1.2. Vývojář může nakonfigurovat výjimky v Info.plist pomocí NSAppTransportSecurity pro konkrétní domény, ale Apple doporučuje minimalizovat výjimky a používat HTTPS všude. Porušení požadavků ATS je důvodem k zamítnutí aplikace při recenzi v App Store.

<!-- 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>

Konfigurace ATS v Info.plist. NSAllowsArbitraryLoads je nastaven na false — všechna připojení musí používat HTTPS. Pro doménu cdn.example.com je nastavena minimální verze TLS 1.2, NSAllowsLocalNetworking=true povoluje HTTP pro lokální síť (užitečné pro vývojové servery). Apple důrazně nedoporučuje zapínat NSAllowsArbitraryLoads bez NSExceptionDomains — to by měla být výjimka, nikoli obecné pravidlo.

TLS na Android: Network Security Config

Network Security Config — mechanismus Androidu pro konfiguraci HTTPS a TLS bez změny kódu Java/Kotlin. Konfigurace je definována v XML souboru network_security_config.xml a připojena v AndroidManifest pomocí atributu android:networkSecurityConfig. Podporuje konfiguraci důvěryhodných certifikátů (user a system CA), Certificate Pinning, vypnutí prostého HTTP, debug přepisy a přesměrování provozu.

<!-- 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 pro Android. Base-config zakazuje prostý provoz a důvěřuje pouze systémovým CA certifikátům (bez uživatelských — ochrana proti instalaci MitM certifikátů uživatelem). Domain-config pro api.example.com obsahuje pin-set s SHA-256 otiskem certifikátu. Pokud se certifikát serveru změní před uvedeným datem expirace, připojení bude zamítnuto — toto je přísná forma Certificate Pinning.

Certificate Pinning a bezpečnost

Certificate Pinning — technika fixace certifikátu nebo veřejného klíče serveru v kódu aplikace. Při každém TLS Handshake klient porovná certifikát serveru s dříve uloženým otiskem (hash SHA-256). I když útočník získá důvěryhodný CA certifikát nebo zkompromituje certifikační autoritu, nemůže provést MitM útok — aplikace kontroluje konkrétní otisk, nikoli řetězec CA. To je obzvláště důležité pro finanční aplikace a aplikace s citlivými údaji.

Rizika a alternativy Pinningu

Certificate Pinning vyžaduje opatrnost: při změně certifikátu na serveru se všechny staré verze aplikace nebudou moci připojit. Doporučuje se ukládat několik záložních otisků (hlavní + záložní), uvést datum expirace pin-set a implementovat fallback mechanismus přes standardní CA ověření. Alternativou je Trust On First Use (TOFU), kdy si aplikace zapamatuje certifikát při prvním připojení a upozorní uživatele při jeho změně. Podle OWASP (2026) patří chybějící Certificate Pinning mezi top 3 zranitelností mobilních aplikací (M3: Insecure Communication).

Implementace Pinningu v Alamofire

V Alamofire 5+ se Certificate Pinning konfiguruje pomocí ServerTrustManager s PinnedCertificatesTrustEvaluator (kontrola celého certifikátu) nebo PublicKeysTrustEvaluator (pouze veřejný klíč). Veřejný klíč je preferován — nemění se při aktualizaci certifikátu u stejné CA. Vytvořte ServerTrustManager se slovníkem [host: evaluator], předejte ho do Session a používejte pro všechny požadavky na chráněná API.