Protokoly omezující moc certifikačních autorit CZ.NIC z.s.p.o. Ondrej Mikle / ondrej.mikle@nic.cz 1. 3. 2012 1
Obsah 1. Proč potřebujeme nové protokoly? 2. DANE 3. Sovereign Keys 4. Certificate Transparency 5. Mutually Endorsing CA Infrastructure 6. Technický bonus pro výzkumníky 2
Fail za období 2011-2012 Comodo (3/2011) íránský hacker si napadnutím RA InstantSSL vydal certifikáty pro Gmail, Mozillu... Diginotar (7/2011) opět Írán a opět certifikáty pro Gmail, Mozillu... podvodné certikáty použity na sledování 300 000 íránských IP StartCom, GlobalSign taky napadeny z íránských IP adres GlobalSign revokoval několik certifikátů (podle CRL), i když veřejně mluvil jenom o jednom StartCom nemusel revokovat žádný Trustwave (2/2012) přiznává se k vydávání MitM certifikátů...jenom mediálně nejznámější případy 3
Fail podle CRL Peter Eckersley z EFF spočítal počet kompromitovaných CA podle CRL cacompromise důvodu (10/2011) zopakováno v CZ.NIC Labs (12/2011) výsledek téměř totožný s Eckersleym (14 vs 15 celkově) určitě tam není vše, CA vyhazují staré záznamy z CRL od 6/2011 rok 2011 celkově důvěryhodné 3 6 14 nedůvěryhodné 2 2 2 4
Proč potřebujeme nové protokoly 5
Protokoly a nástroje proti MitM existující nástroje myšlenka: vidí notářské servery stejný certifikát jako já? implementace: Perspectives, Convergence, Crossbear problém s CDN službami, které mají mnoho certifikátů nové protokoly myšlenka: operátor serveru ví nejlépe, jaký má mít certifikát tzv. certificate pinning technika 6
DANE v IETF zaštiťuje CZ.NIC a Google, snad už brzy bude RFC záznam o asociaci certifikátu k doméně je v DNS, obsahuje: doménu, port (př. 443 pro HTTPS), protokol (tcp/udp) certifikát, veřejný klíč nebo hash z nich záznam se jmenuje TLSA, musí mít DNSSEC podpis možnosti asociace certifikátů serverový certifikát (řetězící se k důvěryhodné CA) důvěryhodný CA certifikát v řetězci certifikátů specifický serverový/ca certifikát (možnost vytvoření vlastní CA ) první dvě omezují současný stav, aby libovolná napadená CA nemohla vydat certifikát komukoli 7
DANE příklad pro gmail.com 8
Sovereign Keys pochází od Petera Eckersleyho z EFF ke každému doménovému jménu je přiřazen RSA/ECC klíč nazvaný Sovereign Key (dále jen SK) jiný než klíč použitý v serverovém certifikátu (může být i z DANE) vlastník musí prokázat kontrolu nad doménou existuje nefalšovatelná a časově monotonní timeline jsou tam všechny SK a jejich vztah k doménám timeline je v několika kopiích na timeline serverech (př. 20) každý timeline server podepisuje timeline svým klíčem monotonicita zaručena přes sériová čísla a časová razítka funguje, dokud existuje alespoň jeden čestný timeline server 9
Sovereign Keys diagram 10
Sovereign Keys algoritmy dost složitý protokol, řeší mnoho věcí revokace SK čerstvost SK timeline lze tahat po částech ochrana proti některým DoS útokům na timeline servery největší výzva jak zabránit někomu vytvořit SK dříve než skutečnému vlastníkovi domény? povinné HTTP Strict Transport Security kontaktování na adresy ve WHOIS požadavek na textový soubor na serveru skutečně chci vytvořit SK s hashem DEADBEEFCAFEBABE podobnost s validací u CA není náhodná 11
Certificate Transparency Google se nechal inspirovat od Sovereign Keys myšlenka: všechny certifikáty vydané od CA budou ve veřejně přístupném logu log podobně jako u SK nefalšovatelný a časově monotonní datová struktura jsou Merkleho stromy stačí podepsat jen části nebo jen kořen není nutné stahovat vždy celý strom operátor serveru x.y.z musí kontrolovat, jestli se neobjevil v logu certifikát, který si vydat nenechal Google plánuje provozovat logy centralizovaně existuje už i alpha verze kódu 12
Mutually Endorsing CA Infrastructure prezentoval Kai Engert (Mozilla) na FOSDEM 2012 každá CA se zaručí za každý server jaké DNS jméno používá, s kterou IP s certifikátem a aktuálními revokačními informacemi server si periodicky vyžádá voucher s těmito informacemi od různých CA server řekne CA: oskenuj mi certifikát a zapamatuj si co vidíš CA odpoví: tady to máš i s mým podpisem zpátky když se klient připojí k serveru x.y.z: vybere si náhodně tři CA jiné než ta, která vydala serveru certifikát server pošle navíc jeden voucher od zvolené CA 13
Závěrem technický bonus X.509v3 je šílený formát a RFC 5280 žádný klient neimplementuje správně/úplně (následující už opraveno) null-prefix attack, IDN znak vypadající jako / (Marlinspike 2009) 0x80 OID encoding attack, OID integer overflow (Kaminsky 2009) ignorace basicconstraints (iphone měl v 2011 stejnou chybu jako Internet Explorer v 2005) tím to nekončí ASN.1 definuje 12 (!) typů řetězců, různé implementace si je vykládájí různě různě striktní parsování X.509v3 extensions (viděl jsem i velmi populární prohlížeč ignorovat neznámou extension označenou jako critical ) nové protokoly zamezí oblafnutí CA/klientů podobnými triky 14
Otázky 15