Ne bezpečnost SSL

Na abclinuxu.cz se pod článkem o software fail2ban rozhořela (zatím) věcná a rozsáhá diskuse. V rámci této diskuse přišlo slovo i na téma ssl (hmm, koukám, že na wiki spojili SSL a TLS, no potěš) a souvisejících věcí. V tomto článku bych chtěl vypíchnout konkrétní (ale anonymizované) příklady z praxe, kde podle mého názoru dochází k flagrantnímu porušování zásad bezpečnosti (nejen) ssl.

Před cca měsícem byla zvěřejněna zranitelnost konkrétní implementace TLS pojmenovaná jako HeartBleed. Oprava knihovny OpenSSL byla vydána poměrně rychle pro všechny postižené systémy a díky práci adminů také relativně rychle odstraněna z postižených systémů. (Ostatně takto se postupuje v případě všech zranitelností a je to obrovká výhoda opensource — oprava a nasazení je vyřešeno velmi rychle, nečeká se na updatovací termín jak je tomu u některých komerčních produktů a už vůbec ne na (ne)zájem zákazníků — ano, i na opravách security chyb ve vlastních produktech někteří chtějí vydělávat).

Ovšem, co už tak ukázkově neproběhlo (a je to chronický problém, o tom se rozepíšu dále) byla výměna klíčů certifikátů u postižených serverů. Většina autorit velmi pružně nabídla tzv. reissue certifikátů zdarma. Skutečně lidé na toto reagovali, generovali se nové klíče pro nové CSR. V tomto až takový problém nebyl (samozřejmě, „rychlost“ s jakou někteří (ne)reagují je sama o sobě zarážející, ale to není tématem článku).

Problém nastává později, kdy dochází k vypršení platnosti certifikátů a je nutné je obnovit (standardní renew). Tady se v praxi velmi často vyskytují případy, kdy je pro obnovený certifikát použit stejný klíč, jaky byl před opravou HeartBleed. Je to zásadní porušení zásad, obecně lze doporučit pro každý nový certifikát použít nový klíč. (S každou žádostí o certifikát — CSR — generovat nový pár klíčů.) (Pozn.: Tohle se pochopitelně netýká systémů, které mají soukromé klíče na nějakém HSM, ale v takovém případě se o bezpečnost většinou dbá a nejsou cílovou skupinou tohoto článku.)

Jistou část viny na tom nesou i CA, které v rozhranní pro obnovení certifikátu nabízejí použít původní CSR (ten, který byl při zadán při objednání) a nikoliv alespoň CSR z procesu Reissue. Podle mého názoru by měly trvat na zadání zcela nového CSR a pokud zákazník použije původní kompromitovaný klíč, nese za to plnou odpovědnost.

Když už jsme u těch autorit, tak po zkušenostech z praxe mi nikdo nevymluví názor, že se jedná pouze o výběrčí poplatků za to, že jejich kořenový certifikát distribuují někteří výrobci prohlížečů. O bezpečnost vůbec nejde.

Ověřování většiny vystavených certifikátů (těch nejlevějších, které ale i tak stojí min. několik stovek, většinou přes tisíc korun, probíhá tak, že na email na dané doméně přijde potvrzovací zpráva, je nutné kliknout na odkaz a stisknout tlačítko approve. Nic víc. Tedy stačí mít přístup k poště na doméně, pro kterou chceme získat certifikát a máme ho.

Možná si říkáte, že se k poště jen tak někdo nedostane. Omyl. Většina, i poměrně důležitých institucí, má své služby u mnoha různých poskytovatelů. Některé instituce v tom mají takový nepořádek, že dokonce sami neví, u koho danou službu mají. Tedy k emailům se reálně dostane téměř kdokoliv (kdo má dostatečný zájem). To ani nechci otevírat téma, že ten email není šifrovaný, takže i po cestě internetem na každém routeru je možné si ten obsah přečíst (a dostat se tak k mnohem zajímavějším informacím, než je jen odkaz na potvrzení vystavení certifikátu).

Pochopitelně existují i dražší a lépe „ověřované“ typy certifikátů. Nejdražší certifikát, co jsem zatím zařizoval, stál hodně přes 10 tis. korun, se ověřoval telefonicky s CA. To probíhá tak, že vám zavolá operátor a snaží se vás nějak ověřit. Což většinou probíhá v angličtině. V tomto případě jsem na jedné straně linky seděl já, který v mluvené konverzaci v angličtině nijak nevynikám (no, je to katastrofa, co si budeme povídat) a na druhé straně dle přízvuku asi nějaká pakistánka (která byla nejspíš ráda, že našla alepoň nějakou práci). Ona nerozuměla mě, já jsem nerozuměl jí (ani jedna strana si nemohla být jistá s kým hovoří). Certifikát byl vystaven, stačilo říct město sídla firmy. Nic víc. Co byste také za více než 10 tis. korun chtěli, že.

Aby toho nebylo málo, tak v případě reissue tohoto certifikátu po chybě heartbleed neproběhlo už ověřování vůbec žádné. Tedy pokud by útočník vychytal správný okamžik, tak se mohl v rámci reissue akce dostat k velmi zajímavým kouskům.

Když už tady mluvím o autoritách a ověřování, tak nejlepší ověření (dva doklady totožnosti a ověření dvěma lidmi) mám u autority, která nikdy nebude v seznamech prohlížečů. Takže certifikáty vystavené pro mě nejdůvěryhodnější (externí, nejdůvěryhodnější je pro mě má vlastní autorita kterou spravuji) autoritou jsou pro veřejné použití prakticky nepoužitelné.

Podívejme se na samotné generování klíčů. Nejprve jak by to mělo být: na místě, pro které požadujeme certifikát (pro příklad webserver) se vygeneruje pár klíčů (soukromý a veřejný). Veřejný se použije pro CSR (resp CSR obsahuje veřejný klíč), toto CSR se pošle na autoritu, ta to podepíše a vrátí certifikát. Soukromý klíč zůstává na místě, není nutné ani žádoucí, aby to místo opustil. Tento způsob, kromě toho, že je nejbezpečnější, je i nejjednodušší. (Dva kroky: CSR –>CA –> CRT, finito).

Jenže v praxi. V praxi to vypadá tak, že klíč generuje někdo na svém pracovním počítači a po kolečku s autoritou řeší, jak to dostat na server (typicky zase u nějakého dodavatele). A jsme zase u emailů. Tento někdo pošle certifikát a klíč emailem (ano, skutečně prostě jako přílohu), někdo jako zip s heslem (hesla jsou i jednoznaková). Tedy přístup ke klíči má kde kdo, a celé požadované zabezpečení je … víte kde.

Dalším typickým příkladem jsou wildcard certifikáty s platností na všechny poddomény dané domény. (*.doména.cz) Jsou instituce, které mají (proč nechme stranou) 50 webů (na jedné hlavní doméně) a jak to tak chodí, tak u 40 dodavatelů (ne, nepřeháním, některé instituce mají skutečně desítky dodatavelů IT služeb). Tedy, když už někdo, i kdyby nakrásně dodržel všechny zásady, vygeneruje klíč a získá bezpečnou cestou certifikát, tento klíč je nutné rozdistribuovat mezi desítky dodavatelů. A stačí jen jeden nepoctivý a může si kdykoliv udělat 51. web se zcela validním, naleštěným a drahým certifikátem na doméně instituce a návštěvníci webu tak nebudou mít nejmenší podezření a s klidem například zadají svoje přihlašovací údaje k systémům dané instituce (MITM, Phishing).

Proč se tak chovají? Někdy je to tak, že přijde nějaké nařízení (strany a vlády), že je nutné okamžitě cosi nasadit. Takže potom přicházejí požadavky „my tam chceme to https“. Ono, mezi námi, to nemusí být rovnou veřejná instituce podlehající manýrům ministrů, toto se velmi často děje i na soukromé úrovni (slyšel jsem, že https / dkim / spf / atp. je dobrý tak to tam chci ale nechci o tom vůbec nic vědět ani pro to nic udělat), ale nebudu příliš rýpat.

Takže se tam prostě nasadí https. Finito. ;-) To, že se to „https“ i na straně serveru musí nějak nastavit (protože ne všechny šifry podporované serverem i klienty jsou stejně bezpečné a ne všechny protokoly jsou vhodné), už se obvykle neřeší. „Řeklo se https, tak udělej https a neptej se tak blbě.“

Dalším zajímavým tématem je víra na security through obscurity. A to už se obloukem dostávám k tématu článku o fail2ban. Jsou lidé, kteří místo toho, aby věc udělali správně (a v případě počítačových technologií a konrétně SSL a PKI se poměrně dobře ví, co je to správně), tak vymýšlejí různé způsoby, jak to obejít.

Většinou jsou k tomu používány zástupné důvody jako útoky na ssh mi plní logy apod. Problémy by se měly řešit tam, kde vznikají. Pokud má někdo problém s přílišným počtem záznamů v logu, musí se to vyřešit na straně logu. Číslo portu (oblíbená to technika pro zabránění útokům na ssh je změna čísla portu ze standardního 22 na nějaký jiný) opravdu s logy žádným způsobem nesouvisí. A mimo to, že tyto techniky nijak bezpečnost nezvyšují, tak brání řádnému použití služby. Tedy, obešla se bezpečnost, „vyřešil“ se nesouvisející problém (například ono zmíněné logování nezdařených přístupů) a ještě se stížila práce těm, kteří tam ten přístup mít mají.

Jak už jsem psal u posílání klíčů, ono to nejbezpečnější řešení je současně tím nejjednodušším. Lze nastavit přístup pomocí klíčů (u ssh je to zcela běžné, u ostatních služeb, snad s vyjímkou CACert a některých bank s přístupem přes „čipovku“, se to moc často nevidí). Přístup s klíčem je velmi pohodlný na použití (při prvním použití klíče je třeba zadat jeho heslo, vzhledem k tomu, že je jen jedno, tak to heslo může být velmi složité) a potom už je přístup do všech systému zcela volný (z hlediska uživatele) a současně je tento systém tím nejbezpečnějším, co lze použít.

Opět, v praxi se potom setkáváme s miliony zástupných důvodů, proč klíče nelze použít a současně proč heslo musí být krátké (aktuální doporučení je mít heslo s entropií min. 112b, což je poměrně šílených 24 znaků — celkem přirozeně si nikdo nebude schopen pamatovat pro každý systém takto kvalitní heslo. (Proto také existují systémy pro bezpečné generování i uchovávání hesel, pro příznivce unixového světa je to třeba pass).

Jinak, já nemám nic proti dalším systémům obrany. I před dokonale zabezpečenou službou klidně může být firewall, i před dokonale zabezpečnou službou klidně může být systém na omezení přihlášení. Ale nejdůležitější ze všeho je, aby tyto systémy byly nasazeny s cílem ještě zvýšit bezpečnost a ne jako pokus o obejití toho, že ten vnitřní systém je zbastlený, nebezpečný a nikdo se nechce jeho zabezpečení věnovat (ano, i hlášky typu to neupdatuj, to nikdo nezaplatí, lze slyšet nebo naopak to teď neupdatuj, musíme na tom makat a nelze to přerušovat).

To bylo několik příkladů z praxe, které se reálně staly. Neověřování při vystavení certifikátů ze strany CA, zasílání klíčů v emailech, nedostatečná výměna klíčů po opravě serveru, výmluvy proč to nelze dělat bezpečně apod. Přísahám, že vše se skutečně stalo.

Cílem tohoto článku ale nebylo se o někoho otírat a tak prosím lidi v mém okolí, kteří by se případně v některých popisovaných událostech poznali, aby místo případné záště, kterou možná cítí se zamysleli nad tím, jak ty věci dělat lépe. Bezpečně a zároveň i jednodušeji a s menším počtem komponent.