česky | english
Klientské certifikáty a SSO - staronová věc
[SSO = Single Sign-On, jediné přihlášení]
Iang pronesl Bleskovou řeč na Fosdem 2010, nazvanou "Klientské certifikáty, staronová věc". Zde jsou výpisky. Viz také presentaci na zdroji v ODP a výstupu PDF. YouTube má videozáznam. Je take umístěn na LCA2011.
Toto je příběh o identifikaci. Začali jsme někdy v 80. letech 20. století tak, že jsme důvěřovali každému, ale rychle jsme to změnili na hesla a uživatelská jména. V devadesátých létech se zvedl povyk okolo "jednotného přihlášení" (Single Sign On neboli SSO) a po roce 2000 jsme slýchali o federaci.
Proč to nefungovalo? Proč se stále pokoušíme vyřešit tento problém? No, "důvěřovat každému" nefungovalo, protože není každý hoden důvěry. Uživatelská jména a hesla trpěla populační explozí: každá osoba měla mnoho přístupů k různým webům a jiným místům, a každé mělo svoje heslo - dohromady k nezapamatování. Příliš mnoho hesel, opakovaná použití, jednoduchost a složitost tvořily opojnou směs, a výsledné problémy zvyšovaly náklady na uživatele a podporu... nemluvě o zabezpečení.
SSO trpělo jiným neduhem: každé přístupové místo (např. web) si muselo zvolit metodu, ale udělali to i všichni uživatelé. Přístupová místa zahlížela na všechny členy, kteří si nezvolili jejich oblíbenou metodu, uživatelé zase zahlíželi na všechna přístupová místa, která nepřijímala jejich preference. Vzniklo smrtící objetí, známé spíše jako problém slepice a vejce.
Federace také trpěla stížnostmi uživatelů, že nechtějí mít svá data uložena na serveru nějaké korporace, a a společnosti zase nechtěly sledovat tímto způsobem své zákazníky. Každý podezíral každého.
Víme, jak na Základní příběh identifikace - teoreticky, ale neuspěli jsme v praktické zkoušce. Proč to naše počítače nedokážou?
No, ukázalo se, že mohou: v každém webovém prohlížeči a serveru jsou klientské certifikáty. Jsou to staré dobré kryptografické nástroje. Prostě vezmete pár klíčů (veřejný-privátní), na konec veřejného klíče si nechte připlácnout podpis - obvykle pocházející od nějaké jiné společnosti jako CA. Proč to nefungovalo?
Když se podíváme na výše uvedené chyby, nebylo to (a) protože to vše je v software webového serveru jako Apache nebo IIS a je to tam už dlouho. Ani záležitosti ochrany dat skutečně nenastaly (ačkoli existují), protože údaje v samotném certifikátu nejsou tak rozsáhlé, aby na nich tak záleželo, a jejich použití je zřejmě zvládnuto docela dobře.
Je to (b): většina uživatelů nemá klientský certifikát. Proč? No, bylo to příliš složité, příliš komplikované pro obyčejné uživatele, a to zaškrtilo celý vývoj. Kvůli chybě ve vajíčku nikdy nevyrostlo kuře. A skutečně, na otázku Proč se to nestalo? je nejlépe odpovědět: Neptejte se. Tato odpověď vás aspoň nezarmoutí.
Tohle je příběh o tom, jak CAcert vyřešil ten problém. A je to opravdu slušný kus příběhu, jak hned uvidíme.
Certifikáty od certifikačních autorit (CA) mají co do činění s "identitou", ať už je to co chce, a my ji zjišťujeme pomocí něčeho, čemu říkáme zaručování. V CAcert jsme měli asi 8000 zaručovatelů, kteří prováděli proces individuální kontroly "identity" jiných členů. Někteří tomu říkají web důvěry.
CAcert měl velké potíže získat audit, což vedlo k velké otázce: jak auditovat web důvěry? Klasické audity vyžadují a očekávají dokumentaci, normy, ověření. Takže CAcert je vytvořil, a jeden prvek toho celku byl (nyní pověstný) test Výzva zaručovatele (Assurer Challenge) na systému CATS. 25 vybraných otázek, každá s několika možnostmi odpovědi, zabalených do základního webu PHP, zatím nepříliš složitého.
Hotovo, ale měli jsme inspiraci: rozhodli jsme se, že jediný způsob přístupu k tomuto webu bude klientskými certifikáty. Bylo to proto, že jsme CA, nebo že chceme být "cool", nebo si myslíme, že 25 otázek s více odpověďmi, stahovatelných po síti, potřebuje ochranu s vysokým zabezpečením? Nebo...? Snad to byla jedna z otázek s odpovědí "neptejte se", nebo jsme jen chtěli, aby se tento příběh vyprávěl?
Ať je to jak chce, fungovalo to. CATS ožil začátkem roku 2008 a zkouška se stala povinnou začátkem roku 2009. Potom dramaticky poklesl počet zaručovatelů z těch asi 10 000 a postupně šplhal zpátky na dnešních asi 3339 (zaručovatelů) [1.4.2015: 6373]. Naše současná báze zaručovatelů je daleko silnější a daleko schopnější; současné události to dosvědčují.
To nám umožňuje dát se do problému Kuře. Teď, když jsme věděli, že každý náš zaručovatel má ve svém prohlížeči klientský certifikát, mohli jsme trvat na tom, aby každý z našich webů používal klientské certifikáty. Takže jsme to provedli: napřed s blogem a také se Sympa a hlasovacím nástrojem výboru - je to probíhající úkol, priorita pro vývojáře aplikací.
Jak dobře to funguje? Velmi dobře. Blog jsme zpřístupnili novým a dalším autorům, kteří potřebovali pouze klientské certifikáty; nepotřebují žádat o povolení a slyšet NE, nebo že se žádost ztratila, nebo být ignorováni. Zapomenutá hesla už nejsou problém. Spam je vyřešen.
Vyskytnou se i nějaké zrady, nic není dokonalé. Firefox je zmaten z více certifikátů, proto čekáme na bílé listině, než nás přidá tým vývojářů Firefox. Také když se Apache rozhodne, že nemá rád klientské certifikáty, posílá zpět do prohlížeče chybu spojení protokolem SSL (SSL connection protocol error). Ten ji pak zobrazí uživateli. To je matoucí; klientovi je třeba říci, aby zkontroloval svůj klientský certifikát. Naneštěstí zde figuruje trochu vývojářské arogance, obě strany tvrdí, že to dělají správně, a urážejí ostatní, místo aby řešily problém. Ten bude asi vyřešen, když váha uživatelských stížností někoho donutí myslet otevřeněji.
Strategie. Víme nyní dost pro návrh, jak zavést klientské certifikáty. První otázkou je, zda budete míchat hesla a klientské certifikáty, zda povolíme uživatelům si vybrat. To má určité stinné stránky: je tu zase rozdíl metod, takže budete v této oblasti stále kódovat, věčně se zabývat podporou a chybami. Je to stejný rozdíl jako mezi HTTP a HTTPS, který využívají zločinci provádějící phishing (lákající z uživatelů osobní údaje, například hesla). CAcert používá tuto hybridní metodu na svém webu, ale jen proto, že také musí povolit uživatelům nějaký způsob, jak obnovit jejich účet.
Dále přichází sólo: Pouze SSL, pouze klientské certifikáty, pořád a pokaždé. To je daleko lepší, protože tu není třeba kódovat výjimky (chyba na "přistávací" stránce - landing page), nejsou případy nečistého kódu, s nímž je nutno se zabývat (měla, neměla?). Pak tu máme dilema zpracovávat certifikáty v Apache, nebo v PHP (nebo jiném kódu). (2.a) původně umožňuje určité zpracování řetězců, ale tíhne k "příliš málo" nebo "příliš mnoho" a vždy existují určité případy, které je lépe řešit kódem. Proto je nejlépe dělat celou věc v aplikačním kódu PHP (2.b).
Více do hloubky: třetí zrada je, že klientské certifikáty se mění: končí jejích platnost (expirují) a mohou být ztraceny nebo prozrazeny. Zde ve vašem kódu PHP můžete uložit informaci o klientském certifikátu do databáze a z ní indexovat účet. Když je předložen nový certifikát, můžete vyhledat e-mailovou adresu nebo jméno uživatele a potvrdit si, že jsou shodné. To umožní uživateli mnohem hladší průchod, i když je třeba více přemýšlet, když se změní jméno a e-mailová adresa, nebo dojde-li ke kolizi jmen.
Závěr. Pro nás klientské certifikáty fungují a fungují dobře. Šetří čas naší správě, uspokojují naše uživatele, protože přístup je mnohem jednodušší a spolehlivější, než s kombinací uživatelské_jméno / heslo. Řeší za nás problém SSO a fungují... pokud můžete dostat k uživatelům jejich vejce.
A tady je výzva pro vás: Jak dostat klientské certifikáty k vašim uživatelům, tak abyste z toho pak měli prospěch. Jsou tři možné strategie:
* Jak to udělal CAcert, vybudujte web, jakýkoli web, a trvejte na používání klientských certifikátů. Vtáhněte do toho své uživatele.
* Nebo zatlačte své uživatele prostým stanovením pravidla jako "Všichni uživatelé jsou zároveň zaručovatelé CAcert." (Tak jsem to udělal u jiné technické nadace, s kterou spolupracuji.)
- * Konečně můžete vytvořit jednoduchou interní CA a provozovat "tovární výdej" klientských certifikátů svým lidem.
Děkuji, prosím dotazy.
- A co opakované vyjednávání v TLS?
- Odpověď: Toto je opravdu mimo téma, ale chcete-li omezit svůj web na výlučné používání klientských certifikátů po celou dobu (zbavit se jakýchkoli souborů podadresáře .htaccess), pak soudím, že opakované vyjednávání nebude spuštěno.
- Dotýká se to ochrany soukromí?
- Odpověď: Ano, v zásadě každý web si může vyžádat Váš certifikát během TLS relace s klientskými certifikáty, což znamená, že tyto weby mohou zjistit Vaše jméno, aniž si to uvědomíte. Je hlášena chyba v Mozille, která se toho týká... i zde čekáme na lepší řízení práce s certifikáty ve Firefoxu (zase jsme v pořadníku). Je také třeba říci, že žádost serveru o klientský certifikát je základní slabinou či dokonce chybou protokolu TLS a že změna není pravděpodobná, takže prohlížeč bude mít mnohem více práce a servery se vždy budou muset konfigurovat.