HTTPS a SSL/TLS certifikáty: principy šifrovaného a bezpečného přenosu dat

Proč HTTPS a co má společného „SSL“

HTTPS (HyperText Transfer Protocol Secure) je metoda, jak šifrovaně a autentizovaně přenášet HTTP přes zabezpečený kanál. Historicky se používal termín SSL (Secure Sockets Layer), avšak moderní web využívá nástupnický protokol TLS (Transport Layer Security). Dnes tedy „HTTPS“ znamená „HTTP přes TLS“. Základní cíle jsou tři: důvěrnost (šifrování obsahu), integrita (detekce změn) a autentizace (ověření identity protistrany).

Stavební kameny: asymetrická a symetrická kryptografie, hashovací funkce a AEAD

• Asymetrická kryptografie (např. RSA, ECDSA/Ed25519): používá dvojici klíčů (veřejný/soukromý) pro digitální podpisy a výměnu tajemství.
• Symetrická kryptografie (např. AES, ChaCha20): rychlé šifrování datového provozu po dohodě na sdíleném klíči.
• Hashovací a KDF funkce (SHA-2/SHA-3, HKDF): zabezpečují integritu a slouží k odvození klíčů.
• AEAD režimy (AES-GCM, ChaCha20-Poly1305): kombinují šifrování a autentizaci obsahu v jednom průchodu.

Jak funguje TLS: zjednodušený přehled handshake (TLS 1.3)

1. ClientHello: prohlížeč odešle seznam podporovaných šifer, verzí TLS, rozšíření (SNI, ALPN, OCSP stapling apod.) a ephemeralní křivku pro výměnu klíčů (např. X25519, P-256).
2. ServerHello: server vybere parametry, zašle svůj certifikát, případně OCSP stapling a CertificateVerify (digitální podpis) a dokončí ephemeralní Diffie-Hellman (ECDHE) pro dohodu tajemství.
3. Odvození klíčů: obě strany pomocí HKDF odvodí traffic keys; od tohoto okamžiku je komunikace šifrovaná a autentizovaná.
4. Early data (0-RTT, volitelné): klient může odeslat data ještě před dokončením handshake – rychlé, ale s určitými bezpečnostními riziky (opětovné přehrání).

Poznámka: TLS 1.3 zjednodušuje a zkracuje spojení (1 RTT), odstraňuje zastaralé šifry a vyžaduje PFS (Perfect Forward Secrecy) díky ECDHE.

Co je SSL/TLS certifikát a jak vzniká důvěra

Certifikát je veřejný klíč serveru s metadaty (doménové jméno, platnost, vydavatel), podepsaný certifikační autoritou (CA). Důvěra stojí na PKI (Public Key Infrastructure): operační systémy i prohlížeče obsahují seznam root CA, kterým důvěřují. Řetězec důvěry je typicky: Root CA → Intermediate CA → Serverový certifikát.

Druhy certifikátů: DV, OV, EV a speciální varianty

• DV (Domain Validation): ověřuje se kontrola nad doménou (DNS, HTTP soubor, e-mail). Běžné pro většinu webů (např. ACME/Let’s Encrypt).
• OV (Organization Validation): navíc potvrzení formální vazby na právnickou osobu (IČ, název). Vhodné pro B2B portály.
• EV (Extended Validation): rozšířené ověření identity; dnes má omezený vizuální dopad v uživatelském rozhraní prohlížečů, avšak přísnější due diligence.
• SAN/UCC: Subject Alternative Name – umožňuje pokrýt více domén nebo subdomén jedním certifikátem.
• Wildcard: např. *.example.com – pokrývá libovolnou první úroveň subdomény.
• mTLS (client certs): oboustranná autentizace (server i klient) – používaná u interních API a vysoce kritických systémů.

Proces vydání: CSR, ACME a nasazení

1. Generování klíčů: na serveru nebo v HSM vytvoříte soukromý a veřejný klíč (RSA 2048+/ECDSA P-256/X25519 pro výměnu).
2. CSR (Certificate Signing Request): obsahuje veřejný klíč a požadovaná jména (CN/SAN), podepsaný soukromým klíčem.
3. Validace CA (DV/OV/EV): například ACME výzvy přes DNS-01/HTTP-01.
4. Vystavení a řetězec: CA vrátí serverový certifikát a intermediate; server musí odesílat full chain.
5. Konfigurace: instalace certifikátu a klíče, povolení moderních šifer, zapnutí OCSP stapling, HSTS a přesměrování HTTP→HTTPS.

Ověření certifikátu v prohlížeči: co se děje na pozadí

• Kontrola domény (CN/SAN) vůči cílové URL hostu.
• Validace řetězce k důvěryhodnému rootu z lokálního úložiště.
• Revokace: OCSP/CRL; v praxi pomáhá OCSP stapling (server přikládá čerstvou odpověď).
• Certificate Transparency (CT): certifikát musí být zaznamenán v veřejných CT logech; prohlížeče vyžadují důkaz (SCT).

Šifry, verze TLS a nastavení serveru

• Preferujte TLS 1.3; povolte TLS 1.2 pro kompatibilitu, starší verze vypněte.
• PFS: ECDHE (X25519/P-256) pro výměnu klíčů, AES-GCM nebo ChaCha20-Poly1305 pro AEAD.
• Podpisy certifikátů: ECDSA (rychlejší, kratší klíče) nebo RSA 2048+; Ed25519 je podporována v TLS 1.3 pro podpisy, dostupnost v CA ekosystému se liší.
• ALPN: vyjednávání HTTP/2 nebo HTTP/3 (QUIC) v rámci TLS.
• SNI: Server Name Indication – umožňuje hostovat více certifikátů/domén na jedné IP adrese.

HTTP/2 a HTTP/3 (QUIC): co to mění

HTTP/2 běží zpravidla nad TLS a přináší multiplexing. HTTP/3 běží nad QUIC (UDP) a integruje TLS 1.3 přímo do transportní vrstvy. Výsledkem jsou rychlejší handshaky, nižší latence při ztrátách paketů a lepší mobilní uživatelská zkušenost.

HSTS, směrování na HTTPS a smíšený obsah

• HSTS (HTTP Strict Transport Security): prohlížeč po prvním kontaktu vyžaduje výhradně HTTPS po definovanou dobu; chrání před downgrade a stripping útoky.
• Přesměrování 301 z HTTP na HTTPS a ideálně HSTS preload pro kořenovou doménu i subdomény.
• Mixed content: blokujte nešifrované zdroje (obrázky, skripty) na HTTPS stránkách.

Obnovení relace a 0-RTT: rychlost vs. rizika

• Obnovení relace: TLS 1.3 využívá PSK (Pre-Shared Keys) se session tickets – umožňuje rychlejší navázání spojení bez opakovaného full handshake.
• 0-RTT data: umožní odesílání dat okamžitě, avšak nese riziko replay útoků; omezujte na idempotentní metody (GET) nebo zvažte vypnutí 0-RTT.

Architektury v praxi: terminace TLS, CDN a mTLS

• Reverse proxy/Load balancer: TLS se ukončí na hranici (NGINX/Envoy/HAProxy, CDN), do aplikační vrstvy jde čisté HTTP/2 nebo HTTP/3, případně interní TLS.
• CDN/WAF: zlepšují latenci a bezpečnost (DDoS ochrana, pravidla WAF); dbejte na správnou propagaci certifikátů a SNI.
• mTLS: oboustranné ověření klientským certifikátem je ideální pro interní služby a zero-trust architektury.

Životní cyklus a obnova: platnosti, rotace a automatizace

• Krátké platnosti (např. 90 dnů u ACME) s automatickou obnovou snižují dopady kompromitace klíčů.
• Automatizace: ACME klienti (obnova, nasazení, reload služeb), monitorování funkčnosti (syntetické testy, upozornění na expiraci).
• Bezpečná správa klíčů: omezené přístupy (ACL), HSM nebo alespoň dedikované účty a auditní stopy.

Revokace, CT a bezpečnostní zásady

• OCSP/CRL: revokace kompromitovaných certifikátů; spoléhání na OCSP stapling a krátké platnosti.
• Certificate Transparency: pravidelný monitoring CT logů odhalí neoprávněné vydání certifikátů pro vaši doménu.
• Pinning: historický HPKP je zastaralý; používejte pinning v aplikacích (např. mobilní klienti) nebo sledujte CT záznamy.

Výkon a škálování: co skutečně ovlivňuje rychlost

• Výběr křivek a šifer: ECDHE + AES-GCM či ChaCha20-Poly1305; na CPU bez AES-NI bývá ChaCha20-Poly1305 rychlejší.
• Session resumption a HTTP/2/3: minimalizace RTT, multiplexing, server push (s opatrností), QUIC pro mobilní sítě.
• Cache OCSP staplingu a minimalizace velikosti certifikačního řetězce.

Časté chyby a jejich prevence

• Neposílání intermediate certifikátu: klient nedokáže ověřit řetězec – vždy instalujte full chain.
• Slabé šifry/verze: ponechání TLS 1.0/1.1 nebo ne-PFS šifer – vypněte a aktualizujte.
• Smíšený obsah: načítání HTTP zdrojů na HTTPS stránce – prohlížeče blokují a snižují důvěryhodnost.
• Nesprávné SNI/ALPN: vede k pádu na HTTP/1.1, nesprávným certifikátům či varováním v prohlížeči.
• Chybějící HSTS: uživatel může být při prvním přístupu napaden downgrade útokem (např. ssl-strip).

Bezpečnost na klientovi: validace a detekce problémů

• Varování prohlížeče (self-signed, vypršelý certifikát, nesoulad CN): neobcházejte; opravte certifikát nebo řetězec.
• Enterprise intercept: firemní MITM proxy s vlastním root certifikátem – vyžaduje transparentnost a řízení rizik.
• DNSSEC + DANE (pokročilé): v určitých prostředích doplňují PKI, ale mají omezenou podporu v běžných webových klientech.

Bezpečnost v aplikační vrstvě: HTTPS není všelék

Šifrování neřeší zranitelnosti aplikací (XSS, SQLi, CSRF). HTTPS chrání přenos dat, ale je nezbytné dodržovat i Content Security Policy, správu cookies (Secure, HttpOnly, SameSite), rate-limiting a další mechanismy kontroly.

Kontrolní seznam pro provoz HTTPS

• TLS 1.3 (a 1.2), silné ECDHE křivky, AEAD šifry, PFS.
• Platný certifikát s kompletním řetězcem, CT/SCT, OCSP stapling.
• HSTS (+ preload), povinné přesměrování na HTTPS, žádný mixed content.
• ALPN pro HTTP/2 a HTTP/3; správné SNI pro multi-tenant hosting.
• Automatizovaná obnova certifikátů (ACME), monitoring expirace certifikátů.

Závěr: bezpečný a rychlý web díky správnému nasazení TLS

HTTPS je dnes standardem důvěry pro webové aplikace. Moderní TLS 1.3, silné šifry, pečlivá správa certifikátů a správná konfigurace serveru i prohlížečových politik (HSTS, ALPN, SNI) přinášejí současně bezpečnost, výkon i důvěru. Správně nastavené HTTPS je rychlé, automatizované a transparentní – a tvoří základ bezpečné digitální komunikace.