Proč HTTPS a co s tím má společného „SSL“
HTTPS (HyperText Transfer Protocol Secure) je způsob, jak šifrovaně a autentizovaně přenášet HTTP přes zabezpečený kanál. Historicky se mluvilo o SSL (Secure Sockets Layer), avšak moderní web používá nástupnický protokol TLS (Transport Layer Security). Dnes tedy „HTTPS“ = „HTTP přes TLS“. Základní cíle jsou tři: důvěrnost (šifrování obsahu), integrita (detekce úprav) a autentizace (ověření, s kým komunikujeme).
Stavební kameny: asymetrická a symetrická kryptografie, hash a AEAD
- Asymetrická kryptografie (např. RSA, ECDSA/Ed25519): používá pár klíčů (veřejný/soukromý) k digitálním podpisům a výměně tajemství.
- Symetrická kryptografie (např. AES, ChaCha20): rychlé šifrování samotného datového provozu po dohodě na sdíleném klíči.
- Hashovací a KDF funkce (SHA-2/SHA-3, HKDF): zajištění integrity, odvozování klíčů.
- AEAD režimy (AES-GCM, ChaCha20-Poly1305): šifrují a zároveň autentizují obsah jedním průchodem.
Jak funguje TLS: zjednodušený přehled handshake (TLS 1.3)
- ClientHello: prohlížeč pošle seznam podporovaných šifer, verzí TLS, rozšíření (SNI, ALPN, OCSP stapling aj.) a ephemerální křivku pro výměnu klíčů (např. X25519, P-256).
- ServerHello: server vybere parametry, pošle svůj certifikát, případně OCSP stapling a CertificateVerify (digitální podpis), a dokončí ephemerální Diffie-Hellman (ECDHE) pro dohodu tajemství.
- Odvození klíčů: obě strany pomocí HKDF odvodí traffic keys; od tohoto okamžiku je komunikace šifrovaná a autentizovaná.
- Early data (0-RTT, volitelné): klient může poslat data ještě před plným dokončením – rychlé, ale se specifickými bezpečnostními riziky (replay).
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/prohlížeče mají seznam root CA, které důvěřují. Řetězec důvěry je typicky: Root CA → Intermediate CA → Server 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 formální vazba na právnickou osobu (IČ, název). Vhodné pro B2B portály.
- EV (Extended Validation): rozšířené ověření identity; dnes s menším vizuálním benefitem v UI prohlížečů, ale s přísnější due diligence.
- SAN/UCC: Subject Alternative Name – více domén/subdomén v jednom certifikátu.
- Wildcard: např.
*.example.com– pokrývá libovolnou první subdoménu. - mTLS (client certs): oboustranná autentizace (server i klient) – pro interní API a vysoce kritické systémy.
Proces vydání: CSR, ACME a nasazení
- Generování klíčů: na serveru či HSM vytvoříte soukromý/veřejný klíč (RSA 2048+/ECDSA P-256/X25519 pro výměnu).
- CSR (Certificate Signing Request): obsahuje veřejný klíč a požadovaná jména (CN/SAN), podepsaný soukromým klíčem.
- Validace CA (DV/OV/EV): například ACME výzva přes DNS-01/HTTP-01.
- Vystavení a řetězec: CA vrátí serverový certifikát a intermediate; server musí posílat full chain.
- Konfigurace: instalace certifikátu a klíče, povolení moderních šifer, zapnutí OCSP stapling, HSTS, HTTP→HTTPS přesměrování.
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 jako 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ání HTTP/2 nebo HTTP/3 (QUIC) v rámci TLS.
- SNI: Server Name Indication – umožní hostovat více certifikátů/domén na jedné IP.
HTTP/2 a HTTP/3 (QUIC): co to mění
HTTP/2 běží nad TLS (obvykle) a přináší multiplexing. HTTP/3 běží nad QUIC (UDP) a integruje TLS 1.3 přímo do transportu. Výsledkem jsou rychlejší handshaky, menší latence při ztrátách a lepší mobilní 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 danou dobu; chrání před downgrade/stripping útoky.
- Přesměrování 301 z HTTP na HTTPS a ideálně HSTS pre-load pro kořenovou doménu a subdomény.
- Mixed content: blokujte nešifrované zdroje (obrázky, skripty) na HTTPS stránkách.
Obnovení relace a 0-RTT: rychlost vs. rizika
- Session resumption: TLS 1.3 používá PSK (Pre-Shared Keys) se session tickets – rychlejší navázání bez plného handshake.
- 0-RTT data: umožní okamžité odeslání požadavků, ale hrozí replay; omezujte na idempotentní metody (GET), nebo 0-RTT vypněte.
Architektury v praxi: terminace TLS, CDN a mTLS
- Reverse proxy/Load balancer: TLS se ukončí na hraně (NGINX/Envoy/HAProxy, CDN), do aplikace jde čisté HTTP/2/3 nebo vnitřní TLS.
- CDN/WAF: zlepšují latenci a bezpečnost (DDoS, WAF pravidla); dbejte na správnou propagaci certifikátů a SNI.
- mTLS: oboustranné ověření certifikátem klienta – ideální pro interní služby a nulovou důvěru (zero-trust).
Životní cyklus a obnova: platnosti, rotace a automatizace
- Krátké platnosti (např. 90 dnů u ACME) + automatická obnova snižují dopady kompromitace.
- Automatizace: ACME klienti (obnova, deploy hooky, reload služby), ověřování funkce (syntetické testy, expirace alerty).
- Bezpečná správa klíčů: omezené ACL, HSM, nebo aspoň dedikované účty a audit.
Revokace, CT a bezpečnostní zásady
- OCSP/CRL: revokace kompromitovaných certifikátů; spoléhejte na OCSP stapling a krátké platnosti.
- Certificate Transparency: pravidelně sledujte CT logy (zachytíte neoprávněná vydání pro vaši doménu).
- Pinning: historický HPKP je deprecovaný; používejte pinning v aplikaci (mobilní klienty) nebo monitorujte CT.
Výkon a škálování: co skutečně ovlivňuje rychlost
- Výběr křivek a šifer: ECDHE + AES-GCM/ChaCha20-Poly1305; na CPU bez AES-NI bývá ChaCha20-Poly1305 rychlejší.
- Resumption a HTTP/2/3: minimalizace RTT, multiplexing, server push (opatrně), QUIC pro mobilní sítě.
- Cache OCSP staplingu a minimalizace velikosti cert řetězce.
Časté chyby a jejich prevence
- Neposílání intermediate certifikátu: klient pak nedokáže ověřit řetězec – vždy instalujte full chain.
- Slabé šifry/verze: ponechané TLS 1.0/1.1 nebo ne-PFS sady – vypnout, aktualizovat.
- Smíšený obsah: načítání HTTP zdrojů v HTTPS stránce – prohlížeče blokují a snižují důvěru.
- Nesprávné SNI/ALPN: vede k pádu na HTTP/1.1, špatným certům nebo varováním.
- Chybějící HSTS: uživatel může být napaden downgrade útokem (ssl-strip) při prvním přístupu.
Bezpečnost na klientovi: validace a detekce problémů
- Varování prohlížeče (self-signed, vypršel, CN nesedí): uživatele neobcházejte; opravte certifikát/řetězec.
- Enterprise intercept: firemní MITM proxy s vlastním rootem – nutná transparence a řízení rizik.
- DNSSEC + DANE (pokročilé): v některých prostředích doplněk k PKI, ale omezená podpora pro web klienty.
Bezpečnost v aplikační vrstvě: HTTPS není všelék
Šifrování neřeší zranitelnosti aplikace (XSS, SQLi, CSRF). HTTPS chrání přenos, ale je nutné dodržet i Content Security Policy, správu cookies (Secure, HttpOnly, SameSite), rate-limiting a další kontrolní mechanismy.
Kontrolní seznam pro provoz HTTPS
- TLS 1.3 (a 1.2), silné ECDHE křivky, AEAD šifry, PFS.
- Platný certifikát s plným řetězcem, CT/SCT, OCSP stapling.
- HSTS (+ preload), povinné přesměrování 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.
Závěr: bezpečný a rychlý web díky správně nasazenému TLS
HTTPS je dnes standardem důvěry pro web. Moderní TLS 1.3, silné šifry, pečlivá správa certifikátů a správná konfigurace serveru i prohlížečových zásad (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.