HTTP/HTTPS: co to je, přenosové protokoly dat a šifrování TLS

Co jsou HTTP a HTTPS?

HTTP (HyperText Transfer Protocol) — je protokol aplikační vrstvy modelu OSI určený k přenosu hypertextových dokumentů a dalších dat ve World Wide Web. Vyvinutý Timem Bernersem-Leem v roce 1989, HTTP prošel několika verzemi: od HTTP/0.9 (pouze GET požadavky a HTML odpovědi) po moderní HTTP/2 a HTTP/3. Protokol funguje na schématu požadavek-odpověď: klient odešle požadavek na server, server jej zpracuje a vrátí odpověď.

HTTPS (HTTP Secure) — je rozšíření protokolu HTTP přidávající vrstvu šifrování prostřednictvím TLS (Transport Layer Security). HTTPS není samostatný protokol — je to kombinace HTTP a TLS. Data přenášená přes HTTPS jsou šifrována na straně klienta a dešifrována na serveru, což je činí nedostupnými pro zachycení a padělání. HTTPS také zajišťuje autentizaci serveru pomocí SSL/TLS certifikátů a garantuje, že se klient připojuje ke skutečnému serveru, nikoli k útočníkovi.

Klíčový rozdíl mezi HTTP a HTTPS je bezpečnost. HTTP přenáší data v otevřené podobě: jakýkoli uzel sítě mezi klientem a serverem může číst obsah požadavku nebo odpovědi. HTTPS šifruje veškerý obsah včetně URL, hlaviček a těla požadavku a ponechává viditelnou pouze IP adresu serveru a port připojení. Pro mobilní aplikace pracující přes veřejné Wi-Fi sítě je HTTPS povinným bezpečnostním požadavkem.

Jak funguje HTTP

HTTP — je bezstavový protokol (stateless) fungující nad TCP/IP. Klient naváže TCP spojení se serverem (obvykle na portu 80 pro HTTP nebo 443 pro HTTPS), odešle HTTP požadavek, obdrží HTTP odpověď a ukončí spojení (v HTTP/1.1 může být spojení znovu použito). Každá interakce mezi klientem a serverem se skládá z požadavku a odpovědi. Bezstavovost znamená, že server neuchovává informace o předchozích požadavcích klienta — každý požadavek je zpracováván nezávisle.

Proces HTTP interakce zahrnuje následující kroky:

• DNS rozlišení — prohlížeč nebo klient převede doménové jméno na IP adresu pomocí DNS
• TCP handshake — TCP spojení je navázáno třífázovým handshake (SYN, SYN-ACK, ACK)
• TLS handshake — pro HTTPS je dodatečně navázáno šifrované spojení (výměna certifikátů a klíčů)
• HTTP požadavek — klient odešle metodu, URL, hlavičky a volitelně tělo požadavku
• HTTP odpověď — server vrátí stavový kód, hlavičky a tělo odpovědi

Důležitou vlastností HTTP je idempotence metod. GET, HEAD, PUT, DELETE a OPTIONS jsou idempotentní: vícenásobné provedení stejného požadavku nemění stav serveru po prvním provedení. POST, PATCH a CONNECT nejsou idempotentní — každé volání může vytvořit nový zdroj nebo změnit stav. Pro mobilní vývoj je pochopení idempotence kritické: při opětovném odeslání požadavku kvůli chybě sítě musí klient vědět, zda je bezpečné požadavek zopakovat.

HTTPS a šifrování TLS

HTTPS používá kryptografický protokol TLS (Transport Layer Security) k ochraně přenášených dat. TLS — nástupce SSL (Secure Sockets Layer), který byl vyvinut společností Netscape v roce 1995. Verze SSL 2.0 a 3.0 jsou považovány za zastaralé a nebezpečné; moderní verze TLS 1.2 (vydána v roce 2008) a TLS 1.3 (vydána v roce 2018) jsou široce používány. TLS 1.3 zejména zkracuje dobu navazování spojení z 2 round-trips na 1, což výrazně urychluje načítání na mobilních zařízeních.

Proces TLS handshake zahrnuje následující fáze:

• Client Hello — klient odešle seznam podporovaných verzí TLS a sad šifer
• Server Hello — server vybere verzi TLS a sadu šifer, odešle svůj SSL/TLS certifikát
• Ověření certifikátu — klient ověří certifikát serveru pomocí řetězce důvěry až ke kořenové CA
• Výměna klíčů — klient a server vygenerují společný tajný klíč (relační klíč)
• Switch Cipher — obě strany potvrdí přechod na šifrované spojení

Ověření SSL/TLS certifikátu — kritická fáze pro bezpečnost. Klient kontroluje, zda certifikát: nevypršel, je podepsán důvěryhodnou certifikační autoritou (CA), odpovídá doméně v URL a nebyl odvolán (prostřednictvím CRL nebo OCSP). V mobilních aplikacích se doporučuje použití Certificate Pinning — připojení ke konkrétnímu certifikátu nebo veřejnému klíči serveru. To zabraňuje MITM útokům i v případě kompromitace CA. Pinning však vyžaduje opatrnost: při změně certifikátu musí být aplikace předem aktualizována.

Struktura HTTP požadavku a odpovědi

HTTP požadavek se skládá ze tří částí: počátečního řádku (request line), hlaviček (headers) a volitelného těla (body). Počáteční řádek obsahuje HTTP metodu, URL požadavku a verzi HTTP. Hlavičky předávají metainformace: typ obsahu, autentizační tokeny, nastavení cache. Tělo je přítomno pouze u metod přenášejících data (POST, PUT, PATCH) a chybí u GET a DELETE.

Příklad HTTP požadavku na REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

HTTP odpověď má analogickou strukturu: počáteční řádek s verzí HTTP a stavovým kódem, hlavičky a tělo. Stavový kód – třímístné číslo určující výsledek zpracování požadavku. Hlavičky odpovědi zahrnují Content-Type, Content-Length, Cache-Control, Set-Cookie a další. Tělo odpovědi obsahuje požadovaná data ve formátu uvedeném v Content-Type (obvykle JSON pro API, HTML pro webové stránky, obrázky pro mediální obsah).

Hlavičky hrají klíčovou roli v fungování HTTP. Content-Type a Accept řídí formát dat. Authorization předává přístupové tokeny. Cache-Control řídí ukládání do cache. CORS hlavičky (Access-Control-Allow-Origin) kontrolují přístup z jiných domén v prohlížečích. User-Agent identifikuje klientskou aplikaci. Pro mobilní aplikace jsou hlavičky pro správu cache obzvláště důležité — snižují objem přenášených dat a zlepšují fungování při slabém signálu.

Stavové kódy HTTP

Stavové kódy HTTP jsou seskupeny do pěti tříd označených první číslicí: 1xx (informační), 2xx (úspěch), 3xx (přesměrování), 4xx (chyba klienta), 5xx (chyba serveru). Pochopení těchto kódů je nezbytné pro správné zpracování odpovědí v mobilní aplikaci: 2xx znamená úspěch a data lze zobrazit, 4xx indikuje problém v požadavku (je třeba zobrazit chybu uživateli), 5xx — problém na serveru (požadavek je třeba opakovat později).

Pro mobilní aplikace má zpracování kódu 401 Unauthorized zvláštní význam. Po obdržení tohoto kódu by se klient měl pokusit obnovit přístupový token pomocí Refresh Token a zopakovat původní požadavek. Pokud obnovení tokenu také vrátí 401, musí být uživatel přesměrován na přihlašovací obrazovku. Tato logika je obvykle implementována v Interceptor (OkHttp) nebo v middleware vrstvě síťového klienta.

HTTP/1.1, HTTP/2 a HTTP/3

HTTP/1.1, publikovaný v roce 1999, stále zůstává široce používanou verzí protokolu. Jeho hlavní nevýhoda — head-of-line blocking: požadavky na stejný server jsou prováděny sekvenčně, každý další čeká na dokončení předchozího. K obejití tohoto omezení otevírají prohlížeče 6–8 paralelních TCP spojení ke stejné doméně, což zvyšuje zatížení serveru a spotřebu paměti. HTTP/1.1 také přenáší hlavičky v nešifrované podobě a nepodporuje server push.

HTTP/2 (2015) řeší problém blokování pomocí multiplexování — více datových toků je přenášeno jedním TCP spojením současně. Server může odesílat zdroje klientovi dříve, než je klient požádá (server push). HTTP/2 také komprimuje hlavičky pomocí HPACK, což snižuje objem přenášených dat. Pro mobilní aplikace je HTTP/2 obzvláště užitečné: jedno spojení nahrazuje několik, čímž se zkracuje doba TLS handshake a spotřeba baterie.

HTTP/3 (2022) — nejnovější verze protokolu, která místo TCP používá QUIC (Quick UDP Internet Connections). QUIC funguje nad UDP a odstraňuje problém head-of-line blocking na úrovni transportního protokolu. HTTP/3 zkracuje dobu navazování spojení na 0 round-trips v nejlepším případě (při opakovaných připojeních) a na 1 round-trip při prvním připojení, což je výrazně rychlejší než HTTP/2 s jeho 2–3 round-trips. Pro mobilní zařízení je HTTP/3 obzvláště efektivní při přepínání mezi Wi-Fi a mobilní sítí — spojení není přerušeno, protože QUIC používá identifikátor spojení namísto IP adresy.

HTTPS v mobilním vývoji

Používání HTTPS v mobilních aplikacích — není doporučení, ale povinný požadavek. Počínaje Android 9 (API 28) a iOS 9 (ATS — App Transport Security) musí všechna síťová spojení standardně používat HTTPS. HTTP požadavky jsou systémem blokovány a k jejich povolení je vyžadována výslovná výjimka v konfiguraci aplikace. Google Play Store a App Store odmítají aplikace přenášející důvěrná data přes HTTP, včetně hesel, tokenů a osobních údajů.

Konfigurace HTTPS v mobilní aplikaci na Androidu zahrnuje:

<!-- AndroidManifest.xml — oprávnění pro síťové požadavky -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — konfigurace HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Na iOS se obdobná konfigurace provádí pomocí Info.plist s klíčem NSAppTransportSecurity. Pro ladění HTTPS provozu v mobilních aplikacích se používají proxy nástroje: Charles Proxy, Proxyman nebo mitmproxy. Vyžadují instalaci důvěryhodného SSL certifikátu na zařízení. V produkčních sestaveních je třeba vypnout možnost ladění a zkontrolovat, zda je Certificate Pinning správně nakonfigurován. Použití OkHttp na Androidu s jeho CertificatePinner nebo TrustManager na iOS s SecTrustEvaluate — standardní přístupy k implementaci pinningu.

Důležitý aspekt bezpečnosti HTTPS v mobilním vývoji — SSL Pinning. Bez pinningu aplikace důvěřuje jakémukoli certifikátu podepsanému známou CA. Pokud je CA kompromitována, může útočník zachytávat provoz aplikace. Pinning připoutá aplikaci ke konkrétnímu certifikátu nebo veřejnému klíči serveru. Při změně certifikátu na serveru je nutné vydat aktualizaci aplikace, proto se pinning plánuje s rezervou — připevňuje se k certifikátu nadřazené CA nebo se používá několik záložních klíčů.