Slovník pojmů

HTTPS a TLS

HTTPS chrání přenos mezi klientem a serverem před odposlechem a nepozorovanou změnou. Neověří ale, zda má přihlášený uživatel právo změnit objednávku.

Stručná definice

HTTP v zabezpečeném spojení, ne samostatná aplikační autorizace.

HTTPS není náhrada HTTP, ale jeho použití uvnitř spojení chráněného TLS neboli Transport Layer Security. Před odesláním webového požadavku se klient a server dohodnou na bezpečnostních parametrech. Server předloží certifikát pro svou doménu a klient ověří jeho důvěryhodnost, platnost a shodu se jménem, na které se připojuje.

Po úspěšném navázání TLS jsou data mezi klientem a konkrétním koncem spojení šifrovaná a chráněná proti nepozorované úpravě. U běžného webu je tím koncem reverse proxy nebo webový server. Pokud infrastruktura TLS ukončuje tam, spojení mezi proxy a backendem je samostatný úsek, který se navrhuje podle důvěryhodnosti sítě a citlivosti dat.

K čemu se používá

Pro každý webový request, přihlášení i API integraci

TLS chrání transportní vrstvu, na níž běží web, API i automatizovaná komunikace.

  • webové stránky, přihlášení, administrace a session cookies
  • API tokeny, autorizační hlavičky a citlivé requesty klientských aplikací
  • webhooky, integrace dopravců, marketplace a platební komunikace
  • načítání JavaScriptu, stylů, obrázků a fontů bez mixed content
  • secure context pro webové funkce, které prohlížeče mimo HTTPS neotevřou

Praktický příklad

API za reverse proxy s obnoveným certifikátem

Klient marketplace volá HTTPS endpoint API. Reverse proxy předloží certifikát pro api.example.cz, ověří se TLS spojení a proxy předá request interní aplikaci. Backend ověří HMAC podpis webhooku nebo token API nezávisle na tom, že spojení bylo šifrované.

Konfigurace níže ukazuje pouze zásadu: HTTP přesměrovat na HTTPS a poslat HSTS až z HTTPS odpovědi. Hodnotu max-age, seznam podporovaných protokolů a způsob správy certifikátu je nutné zvolit podle infrastruktury a otestovat, nikoli zkopírovat bez kontextu.

server {
    listen 80;
    server_name api.example.cz;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name api.example.cz;

    add_header Strict-Transport-Security "max-age=31536000" always;
    # certifikát a bezpečné TLS nastavení patří sem
}

Jak funguje

Nejdřív bezpečný kanál, potom HTTP request

Handshake je kryptografický protokol; pro vývoj aplikace je důležité hlavně vědět, jaké záruky dává a kde končí.

  1. Klient žádá HTTPS doménu Prohlížeč nebo API klient se připojí na doménu a nabídne podporované verze TLS a algoritmy.
  2. Server prokáže identitu Server pošle certifikát a kryptograficky prokáže držení odpovídajícího soukromého klíče. Klient kontroluje řetězec důvěry, dobu platnosti i název domény.
  3. Dohoda klíčů Obě strany odvodí sdílené klíče pro konkrétní spojení. Následný přenos používá efektivní symetrické šifrování a kontrolu integrity.
  4. HTTP přes TLS Teprve nyní putují URL, hlavičky, cookies a tělo requestu chráněným kanálem k serveru nebo reverse proxy.
  5. Aplikační kontrola Backend i nad HTTPS ověří vstup, relaci či token a oprávnění uživatele. TLS tento krok neprovádí.

Hlavní části a pojmy

Certifikát, šifrování a životní cyklus jsou rozdílné věci.

Bezpečnost spojení závisí na správné konfiguraci serveru, klientovi i provozní disciplíně.

Certifikát a důvěryhodná autorita

Certifikát váže veřejný klíč na doménové jméno. Klient jej ověřuje pomocí důvěryhodného řetězce; samotné vlastnictví souboru s certifikátem není důkaz, že odpovídá právě požadované doméně.

Šifrování, integrita a autentizace serveru

TLS má bránit čtení i tajné změně dat po cestě a pro web obvykle ověřuje server vůči klientovi. Neznamená automaticky vzájemné ověření klienta; to vyžaduje mTLS nebo aplikační mechanismus.

TLS termination

TLS může skončit na CDN, load balanceru nebo nginxu. Následující hop k backendu není „automaticky HTTPS“ a je třeba vědět, kdo k němu má síťový přístup a zda se znovu šifruje.

HSTS a přesměrování

HTTP přesměrování vede uživatele na HTTPS. HSTS říká prohlížeči, aby při dalších návštěvách doménu používal rovnou přes HTTPS; zavádí se až po pečlivém ověření všech subdomén a certifikátů.

Mixed content

HTTPS stránka nesmí bez rozmyslu načítat aktivní zdroje přes HTTP. Nešifrovaný skript by mohl obejít ochranu celé stránky, i když je dokument sám doručen přes HTTPS.

Vztah k ostatním nástrojům

TLS chrání přenos, jiné vrstvy chrání význam operace.

Bezpečná webová aplikace potřebuje vedle HTTPS také bezpečný serverový návrh.

Reverse proxy a nginx
Často přijímají veřejné TLS spojení, drží certifikát a předávají bezpečně definovaný kontext backendu.
OAuth 2.0 a OpenID Connect
Protokoly pro přihlášení a delegované oprávnění spoléhají na bezpečný transport, ale samy řeší identitu a tokeny.
JWT
Token je nutné ověřit na serveru; HTTPS chrání jeho přenos, ne jeho oprávnění nebo dobu platnosti.
Content Security Policy
CSP omezuje chování prohlížeče po načtení stránky. HTTPS nebrání samo o sobě XSS ani načtení nevhodného povoleného skriptu.

Výhody a omezení

Nutná vrstva, která neřeší všechny bezpečnostní otázky.

Přínosy

  • ochrana důvěrnosti a integrity dat během přenosu
  • ověření identity serveru pro důvěryhodnou doménu
  • ochrana přihlášení, cookies, API tokenů a obsahu před běžným odposlechem v síti
  • předpoklad pro secure context a mnoho moderních webových funkcí

Omezení a časté chyby

  • HTTPS neodstraní XSS, SQL injection, chybnou autorizaci ani únik dat ze serveru
  • prošlý nebo špatně nasazený certifikát znepřístupní aplikaci klientům
  • TLS termination bez pochopení interního hopu může vytvořit nechráněnou část cesty
  • HSTS s includeSubDomains může poškodit subdoménu, která HTTPS neumí
  • nešifrovaný externí zdroj vytvoří mixed content nebo oslabí stránku

Kdy dává smysl

Pro veřejný web a službu komunikující přes nedůvěryhodnou síť.

HTTPS patří na web, administraci, API, webhook endpoint i integrační klientské volání. Nejde jen o hesla nebo platbu: URL, cookies, obsah odpovědi a tokeny mohou mít bezpečnostní nebo obchodní hodnotu. Stejná zásada platí pro interní cesty, pokud neodpovídají jasně vymezené důvěryhodné síti.

Pouhé „zelené HTTPS“ není audit celé aplikace. Vlastník systému musí řešit automatické obnovování certifikátů, monitoring expirace, bezpečnou konfiguraci serveru, redirecty a test kritických cest. Aplikace zároveň dál ověřuje uživatele a chrání citlivá data v klidu i ve zpracování.

Na co myslet

Bezpečné spojení je provozní závazek, ne jednorázové nastavení.

Konfigurace a životní cyklus certifikátu patří do monitorovaného nasazení.

  • vynucovat HTTPS a testovat redirecty pro běžné i citlivé cesty
  • automatizovat obnovu certifikátů a hlídat jejich dobu platnosti
  • používat současnou bezpečnou TLS konfiguraci podporovanou klienty aplikace
  • znát přesné místo TLS termination a zabezpečení dalšího hopu k backendu
  • odstranit mixed content a kontrolovat atribut Secure u citlivých cookies
  • zavádět HSTS až po ověření rozsahu domén a recovery postupu

Časté otázky

HTTPS, TLS a hranice jejich ochrany

Je HTTPS a TLS totéž?

HTTPS je použití HTTP přes TLS. TLS může chránit i jiné aplikační protokoly, například e-mailové nebo databázové spojení.

Ověřuje certifikát server nebo prohlížeč?

Server certifikát předkládá a prokazuje držení odpovídajícího soukromého klíče. Prohlížeč či jiný klient ověřuje jeho řetězec důvěry, platnost a shodu s doménou.

Stačí HTTPS k zabezpečení API?

Ne. HTTPS chrání přenos. API ještě musí ověřit token či jiný autentizační údaj, zkontrolovat oprávnění, validovat vstup a bezpečně pracovat s daty.

Má být HSTS vždy s includeSubDomains?

Jen když všechny současné i budoucí subdomény bezpečně podporují HTTPS. Jinak může prohlížeč zablokovat legitimní službu na subdoméně.

Jak řeším provozní bezpečnost

Bezpečný přenos spojuji s bezpečnými hranicemi aplikace.

Při vývoji backendů řeším HTTPS, veřejný vstup, API integrace i serverovou validaci jako navazující části jednoho provozního návrhu.

Zavolejte mi

Zavolám vám následující pracovní den mezi 9:00 a 17:00.

Můžete mi také zavolat rovnou.

+420 605 181 728

Nechte mi telefonní číslo a pošlete žádost o zpětné zavolání.

Odesláním souhlasíte se zpracováním údajů pro vyřízení žádosti.