SSL/TLS — co to je, protokoly a princip fungování šifrování

Co je SSL/TLS?

SSL (Secure Sockets Layer) — je protokol vyvinutý společností Netscape v roce 1995 pro ochranu webového provozu. První verze SSL 1.0 nebyla nikdy zveřejněna, SSL 2.0 (1995) a SSL 3.0 (1996) se používaly do začátku 21. století, ale obsahovaly kritické zranitelnosti. Na místo SSL přišel TLS (Transport Layer Security) — vylepšená verze standardizovaná organizací IETF. TLS 1.0 (1999) byl založen na SSL 3.0 a následující verze TLS 1.1 (2006), TLS 1.2 (2008) a TLS 1.3 (2018) se postupně odkláněly od původní architektury, přidávaly nové šifrovací algoritmy a odstraňovaly zranitelnosti. Dnes je SSL považováno za zastaralé a všechny moderní systémy používají TLS, i když ze setrvačnosti jsou oba protokoly často zmiňovány společně jako SSL/TLS.

Historie vzniku protokolu

Historie SSL/TLS začala s potřebou bezpečného přenosu dat v raném webu. V roce 1994 společnost Netscape vyvinula SSL 1.0 pro svůj prohlížeč Navigator, ale protokol nebyl nikdy zveřejněn kvůli vážným bezpečnostním problémům. SSL 2.0 byl vydán v roce 1995 a používal se v praxi, ale obsahoval četné zranitelnosti: nedostatek ochrany proti Man-in-the-Middle útokům, slabé šifrovací algoritmy a zranitelnost vůči truncation útokům. SSL 3.0 (1996) vyřešil většinu problémů, ale do roku 2014 v něm byla objevena zranitelnost POODLE, načež IETF oficiálně prohlásila všechny verze SSL za zastaralé. TLS 1.0–1.3 postupně zlepšovaly kryptografickou sílu, výkon a důvěrnost, přičemž TLS 1.3 zkrátil handshake ze dvou round-trip na jeden, což je kritické pro mobilní aplikace s nestabilním připojením.

Jak funguje SSL/TLS Handshake

Handshake — je proces navazování bezpečného spojení mezi klientem a serverem. Skládá se z několika po sobě jdoucích kroků, během kterých strany dohodnou verzi protokolu, zvolí šifrovací algoritmy, vymění si klíče a vzájemně se autentizují. V TLS 1.3 trvá handshake pouze jednu síťovou interakci (1-RTT), zatímco v TLS 1.2 byly potřeba dvě (2-RTT).

Prvním krokem klient odešle ClientHello — zprávu obsahující seznam podporovaných verzí TLS, sadu šifer (cipher suites) a náhodné číslo. Server odpoví ServerHello s vybranou verzí a šifrou, svým certifikátem X.509 a digitálním podpisem. Klient ověří certifikát prostřednictvím řetězce certifikačních autorit (CA), vygeneruje relacní klíč a odešle jej zašifrovaný veřejným klíčem serveru z certifikátu. Po potvrzení serverem začne bezpečný přenos dat. Celý handshake proběhne za 1–3 milisekundy na moderních zařízeních, což jej činí neviditelným pro uživatele.

Certifikáty X.509 a řetězec důvěry

Základem TLS autentizace je infrastruktura veřejného klíče (PKI) postavená na certifikátech formátu X.509. Každý certifikát obsahuje: název domény (Common Name nebo Subject Alternative Name), veřejný klíč serveru, název vydavatele (Certificate Authority), dobu platnosti a digitální podpis CA. Klient ověřuje certifikát serveru prostřednictvím řetězce důvěry: od certifikátu serveru až po kořenovou CA, jejíž certifikát je vložen do operačního systému. Na zařízeních Android jsou kořenové certifikáty uloženy v systémovém úložišti aktualizovaném prostřednictvím Google Play Services; v iOS — prostřednictvím iOS Updates. Při porušení kteréhokoli článku řetězce (prošlý certifikát, neshoda domény, neznámá CA) klient přeruší spojení. Pro certifikáty podepsané svým držitelem (používané při vývoji) je vyžadována výslovná důvěra — v Androidu prostřednictvím Network Security Config, v iOS prostřednictvím NSExceptionDomains v Info.plist. Proces ověřování řetězce certifikátů také zahrnuje kontrolu stavu odvolání prostřednictvím CRL (Certificate Revocation List) nebo OCSP (Online Certificate Status Protocol), i když na mobilních zařízeních jsou požadavky OCSP často přeskakovány pro urychlení připojení — to je kompromis mezi bezpečností a výkonem, který by architekti měli zvážit.

SSL vs TLS: klíčové rozdíly

Ačkoli se termíny SSL a TLS často používají jako synonyma, existují mezi nimi zásadní technické rozdíly, které ovlivňují bezpečnost a výkon mobilních aplikací.

Hlavní rozdíl TLS 1.3 oproti předchůdcům — povinné použití Perfect Forward Secrecy (PFS) prostřednictvím protokolu ECDHE. To znamená, že i když útočník získá přístup k soukromému klíči serveru, nebude schopen dešifrovat dříve zachycený provoz. Pro mobilní aplikace, kde je hacknutí serveru reálnou hrozbou, je TLS 1.3 s PFS povinným bezpečnostním požadavkem.

Známé zranitelnosti starých verzí

Zastaralé verze SSL a TLS mají zdokumentované zranitelnosti, které je činí nevhodnými pro produkční použití. POODLE (CVE-2014-3566) útočí na SSL 3.0 prostřednictvím padding oracle a umožňuje dešifrování relačního cookie během 256 požadavků. BEAST (CVE-2011-3389) využívá zranitelnost TLS 1.0 v režimu CBC prostřednictvím předvídatelného IV. Heartbleed (CVE-2014-0160) — není zranitelností protokolu, ale chybou v implementaci OpenSSL umožňující čtení paměti serveru: podle Netcraft bylo v roce 2014 zranitelných více než 500 tisíc serverů. Počínaje Android 10 (API 29) a iOS 13 jsou všechny uvedené protokoly deaktivovány na úrovni systému. Nicméně vývojáři by měli zkontrolovat konfiguraci serveru pomocí SSL Labs Test (qualys.com) před spuštěním aplikace, aby se ujistili, že neexistují zastaralé cipher suites a že je podporován TLS 1.3.

Jak SSL/TLS chrání data v mobilních aplikacích

V mobilních aplikacích chrání TLS data na třech úrovních: šifrování obsahu (nikdo kromě serveru nemůže data číst), kontrola integrity (data nelze během přenosu změnit) a autentizace serveru (klient si je jistý, že se připojuje ke správnému serveru). Autentizace je obzvláště kritická: bez ní může útočník nahradit server prostřednictvím DNS-spoofingu nebo falešného Wi-Fi přístupového bodu.

Podle studie Google Play Protect (2024) používá 76% Android aplikací TLS správně s kontrolou certifikátů. Zbývajících 24% dělá chyby: vypíná kontrolu certifikátů pro testování (a zapomíná ji zapnout v produkci), používá certifikáty podepsané svým držitelem bez ověření nebo povoluje zastaralé protokoly SSL 3.0 a TLS 1.0. Apple App Transport Security (ATS) v iOS vyžaduje minimálně TLS 1.2 od roku 2017 a od iOS 15 používá ve výchozím nastavení TLS 1.3 pro všechny síťové požadavky. Pro dodatečnou ochranu se také doporučuje implementace Certificate Pinning — připojení ke konkrétnímu certifikátu serveru.

Implementace SSL/TLS v mobilních aplikacích

Podívejme se na příklad nastavení bezpečného HTTPS připojení v Androidu pomocí OkHttp — jedné z nejpopulárnějších knihoven pro práci se sítí. Správná konfigurace zahrnuje vynucené použití TLS 1.3 a kontrolu certifiká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()

V tomto příkladu omezujeme sadu podporovaných verzí TLS pouze na protokoly 1.3 a 1.2, s vyloučením zastaralých TLS 1.0/1.1. Cipher suites jsou vybírány z moderních algoritmů s režimem AEAD a povinnou Perfect Forward Secrecy. HostnameVerifier kontroluje shodu názvu hostitele s certifikátem. Pro iOS se podobné nastavení provádí prostřednictvím konfigurace URLSession s parametrem tlsMinimumSupportedProtocolVersion, kde se uvádí .TLSv13. Dodatečně lze v iOS nastavit tlsMaximumSupportedProtocolVersion pro omezení horní hranice verzí — to je užitečné pro kompatibilitu se staršími servery, které ještě nepřešly na TLS 1.3. Taková konfigurace zaručuje maximální úroveň zabezpečení při přenosu dat v mobilní aplikaci.