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čí.
- Klient žádá HTTPS doménu Prohlížeč nebo API klient se připojí na doménu a nabídne podporované verze TLS a algoritmy.
- 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.
- 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.
- 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.
- 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.