Hlavní navigace

Věříte opravdu jen důvěryhodným certifikačním autoritám?

23. 8. 2010
Doba čtení: 3 minuty

Sdílet

Electronic Frontier Foundation ohlásil projekt SSL Observatory, který sleduje veřejně viditelné SSL/TLS certifikáty. Závěr není lichotivý – i když si dokážete vybrat kořenové certifikační autority, tranzitivní důvěra v SSL/TLS modelu způsobí, že budete důvěřovat někomu, komu byste jinak nedůvěřovali.

Electronic Frontier Foundation ohlásil projekt SSL Observatory, který spočívá ve sledování věřejně viditelných SSL/TLS certifikátů na věřejně dostupných strojích. Je zatím dostupná prezentace (PDF), později i MySQL databáze s nasbíranými certifikáty přes BitTorrent. Výsledek několikaměsíčního sběru certifikátů lze shrnout asi následovně:

Mírně bulvárně: největší absurdity

  • „pravé“ 192.168.1.2 je podle US Equifaxu v Texasu; podle belgického GlobalSign je v USA, UK, Švýcarsku a Belgii, i s dvojí identitou jako 77.76.108.82
  • doménové jméno localhost je podepsáno více než 6000krát různými CA (člověk by doufal, že si vedou nějaký záznam, co už podepsali)
  • cca 28 000 podepsaných certifikátů vygenerovaných bugovitým OpenSSL v Debianu, naštěstí jenom asi 500 validních (důsledek nízké entropie při generování klíče)

Skutečné zranitelnosti

Po troše bulváru a jiných nezaměnitelných znaků člověčenstva se podíváme na skutečné problémy. Závažné chyby schématu spočívají v takzvaných intermediate CAs, což jsou certifikační autority, jejichž kořenový certifikát nenaleznete přímo v prohlížeči nebo keystoru, nýbrž jsou důvěryhodnými kořenovými CA podepsány.

Jádro problému spočívá v X509v3 rozšíření BasicConstraints: CA: TRUE. Rozšíření BasicConstraints společně s rozšířením KeyUsage: Certificate Signing umožňuje nějaké certifikační autoritě (které explicitně nemusíte věřit) podepsat libovolné doménové jméno (finta spočívá v tom, že důvěra není tranzitivní, jak to předpokládá SSL/TLS PKI model). Chyba schématu je umocněna faktem, že existují spousty společností, které mají vlastní intermediate CA (Google, Microsoft, Dell, Ford…).

Konkrétní příklad

Nejlépe konkrétní příklad – vezmeme si certificate chain na https://www.e­tisalat.ae (doporučuji zadat si tohle doménové jméno do SSL Labs testovače a podívat se na výsledky).

Certificate chain vypadá následovně (kromě spousty jiných „drobných“ vad jako povolené slabé symetrické šifry se třeba v Opeře ukazuje nesprávné pořadí certifikátu v chainu, protože server ho posílá ve špatném pořadí):

GTE CyberTrust Global Root (serial 0x1a5, SHA1 fingerprint 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74)
  \- Comtrust Root Certification Authority; basic constraints: CA:true; O: Etisalat
      \- Comtrust Server Certification Authority; basic constraints: CA:true; O: Etisalat
            \- www.etisalat.ae

Výše uveden certificate chain říká jednu zásadní věc: mobilní operátor Etisalat umí ve své síti udělat SSL MITM a každý mu bude důvěřovat (protože certifikát GTE CyberTrust Global Root je součástí Firefoxu, Opery, Windows, Androidu, …). Totéž umí udělat libovolná intermediate CA, bez toho, abyste jí přímo věřili. Historický Internet Explorer 5.0 nekontroloval ani BasicConstraints, proto původně vznikl nástroj sslsniff. S nástrojem jako sslsniff není potřeba žádné chyby prohlížeče, když podvádí intermediate CA – prostě podepíše libovolné doménové jméno (viz níže – Etisalat je již z podvádění usvědčena).

root_podpora

Zakazované BlackBerry, Android/iPhone projde

Možná jste si všimli i v mainstream médiích, jak se postupně nabalovaly různé státy, které se snažily buďto zakázat BlackBerry zprávy nebo je omezit (Spojené arabské emiráty, Saudská Arábie, Indie aj.). Důvodem je, že BlackBerry nelze ani přes triky s intermediate CA donutit ke kompromitaci zpráv (BlackBerry messaging service je navržen jinak než SSL/TLS PKI model). Možnost kompromitace SSL nezávisí na platformě (je jedno, zda máte Android/iPhone/Li­nux/Windows). Certifikát operátora Etisalat nebyl vybrán náhodně, je to operátor, který se již snažil prosadit spyware na BlackBerry komunikátory. Paradoxně se na to přišlo, protože „odposlouchávací služba“ nezvládla nápor zařízení a BlackBerry se pořád pokoušelo v cyklu připojit, což se projevilo postranním kanálem jako výrazně snížená výdrž baterie telefonu.

Jak se bránit

Hrozbě intermediate CAs se nelze jednoduše vyhnout (i lidé, kteří toho vědí mnohem víc než já, se neurčitě zašklebí a zahlásí, že „SSL/TLS PKI model is broken“). Pořád lze alespoň mírně snížit riziko:

  • Obecně: v prohlížečích smazat nebo nastavit na nedůvěryhodné certifikáty jako GTE CyberTrust Global Root, pak všechny který obsahují frázi „government CA“ v libovolné permutaci libovolného zemi – zní to hodně neurčitě, ale třeba Taiwanskou státní CA nebo Nizozemskou státní CA nejspíš nikdy nebudete potřebovat (já vím, pořád žádná výhra, nikdo neví jaké CA zvolit, záleží jedině na individuálním paranoidním nastavení; zvolte jako důvěryhodné CA certifikáty používané ty, které používá vaše banka nebo běžně používané služby)
  • Firefox: použijte rozšíření Certificate Patrol, jeho účinnost spočívá v tom, že pozná, když se certificate chain změní, budete o tom vědět
  • Opera: v nastaveních Advanced-Security-Manage Certificates-tab Authorities-vybrat CA+klik View-Warn me before using this certificate
  • Android: rootnout telefon, přes adb pull a adb push získat, vyfiltrovat a uložit certstore, je uložen v /system/etc/security/cacerts.bks.

Měníte důvěryhodné CA ve svém systému?

  • Ano, vytvářím si vlastní seznam
    5 %
  • Ano, některé mažu
    7 %
  • Ne, nechávám přednastavené
    88 %

Byl pro vás článek přínosný?

Autor článku

Autor textu pracuje jako programátor pro výzkum a vývoj v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.