HTTPS

Co HTTPS přidává k HTTP

HTTPS zachovává význam požadavků a odpovědí HTTP, ale vkládá mezi aplikaci a síť šifrovanou vrstvu TLS. Prohlížeč proto neposílá URL cestu, hlavičky, cookies ani tělo formuláře jako čitelný text pro každý směrovač po cestě. HTTPS zároveň kontroluje, že přijatá data nebyla během přenosu změněna, a že server předkládá certifikát platný pro dané doménové jméno.

HTTPS není samostatný jazyk pro web. Rozdíl je ve schématu adresy https://, v použití portu obvykle vyhrazeného pro šifrovaný provoz a hlavně v navázání TLS spojení před samotným HTTP požadavkem. Po úspěšném handshake může nad stejným zabezpečeným kanálem běžet HTTP/1.1, HTTP/2 nebo jiná dohodnutá varianta.

Co se při navázání spojení ověřuje

Klient při připojení dostane od serveru certifikát a porovná v něm doménu s adresou, kterou uživatel otevřel. Klient také zkontroluje platnost certifikátu a řetězec důvěry vůči certifikační autoritě, kterou operační systém nebo prohlížeč uznává. Teprve potom si obě strany odvodí klíče pro šifrování konkrétní relace.

Serverový certifikát potvrzuje kontrolu nad jménem, ne morální kvalitu provozovatele. HTTPS tedy brání odposlechu a podvržení spojení, ale samo nerozezná podvodný obchod, špatně napsanou aplikaci nebo uniklé heslo. V citlivých systémech se někdy přidává i klientský certifikát, aby server ověřil také klienta.

Kde HTTPS končí v reálné infrastruktuře

HTTPS často nekončí přímo v aplikačním serveru. TLS může ukončit load balancer, CDN, reverse proxy nebo Kubernetes ingress. Za tímto bodem může provoz pokračovat interně jako HTTP, nebo se znovu šifrovat směrem k backendu. Důležité je vědět, kde leží hranice důvěry, kdo vidí nešifrovaná data a které logy mohou obsahovat citlivé údaje.

Aplikace za proxy musí správně rozpoznat původní schéma požadavku. Chybná konfigurace hlaviček typu X-Forwarded-Proto vede k absolutním odkazům s http://, k nesprávnému nastavení cookies nebo k nekonečným přesměrováním. Produkční proxy by měla předávat tyto informace jen z důvěryhodné vnitřní vrstvy.

Co HTTPS neřeší

HTTPS neopraví zranitelnost v aplikaci. SQL injection, XSS, slabé heslo, špatná autorizace nebo únik tokenu zůstávají problémem i na zeleném zámečku. HTTPS také běžně neskryje samotnou IP adresu cílového serveru a podle konfigurace může být částečně viditelné i jméno hostitele použité při navázání spojení.

Praktické situace s HTTPS

Přesměrování starých adres na bezpečnou variantu

E-shop po migraci ponechá staré odkazy s http://, protože je mají zákazníci v záložkách a vyhledávače v indexu. Server vrátí trvalé přesměrování na HTTPS a teprve zabezpečená odpověď nastaví cookies se značkou Secure. První nezabezpečený požadavek stále existuje, proto se po ověření nasazuje HSTS.

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

API za reverzní proxy

Mobilní aplikace volá API přes HTTPS, ale TLS končí na reverzní proxy před aplikačním serverem. Backend vidí lokální HTTP požadavek a při špatné konfiguraci vygeneruje odkaz pro reset hesla s nezabezpečeným schématem. Správné nastavení důvěryhodných forwarded hlaviček zajistí, že aplikace pozná původní veřejnou adresu.

Proč prohlížeč HTTPS někdy odmítne

Prohlížeč zobrazí varování, když certifikát vypršel, nepatří dané doméně, používá nedůvěryhodnou autoritu nebo je stránka složená z nebezpečných prvků načtených přes HTTP. Vývojové self-signed certifikáty patří do lokálního prostředí, ne před běžné uživatele. Ignorování varování v produkci ruší hlavní bezpečnostní přínos HTTPS.