HTTPS a SSL

HTTPS a SSL

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)

  1. 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).
  2. 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í.
  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 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í

  1. Generování klíčů: na serveru či HSM vytvoříte soukromý/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ýzva přes DNS-01/HTTP-01.
  4. Vystavení a řetězec: CA vrátí serverový certifikát a intermediate; server musí posílat full chain.
  5. 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.

Pridaj komentár

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *