Zejména nedávné úniky dokumentů, popisujících masivní sledování občanů vládními institucemi nejrůznějších zemí světa, způsobily zvýšený zájem o šifrování. Samotný Edward Snowden šifrování totiž označil za jednu z cest, jak data před agenturami utajit:
Šifrování funguje. Dobře implementované silné šifrování je jedna z věcí, na kterou se můžete spolehnout. Bezpečnost koncových zařízení je však bohužel tak hrozně špatná, že NSA často dokáže najít cestu, jak šifrování obejít.
Problém je v tom, že zdaleka ne každé šifrování je nastaveno správně. K útoku pak není potřeba astronomický výkon pro hádání hrubou silou, ale je použit nějaký postranní kanál. Právě proto se bezpečnostní odborníci převážně z Rakouska a Německa spojili a pod značkou Bettercrypto.org sepisují příručku Applied Crypto Hardening. Ta je primárně určena systémovým administrátorům a radí jim, jak nastavit protokoly TLS, PGP a SSH u nejběžněji používáných internetových služeb. Přestože je dokument stále ve stádiu konceptu, je možné jej již dnes plnohodnotně použít.
Seriál vznikl za přispění Národního CSIRT týmu České republiky CSIRT.CZ, který provozuje sdružení CZ.NIC, správce české národní domény. CSIRT.CZ je bezpečnostní tým pro koordinaci řešení bezpečnostních incidentů v počítačových sítích provozovaných v České republice. Cílem jeho členů je pomáhat provozovatelům internetových sítí v České republice zřizovat jejich vlastní bezpečnostní týmy a bezpečnostní infrastrukturu, řešit bezpečnostní incidenty a tím zlepšovat bezpečnost jejich sítí i globálního internetu. Více informací na www.csirt.cz.
Neexistuje jedno správné nastavení
Problematika samozřejmě není zdaleka tak jednoduchá, aby stačilo jedno univerzální nastavení, které by mělo vyhovovat všem. Bezpečnost a kompatibilita jsou obvykle dvě strany téže mince, takže často není možné zajistit zároveň vysokou bezpečnost a velmi širokou kompatibilitu. Autoři proto předkládají dvě kompromisní řešení, označené jako A a B.
Varianta A nabízí větší bezpečnost při určitém omezení kompatibility. Hodí se tedy zejména pro privátní systémy, jejichž uživatelská základna je omezená. Varianta B je pak určena pro veřejně provozované služby. Stále nabízí slušné zabezpečení v porovnání s výchozí konfigurací OpenSSL, přitom ale bere ohled i na starší klientské systémy, které nemusí nejnovější šífrovací algoritmy a protokoly podporovat. Varianta B je také použita jako příklad v kuchařkové části příručky, protože se dá předpokládat, že bude vyhovovat nejširšímu spektru administrátorů.
Dopředná bezpečnost
Konfigurační volby TLS protokolu můžeme rozdělit do těchto kategorií:
- Algoritmus výměny klíče
- Autentizace
- Šifrování
- Integrita zpráv
Klíčovým požadavkem na algoritmus výměny klíče je dopředná bezpečnost (Perfect- Forward Secrecy). Ta označuje skutečnost, že sdílený klíč, kterým je šifrována daná relace, není zpětně odvoditelný z privátního klíče některé strany, takže není možné rozšifrovat zaznamenanou komunikaci ani v případě pozdější kompromitace privátních klíčů. Tuto vlastnost splňuje například Diffieho-Hellmanova výměna klíčů, jejíž princip krásně demonstruje následující video:
Problém je, že takováto výměna klíčů může být poměrně pomalá, zvláště na slabším hardwaru. Z toho důvodu se u TLS dlouhou dobu používala výměna klíče algoritmem RSA, která je sice rychlá, ale dopřednou bezpečnost nenabízí.
Pro autentizaci partnerů příručka doporučuje používat tradiční algoritmus RSA. K vlastnímu šifrování jsou doporučovány algoritmy AES a CAMELIA s délkou klíče alespoň 128 bitů. Pro kontrolu integrity zpráv počítá variana A s algoritmem SHA256 nebo lepším, varianta B z důvodu kompatibility připouští i SHA1. Je možné použít i šifrovací algoritmy se zabudovanou kontrolou itegrity (AEAD), jako například AES256-GCM.
Pozor na nedostatek entropie
Velký problém šifrování může představovat nekvalitní generátor náhodných čísel. Jde zejména o nejrůznější embedded zařízení a virtuální servery, které si během svého prvního startu generují například SSH klíče. Pokud takové zařízení nemá ani pevný disk, ani nezávislé hodiny reálného času, existuje poměrně velké riziko, že všechna podobná zařízení budou používat stejné série náhodných čísel, čímž je bezpečnost vygenerovaných klíčů oslabena.
Doporučuje se proto klíče pro takováto zařízení raději generovat externě na stroji s dostečnou mírou entropie (tu je možné na Linuxu sledovat v souboru /proc/sys/kernel/random/entropy_avail). Entropii je možné zlepšit také nástroji běžícími v uživatelském prostoru; zmíněn je například démon haveged. Ten implementuje algoritmus HAVEGE, který získává přídavnou entropii z vnitřních stavů procesoru.
Zajímavá je také zmínka o nevhodnosti použití DSA klíčů na strojích, kde se dá nedostatek entropie předpokládat. Na rozdíl od RSA totiž případné znovupoužití stejného klíče relace nevede jen k prozrazení obsahu šifrované komunikace, ale i ke kompromitaci DSA klíčů.
HTTP Strict Transport Security pro webové služby
K bezpečnějšímu šifrování nemusí nutně sloužit jen správné nastavení šifrovacích algoritmů. V poslední době se objevuje několik nových rozšíření, které mají jako společný cíl zvýšení důvěryhodnosti šifrovaných spojení. Nedávno jsme například psali o připichování certifikátů prostřednictvím DNS záznamů TLSA.
Další zajímavá možnost zvýšení bezpečnosti spočívá v speciální HTTPS hlavičce, která se snaží zvýšit bezpečnost šifrovaných webů přístupem TOFU, známým třeba z SSH. Webový server může do odpovědi na HTTPS požadavek vložit hlavičku, například:
Strict-Transport-Security: max-age=31536000; includeSubDomains Pokud takovou hlavičku přijme kompatibilní klient (většina majoritních desktopových prohlížečů), uloží si doménové jméno a případně i všechny subdomény na seznam serverů, u kterých je vynuceno šifrování po dobu uvedenou ve volbě max-age, ve výše uvedeném příkladu 365 dnů. Dokud je server na takovém seznamu uveden, odmítne prohlížeč jakýkoli pokus o navázání nešifrovaného HTTP spojení k danému serveru. Případné odkazy z jiných stránek na nešifrovanou variantu jsou přímo v prohlížeči automaticky přepsány na HTTPS . Je tak v podstatě vyloučeno na takovou stránku zaútočit útokem známým jako odstranění SSL.
Selhání TLS spojení na stránce s HSTS. Povšimněte si chybějícího tlačítka „Vím o co se jedná“.
Co víc, dojde-li u serveru, který je na seznamu důvěryhodných, k chybě TLS spojení, ať už je důvod jakýkoli, prohlížeč uživateli znemožní danou chybu ignorovat. To je na jednu stranu velká bezpečnostní výhoda, na druhou stranu to klade mnohem větší nároky na bezchybný přístup administrátorů. Pozor je třeba dát zejména na expiraci certifikátu. Rozhodně se zde tedy vyplatí zavést hlavičku nejprve zkušebně s krátkou životností a dobu života zvýšit až po důsledném otestování.
Kuchařka je připravena, pojďme vařit
Díky kuchařkové části příručky je velmi snadné doporučovaná nastavení jen zkopírovat do konfiguračních souborů příslušných serverů. V tuto chvíli jsou podporovány mimo jiné:
- Web servery: Apache, NGINX, Lighttpd, IIS
- E-mailové servery: Dovecot, cyrus, Postfix, Exim
- Databáze: MySQL, Oracle, PostgreSQL, DB2
- VPN servery: OpenVPN, Openswan, tinc
- SSH servery: OpenSSH, Cisco IOS
- IM servery: Prosody, ejabberd
Důležité je také správné nastavení otestovat. Kromě testování pomocí CLI utilit, jejichž použití je zmíněno vždy u konkrétní služby, je možné pro webové služby použít znamý tester Qualys SSL Labs, který vaší webové stránce udělí známku na základě zjištěných problémů.
