Zkratka proTransport Layer Securityté-el-esTakéSSL, SSL/TLS, Transport Layer Security, TLS 1.3Pokročilý

Definice

TLS je kryptografický protokol, který nad spolehlivým spojením (typicky TCP) vytvoří šifnovaný kanál s ověřenou identitou serveru a kontrolou neporušenosti dat. Používá ho HTTPS, e-mailové protokoly, databázová spojení i VPN. Aktuální verze TLS 1.3 zkracuje úvodní handshake na jeden okruh zpráv a odstraňuje zastaralé šifrovací algoritmy.

Kategorie: Sítě a protokolyAktualizováno

Co TLS ve spojení zaručuje

TLS řeší tři nezávislé problémy najednou. Důvěrnost znamená, že odposlouchávající strana na cestě vidí jen šifrovaný tok. Integrita zajišťuje, že změněný nebo přehozený bajt spojení shodí místo toho, aby prošel nepozorovaně. Autentizace pomocí certifikátu dokládá, že protistrana skutečně vlastní doménu, na kterou se klient připojuje. Bez třetí vlastnosti by první dvě byly bezcenné: šifrované spojení s útočníkem uprostřed není k ničemu.

Co se odehraje při handshake

Handshake je úvodní vyjednávání, ve kterém se obě strany dohodnou na verzi protokolu, šifrovací sadě a společném klíči. V TLS 1.3 klient v prvním paketu pošle nabídku šifrovacích sad a rovnou i svůj podíl na výměně klíčů podle Diffie-Hellmana. Server odpoví svým podílem, certifikátem a podpisem, kterým dokazuje, že k certifikátu má privátní klíč. Od té chvíle obě strany odvodí stejné symetrické klíče a zbytek komunikace už jede rychlou symetrickou šifrou, typicky AES-GCM nebo ChaCha20-Poly1305.

Klíčová vlastnost se jmenuje forward secrecy: klíč relace se odvozuje z efemérních hodnot, které se po skončení spojení zahodí. Kdo si tedy dnes uloží zachycený provoz a za pět let se zmocní privátního klíče serveru, starý provoz stejně nerozšifruje.

Co přinesla verze 1.3

TLS 1.3 zkrátilo handshake z dvou okruhů na jeden, takže spojení se naváže znatelně dřív. Zároveň ze standardu vypadly RSA výměna klíčů bez forward secrecy, statické DH, komprese, renegociace a slabé hashe. Volba šifrovací sady je díky tomu mnohem méně prostoru pro chybnou konfiguraci.

Kde všude TLS běží kromě webu

Nejviditelnějším uživatelem je HTTPS, ale TLS chrání i SMTP a IMAP přes STARTTLS, spojení do PostgreSQL a Redisu, gRPC, MQTT nebo WebSocket ve variantě wss://. QUIC jde ještě dál: kryptografii TLS 1.3 má vestavěnou přímo v transportní vrstvě místo nad TCP.

Terminace a co se děje za ní

V produkci se TLS zpravidla ukončuje na okraji infrastruktury, na load balanceru nebo reverzní proxy. Dovnitř pak jde nešifrovaný HTTP provoz, což je přijatelné jen v důvěryhodné síti. Prostředí s vyššími nároky, například prostředí pod PCI DSS nebo servisní mesh v Kubernetes, proto zavádí mTLS: certifikát předkládá i klient, takže se obě strany ověřují navzájem.

Kde se TLS nejčastěji rozbije

Praktické problémy málokdy leží v kryptografii. Nejběžnější je propadlý certifikát, chybějící mezilehlý certifikát v řetězci (prohlížeč jej doplní z cache, ale mobilní aplikace nebo curl selže), nesoulad doménového jména se SAN položkami certifikátu a servery, které ještě nabízejí TLS 1.0 nebo 1.1. Automatická obnova certifikátu protokolem ACME a monitoring zbývající platnosti pokryjí většinu incidentů.

Příklady z praxe

  1. Chybějící mezilehlý certifikát projde v prohlížeči, ale rozbije integraci

    Nasazení nového certifikátu se v Chrome tváří v pořádku, protože prohlížeč si mezilehlý certifikát doplní z dřívějších návštěv. Platební brána volající API téhož serveru ale spadne na chybě ověření řetězce. Kontrola z příkazové řádky ukáže, že server posílá jen listový certifikát bez intermediate.

    openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts
  2. mTLS mezi službami v klastru

    Interní služba přijímá požadavky pouze od volajících, kteří předloží klientský certifikát podepsaný firemní CA. Konfigurace Nginxu vynutí ověření klienta, takže požadavek bez certifikátu skončí chybou 400 ještě před aplikací. Volající strana pak certifikát a klíč přikládá ke každému spojení.

    server {
      listen 443 ssl;
      ssl_certificate     /etc/tls/service.crt;
      ssl_certificate_key /etc/tls/service.key;
      ssl_protocols       TLSv1.2 TLSv1.3;
      ssl_client_certificate /etc/tls/company-ca.crt;
      ssl_verify_client   on;
    }

Časté omyly

MýtusSSL a TLS jsou dvě různé věci, my máme SSL certifikát.
Ve skutečnostiSSL je předchůdce TLS a všechny jeho verze jsou léta prohlášené za zastaralé. Název „SSL certifikát“ přežívá jen marketingově: stejný certifikát se používá v TLS a o protokolu nevypovídá nic.
MýtusZámeček v prohlížeči znamená, že web je bezpečný a důvěryhodný.
Ve skutečnostiZámeček dokládá jen šifrované spojení s držitelem dané domény. Phishingová stránka si certifikát pořídí zdarma za pár minut, takže o poctivosti provozovatele TLS neříká nic.
MýtusTLS zpomaluje aplikaci, takže interně stačí prostý HTTP.
Ve skutečnostiSymetrické šifrování dnes zvládá hardware prakticky zdarma a TLS 1.3 sráží režii handshake na jeden okruh. Provoz uvnitř sítě navíc bývá cílem útoku po prvním průniku, proto se prosazuje mTLS mezi službami.

Časté dotazy

Jak zjistím, jakou verzi TLS a šifrovací sadu server nabízí?
Verzi TLS ověříte přímo z příkazové řádky nástrojem openssl s_client, kterému vynutíte konkrétní verzi (například -tls1_2), a podle toho, zda spojení projde. Výstup zároveň ukáže dohodnutou šifrovací sadu a celý řetězec certifikátů. Pro pravidelnou kontrolu se hodí externí skener nebo vlastní monitoring, který hlídá i zbývající dny platnosti certifikátu. Podporu TLS 1.0 a 1.1 je vhodné vypnout: obě verze jsou vyřazené a jejich nabízení bývá první nález každého bezpečnostního auditu.
Potřebuji TLS i pro spojení mezi službami uvnitř vlastní sítě?
TLS uvnitř sítě dává smysl všude, kde tečou osobní údaje, přihlašovací tokeny nebo platební data. Model důvěryhodné vnitřní sítě selhává v okamžiku, kdy útočník získá přístup k jednomu kontejneru a začne odposlouchávat provoz ostatních. Servisní mesh v Kubernetes proto nasazuje mTLS automaticky včetně rotace certifikátů, takže aplikace o něm nemusí vědět. U jednodušších architektur stačí TLS ukončit na proxy a interní síť pečlivě izolovat.
Co se stane, když certifikátu vyprší platnost?
Po vypršení platnosti certifikátu klienti spojení odmítnou. Prohlížeč zobrazí varovnou stránku, kterou lze proklikat, ale mobilní aplikace, API klienti a cronové skripty selžou tvrdě a bez varování. Výpadek se proto typicky projeví nejdřív na integracích, nikoli na webu. Řešením je automatická obnova protokolem ACME plus nezávislý monitoring, který hlásí zbývající dny platnosti. Spoléhat na e-mailovou upomínku od vydavatele je riskantní, protože často míří na adresu, kterou už nikdo nečte.
Je Let's Encrypt certifikát méně bezpečný než placený?
Certifikát od Let's Encrypt používá stejnou kryptografii jako placené certifikáty a prohlížeč mezi nimi nedělá rozdíl. Liší se úroveň ověření: Let's Encrypt vydává pouze doménově ověřené certifikáty (DV), kdežto komerční vydavatelé nabízejí i ověření organizace (OV a EV). Vyšší úroveň dnes prohlížeče nijak vizuálně nezvýrazňují, takže její přínos je hlavně smluvní a auditní. Pro naprostou většinu webů a API je krátká platnost a automatická obnova spíš výhodou než nedostatkem.

Zdroje

  1. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3(otevře se v novém okně)IETF / RFC Editor, 2018
  2. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2(otevře se v novém okně)IETF / RFC Editor, 2008
  3. Transport Layer Security (TLS) - MDN Web Docs(otevře se v novém okně)Mozilla
  4. Transport Layer Security Cheat Sheet(otevře se v novém okně)OWASP

Související pojmy

Potřebujete to vyřešit v praxi?

Poradíme, jak na to ve vašem projektu

Vysvětlit pojem je jedna věc, navrhnout kolem něj funkční řešení druhá. Ozvěte se a probereme, co dává smysl u vás.