V posledních měsících se často hovoří o důvěryhodnosti CA. O situaci jsme už psali v článku SSL divočina aneb jak se chovají „důvěryhodné“ CA. Výzkumníci v oblasti počítačové bezpečnosti naštěstí již před nějakou dobou začali navrhovat protokoly, které mají zabránit problémům způsobeným útoky na Comodo, DigiNotar nebo jinou CA. Navíc se objevila i certifikační autorita, která vydávala certifikáty pro man-in-the-middle útoky: co se s ní stane a jaký bude precedens do budoucna?
A prvním vítězem Miss MitM se stává…
Prvním držitelem titulu „CA vydávající certifikáty pro MitM“ se stává Trustwave. Je to první CA o které vím, že se „přiznala“ k vydávání sub-CA MitM certifikátů v minulosti (momentálně by měly být tyto sub-CA certifikáty revokovány). Pro MitM použila eufemismus „managing encrypted traffic for enterprises“ (nebude ale zdaleka jediná CA). Ve stejném vlákně pak zástupci GlobalSign a Comodo tvrdí, že vždy podobné požadavky od společností zamítly. Mozilla v novém programu požaduje, aby CA ukázaly všechny vydané sub-CA certifikáty. Lhát zde pro CA znamená dost velký risk – kdyby se na to přišlo, CA bude pravděpodobně odstraněna (a nepomůže jí ani vymáhání škody u soudu). Mozilla již řeší, jestli certifikáty Trustwave odstranit a jaký bude precedens pro podobné případy (velmi dlouhé a „výbušné“ vlákno).
Díval jsem se do své DB, jaké sub-CA Trustwave má. Našel jsem jednu, Micros CA (v SSL Observatory DB jsem nenašel žádnou). Ta ale nejspíš nebude ta správná (certifikát není revokován). Pravděpodobně nebude jednoduché najít MitM certifikáty obíhající „in-the-wild“. Trustwave má navíc v CPS uvedeno, že neručí za to, co s nimi budou třetí strany dělat (nezapomněli zapnut capslock, když tu větu psali).
Za poslední rok se objevilo několik nových protokolů, které by měli nedůsledným a nebezpečným CA zakázat vydávání certifikátů pro libovolné DNS jméno: DANE, Sovereign Keys, Auditable CAs, Mutually Endorsing CA Infrastructure (obecně zavádějí techniku certificate pinning). Pro úplnost zmíním ještě CAA, ale to je jenom takové „doporučení“ pro CA, tudíž neúčinné.
DANE
Protokol DANE v IETF zaštiťuje Google a CZ.NIC. Snad se ho podaří brzy dotlačit do finální fáze, zatím se můžete podívat na aktuální draft. DANE umožňuje provozovatelům TLS služeb k doménovému jménu vytvořit v DNS TLSA záznam určující certifikát služby (pro trojici FQDN, protokol a port). Přiřadit certifikát lze jednou z následovných možností, tzv. certificate usage:
- usage 0: řetězec musí projít PKIX validací u klienta a musí jít přes certifikát v TLSA
- usage 1: řetězec musí projít PKIX validací u klienta a serverový certifikát musí souhlasit s certifikátem v TLSA
- usage 2: řetězec musí projít PKIX validací když certifikát v TLSA použijeme jako trust anchor
- usage 3: serverový certifikát musí odpovídat certifikátu v TLSA
První dvě možnosti lze volně popsat jako restrikci aktuálního stavu: klient udělá validaci, ale navíc zamítne jakýkoliv řetězec neodpovídající TLSA záznamu. Usage 2 umožňuje udělat si „vlastní CA“ a poslední například použít self-signed certifikát. V praxi se poslední dvě možnosti až tak neliší, šlo o „kompatibilitu“ s RFC 5280 a definicí PKIX validace.
Druhý parametr TLSA záznamu je selector – říká která část certifikátu se kontroluje:
- selector 0: celý certifikát
- selector 1: veřejný klíč (SubjectPublicKeyInfo)
Posledním parametrem je matching type, jak se porovnává certifikát z řetězce proti datům z TLSA záznamu:
- matching type 0: kontrola bajt po bajtu na vybrané části
- matching type 1: SHA-256 vybrané části
- matching type 2: SHA-512 vybrané části
Důležitým požadavkem je, že TLSA záznam musí být podepsán DNSSEC-em (jinak by to příliš nemělo smysl).
Příklad použití TLSA záznamu
Mějme webserver s TLS (HTTPS) na adrese labs.nic.cz, portu 443. Když se prohlížeč připojí, vyžádá si od DNS TLSA záznamy jmenující se _443._tcp.labs.nic.cz. Ten by vypadal následovně:
_443._tcp.labs.nic.cz. IN TLSA 1 0 1 62f1221d586e9485d832768c9634afd9dedb64120d8502a0dabcb41511764a2e
Pořadí parametrů v TLSA je usage selector matching data, tudíž klient ověří, jestli serverový certifikát labs.nic.cz má SHA-256 hash 62f1221d586e9485d832768c9634afd9dedb64120d8502a0dabcb41511764a2e. Prakticky si s TLSA záznamy můžete pohrát použitím nástroje swede.
I když základní idea je velmi jednoduchá a jasná, existují „patologické případy“ např. s wildcard doménami nebo SRV záznamy. Další trochou nedeterminismu přispívá způsob vytváření řetězců v různých klientech (můžou používat cachované, měnit je, apod.).
Existuje i DNSSEC stapling implementován jako experimentální featura Chrome. Výhodou DNSSEC staplingu (podobně jako u OCSP staplingu) je lepší soukromí a rychlost (nemusí se dělat extra request na DNS servery). Nevýhoda je složitější implementace na straně klienta i serveru.
Sovereign Keys
Návrh Sovereign Keys (dále jen SK) pochází od Petera Eckersleyho z EFF. Může stavět na DANE, nebo být paralela DANE. Je to taky certificate pinning protokol, i když možná trocha přesnější název by byl key pinning protokol. Dvě definující vlastnosti SK jsou:
- k doménovému jménu je přiřazen klíč (ECC nebo RSA) – tento klíč je nazván Sovereign Key a slouží na podepisování serverových certifikátů
- existuje nefalšovatelná monotonní timeline říkající který klíč byl pro kterou doménu vydán
Timeline je udržována na několika timeline serverech (např. 20) a kopie jsou kvůli lepší dostupnosti uloženy na zrcadlech. Pokud je alespoň jeden timeline server poctivý, podvádění lze odhalit. Finální návrh implementace timeline serveru zatím není, uvažuje se například i o použití podobné struktury jako je blockchain v bitcoinu. Každý timeline server má svůj klíč, kterým podepisuje timeline. Timeline serveru se lze ptát buďto na kompletní kopii timeline, nebo jen na nějakou část. Klíče timeline serverů se budou distribuovat společně s kódem klientů.
Struktury použité v SK jsou v následovné tabulce:
Účel Typ Položka Odhadovaná entropie (v bitech)
--------------------------------------------------------------------------------
Monotonicita uint64_t : serial number 0
uint64_t : timestamp 25
--------------------------------------------------------------------------------
Sovereign Key char[256] : name 50
bool : wildcard 1
char[] : key type 0.5
char[] : sovereign_pubkey 224-256 (za předpokladu ECC)
char[] : protocols 10
uint64_t : expires on 25
--------------------------------------------------------------------------------
V případě char[][] : inheriting name(s) 50
revokace
--------------------------------------------------------------------------------
Důkaz vlastnictví char[] : cacertchain 9000-1300 (256 pro hash)
Sovereign Key char[] : DNSSEC_evidence ?
char[] : claim_signature 1024-2048
--------------------------------------------------------------------------------
Podpis timeline char[] : signature 224-256
Důkaz vlastnictví SK může být buď řetězec certifikátů vydaný od CA (ale jiný než ten serverový řetězec), který obsahuje ECC/RSA klíč v SubjectPublicKeyInfo listového certifikátu. Pro důkaz DNSSEC-em zatím nebylo definitivně rozhodnuto, ale DANE je nejpravděpodobnější možnost. Pro případ revokace kompromitovaného SK můžete uvést DNS jména SK organizací, které pomohou při rozhodování o vydání nového SK (musí to být někdo, komu věříte).
Jak se podpis serverového certifikátu udělaný klíčem SK dostane ke klientovi? Buďto se přidá jako X.509v3 extension do serverového certifikátu nebo se pošle jako extra certifikát v TLS handshake, kterou posílá server. Obě varianty jsou zpětně kompatibilní, i když u přidávání extra certifikátu PKIX WG skřípe zuby.
Nejzávažnější zranitelnost je kompromitace DNS nebo web serveru, pro který SK ještě vydán nebyl: útočník může získat PKIX-validní domain-validated certifikát a prohlásit ho za SK. Skutečný vlastník serveru pak nemá možnost revokace podvodného SK. Návrhy pro zamezení tohoto útoku jsou:
- server musí posílat HSTS hlavičky a automaticky přesměrovávat HTTP na HTTPS
- server musí mít na https://www.domain.com/request-for-sovereign-key.txt soubor obsahující hash SK
- po dobu dvou týdnů zasílat notifikace na WHOIS kontakty, adresu v serverovém certifikátu, atd.
Pokud se vám uvedená verifikace zdá nápadně podobná CA-verifikaci, není to zdání. SK je vlastně taková „CA nad CA“. Protokol SK má dost široký záběr a tudíž je složitý. Např. není vyřešeno, co se stane, když koupíte doménu a původní vlastník vám nedá přidružený SK. Zajímavá diskuse je na konci přednášky o SK na 28C3.
Další operace jako změna protokolů přiřazených k SK nebo revokace jsou popsány v design dokumentu. Obsahuje i algoritmus a struktury pro dotazování timeline serverů nebo mirrorů a pseudokód na detekci podvodných timeline.
Certificate Transparency (Auditable CAs)
Google tým inspirován protokolem Sovereign Keys přišel s vlastním návrhem zvaným Certificate Transparency (pdf). 10sekundové shrnutí návrhu: „všechny certifikáty vydané od CA budou ve veřejně přístupném logu“. Tento log musí mít také vlastnost append-only, nesmí být možné falšovat minulost. Z hlediska TLS klienta můžou nastat tři varianty při ověřování logu:
- certifikát není v žádném veřejném logu a žádný log tajně nespolupracuje s CA – klient odmítne
- certifikát se nachází ve veřejném logu – klient přijme; operátor serveru může zjistit jestli někde vydal podvodný certifikát a reportuje útok
- certifikát se nenachází ve veřejném logu a nějaký log spolupracuje s CA – klient může přijmout dočasně (závisí, jestli může zkontrolovat veřejné logy), ale nakonec se ukáže, že log je falešný
Datová struktura pro logy jsou Merklovy stromy. Proto při mirrorování není nutné vždy stahovat kompletní strukturu. Prezentace důkazu auditu klientovi může být opět jako u SK prezentována extra certifikátem v TLS handshake nebo X.509v3 extension.
Privátní CA přidané ručně do trust store klienta se můžou vyhnout auditu, jinak by musely stejně jako ostatní CA publikovat log vydaných certifikátů. Omezení privátních CA lze implementovat přes X.509v3 name constraints extension.
Mutually Endorsing CA Infrastructure
Tento návrh prezentoval Kai Engert na konferenci FOSDEM 2012 (pdf), podrobnější detaily jsou na stránce projektu MECAI. Krátké shrnutí:
- každá CA se „zaručí“ za každý server – jaké DNS jméno používá, s kterou IP, certifikátem a aktuálními revokačními informacemi (v zásadě něco jako Perspectives provozováno od CA)
- server si periodicky vyžádá voucher s těmito informacemi od různých CA
- browser při TLS spojení v ClientHello uvede, které CA se můžou zaručit (vybere náhodně tři) a server musí voucher od jedné z těch CA poslat v odpovědi (á la OCSP stapling)
Kaiovi se na DANE a Certificate Transparency nelíbí hlavně centralizace: u DNSSEC fakt, že všechno vede k podpisu rootu a u Certificate Transparency obětování decentralizace kvůli jednoduchosti nasazení a dostupnosti. Výhoda MECAI proti Certificate Transparency je soukromí (klient se neptá žádné třetí strany) a hlavní nevýhodu kopíruje z Perspectives: CDN služby můžou vést k zmatku.
Crossbear
Crossbear není ani tak bezpečnostní protokol jako spíš nástroj na hledání, kde dochází k MitM útoku (na „nepřátelském“ území). Vyvinut byl v Technische Universität München, je dostupný jako doplněk pro Firefox.
V krátkosti je to Convergence s traceroutováním – kontaktují se notářské servery, aby sdělily jaký certifikát vidí z jejich síťové perspektivy. Všichni klienti se podílejí na co nejbližší lokalizaci místa útoku stahováním hunting tasks a posíláním výsledků viděných certifikátů a traceroutů. Tudíž je důležité zmínit, že na straně serveru se pak uchovávají informace pro identifikaci útoku (klientské IP, ASN, viděné certifikáty a tracerouty).
K Crossbearu jsou dostupné slajdy, video z 28C3 lightning talks a zdrojáky.
Závěr
Všechny uvedené řešení budou mít problém s captive portals, nicméně TLS klienti mají už teď stejný problém s CRL a OCSP. Adam Langley napsal o řešení pro Chrome, Mozilla k tématu captive portals vede bug 562917.
ČLÁNKY DO MAILU