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

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