Protokoly omezující moc certifikačních autorit

Protokoly omezující moc certifikačních autorit CZ.NIC z.s.p.o. Ondrej Mikle / [email protected] 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

„důvěryhodné“ „nedůvěryhodné“

od 6/2011

rok 2011

celkově

3 2

6 2

14 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