Hlavní navigace

Bettercrypto.org: společně za lepší šifrování

Ondřej Caletka 2. 2. 2015

Šifrované spojení je bezpochyby základem důvěrné komunikace v internetových sítích. Aby ale mohlo plnit svůj účel, je potřeba jej správně nastavit, což nemusí být vždy jednoduché. Proto vznikla bezpečnostní kuchařka, která radí, jak konfigurovat šifrování bezpečně a přitom pokud možno kompatibilně.

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.

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 AESCAMELIA 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ů.

Našli jste v článku chybu?

2. 2. 2015 16:44

A ještě můžu dodat, že standard připouští i předinstalované položky v cache HSTS serverů. Ale samozřejmě, zase se dá argumentovat tím, že tyhle položky může útočník během instalace zachytit a pozměnit. Hlavně ale zatím nejspíš není cesta, jak by se provozovatelé webů mohli nechat na podobný seznam zapsat.

2. 2. 2015 16:14

Jak je napsáno v článku: Pokud bude daná adresa uložena v cache HSTS serverů, prohlížeč se ani nepokusí navázat spojení na port 80. Pokud při spojení k portu 443 dojde na jakoukoli chybu TLS, prohlížeč odmítne chybu ignorovat.

120na80.cz: Bojíte se encefalitidy?

Bojíte se encefalitidy?

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Lupa.cz: Slevové šílenství je tu. Kde nakoupit na Black Friday?

Slevové šílenství je tu. Kde nakoupit na Black Friday?

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

Měšec.cz: Jak vymáhat výživné zadarmo?

Jak vymáhat výživné zadarmo?

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

120na80.cz: Rakovina oka. Jak ji poznáte?

Rakovina oka. Jak ji poznáte?

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Lupa.cz: Není sleva jako sleva. Jak obchodům nenaletět?

Není sleva jako sleva. Jak obchodům nenaletět?

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně