-
Notifications
You must be signed in to change notification settings - Fork 0
TLS a HTTPS
Reverse proxy je z velké části správa TLS, takže bez téhle stránky nedávají ty další smysl. Nejde tu o kryptografii, ale o věci, které tě reálně potkají v konfiguraci.
Tři věci naráz, a je užitečné je oddělovat:
Šifrování — nikdo po cestě nepřečte obsah.
Integrita — nikdo po cestě obsah nezmění, aniž by to bylo poznat.
Autenticita — mluvíš se serverem, za který se vydává. Tohle dělá certifikát a je to ta část, která nejčastěji zlobí.
Šifrování bez autenticity je k ničemu. Kdyby ti stačilo šifrování, útočník se prostě postaví doprostřed a šifruje s tebou sám.
sequenceDiagram
participant K as Klient
participant S as Server
K->>S: ClientHello (umím tyto šifry, chci doménu X)
S->>K: ServerHello + certifikát
K->>K: ověří podpis proti CA a datum platnosti
K->>S: výměna klíčů
Note over K,S: dál je vše šifrované
K->>S: GET / HTTP/1.1
To „chci doménu X" v prvním kroku je SNI a je klíčové pro pochopení reverse proxy.
Na jedné IP adrese může běžet sto webů. Server ale musí vybrat certifikát dřív, než se spojení zašifruje a než uvidí HTTP hlavičku Host.
Řeší to SNI: klient v úvodním nešifrovaném pozdravu pošle jméno domény, na kterou se chce připojit. Podle toho server vybere certifikát.
Praktické důsledky:
Jméno domény jde po drátě nešifrovaně. Obsah nikdo nepřečte, ale to, na které weby chodíš, ano. Řeší to až Encrypted Client Hello, které se teprve nasazuje.
Reverse proxy může podle SNI rozhodovat, aniž by TLS rozbalovala. Tomu se říká SNI routing.
Bez SNI dostaneš výchozí certifikát. Když se připojíš na IP adresu místo na jméno, server neví, co chceš, a pošle první certifikát v pořadí — proto to varování v prohlížeči.
Certifikát sám o sobě nic nedokazuje. Důvěra se odvozuje řetězem:
kořenová CA (v prohlížeči a v OS)
└── mezilehlá CA
└── tvůj certifikát pro example.cz
Server musí poslat svůj certifikát i mezilehlé. Kořenový ne, ten už klient má.
Tohle je nejčastější chyba při ručním nasazení certifikátů. Projeví se tak, že web funguje v prohlížeči na desktopu (ten si mezilehlý certifikát domyslí z keše) a nefunguje v curl, na mobilu nebo v jiné aplikaci.
Ověř si to:
openssl s_client -connect example.cz:443 -servername example.cz < /dev/nullV hlavičce výstupu je Certificate chain — musí tam být víc než jedna položka. A na konci Verify return code: 0 (ok).
Online kontrola: ssllabs.com/ssltest, která ti ukáže i „chain issues".
Caddy a Traefik tenhle problém nemají, protože řetěz sestavují samy.
Jednoduše: TLS 1.2 a 1.3, nic staršího. TLS 1.0 a 1.1 jsou vyřazené, SSL v jakékoliv verzi je prolomené.
Rozumná konfigurace pro nginx:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;U TLS 1.3 se seznam šifer neladí — protokol nabízí jen bezpečné. To ssl_prefer_server_ciphers off je dnes doporučení, protože klient obvykle ví lépe, co má hardwarově akcelerované.
Generátor konfigurací pro všechny běžné servery: ssl-config.mozilla.org.
Hlavička, kterou serveru řekneš prohlížeči „na tuhle doménu chodím vždycky přes HTTPS":
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Chrání proti útoku, kdy tě někdo při prvním requestu na http:// přesměruje jinam.
Pozor na includeSubDomains. Platí to na rok a prohlížeč si to zapamatuje. Když máš pod doménou něco, co běží jen na HTTP, přestane to fungovat a nedá se to jednoduše vzít zpět. Nasazuj nejdřív s krátkým max-age, třeba 300, a zvyšuj až po ověření.
Reverse proxy TLS obvykle ukončí a dovnitř posílá nešifrované HTTP. Je to standardní a v důvěryhodné síti v pořádku — vnitřní provoz mezi proxy a aplikací neopouští stroj nebo důvěryhodný segment.
Alternativy:
TLS passthrough — proxy nerozbaluje, jen podle SNI přepošle dál. Nutné, když aplikace potřebuje vidět klientský certifikát.
Re-encrypt — proxy rozbalí a k aplikaci naváže nové TLS. Užitečné, když provoz jde přes nedůvěryhodnou síť, třeba mezi VM na různých hostitelích.
Pro homelab je ukončení na proxy správná volba.
„NET::ERR_CERT_AUTHORITY_INVALID" → chybí mezilehlý certifikát, nebo je certifikát podepsaný sám sebou.
Funguje v prohlížeči, ne v curl → skoro vždycky chybějící mezilehlý certifikát.
„certificate has expired" → neproběhla obnova. Viz certifikáty a Let's Encrypt.
Aplikace generuje odkazy s http:// → aplikace neví, že běží za proxy. Chybí hlavička X-Forwarded-Proto, viz reverse proxy.
Přesměrovací smyčka → proxy přesměrovává na HTTPS a aplikace taky, přičemž aplikace vidí interní HTTP a myslí si, že je potřeba přesměrovat znovu. Řeší se stejnou hlavičkou.
Našel jsi chybu nebo něco chybí? Založ issue nebo pošli pull request. — Psáno 2026, licence CC BY-SA 4.0
Základy
- Cesta paketu
- Vrstvy a zapouzdření
- MAC, ARP a přepínání
- Prefixy a masky
- Směrování
- DHCP a DNS
- Porty a spojení
- NAT a port forwarding
Domácí síť
IPv6
Linux firewall
TLS a reverse proxy
- TLS a HTTPS
- HTTP, QUIC a WebSocket
- Reverse proxy
- Caddy
- Nginx
- Traefik
- Certifikáty a Let's Encrypt
- Vlastní certifikační autorita
Kryptografie
- Stavební kameny
- Veřejný a soukromý klíč
- Diffie-Hellman
- Hashe, HMAC a podpisy
- Náhodnost a entropie
- TLS handshake
- Postkvantová kryptografie
- Šifrování disků a souborů
Virtualizace a kontejnery
Diagnostika
Vzdálený přístup
Provoz a bezpečnost
Praxe