Slušný člověk nešifruje! - MujMAC.cz - Apple, Mac OS X, Apple iPod

Navigace:  » Úvodní stránka  » Rubriky  » Software  

9. března 2010, 00.00 | Ne, nebudeme se tady bavit o roztomilém britském zákonu RIPA III a jeho důsledcích; namísto toho si ukážeme a vysvětlíme jeden problém, jímž programátoři Apple poněkud zkomplikovali život těm, kdo se nedomnívají, že slušný člověk nemá co skrývat, pro změnu po stránce technické a nikoli legislativní.

Ne, nebudeme se tady bavit o roztomilém britském zákonu RIPA III a jeho důsledcích; namísto toho si ukážeme a vysvětlíme jeden problém, jímž programátoři Apple poněkud zkomplikovali život těm, kdo se nedomnívají, že slušný člověk nemá co skrývat, pro změnu po stránce technické a nikoli legislativní.

(Poznámka: tento článek odpovídá stavu systému 10.6.2; bylo by velmi příjemné, kdyby níže popsané problémy nějaký upgrade vyřešil... ale moc tomu, upřímně řečeno, nevěřím.)

Kdo je kdo a co je co?

Budeme se zabývat šifrováním elektronické pošty a problémy, jež nastávají v aplikaci Mail v Irbisu (Snow Leopard pro ty, kdo nemají rádi překlady jmen), s vyhledáním a použitím vhodného certifikátu.

Ti, jimž jsou pojmy "certifikát", "digitální podpis", "privátní klíč", "veřejný klíč" zcela zřejmé, a kdo rozumějí aplikaci Keychain Access (česky, tuším, Svazek klíčů) a dokáží s ní zacházet, mohou zbytek tohoto odstavce přeskočit a pokračovat rovnou odstavcem "Oč přesně jde?"; pro ostatní uvedeme několik odkazů na články, v nichž jsme se touto problematikou zabývali před časem:

• základy grafického uživatelského rozhraní pro šifrování elektronické pošty jsme si ukázali v prvé sekci tohoto článku;

• princip, na němž takové šifrování funguje, jsme popsali hned v dalším pokračování ("privátní klíč", "veřejný klíč");

• základní princip digitálního podpisu vysvětluje druhý odstavec následujícího dílu (v němž protentokrát můžete klidně přeskočit prvou sekci o "černém uprostřed");

• a hned v dalším jsme se seznámili s pojmem "certifikát", a popsali jsme si, jak se používá pro služby, o nichž se zde bavíme (pozor, vizte poznámku na konci tohoto odstavce!)

• základy práce s aplikací Keychain Access jsme si ukázali o pár dílů dále, v tomto článku a v jeho pokračování.

Pozor na jednu drobnost: v době, kdy byly výše uvedené články psány, používal Mac OS X pro "posvěcené" kořenové certifikační autority standardně keychain "X509Anchors" ve složce "/System/Library/Keychains"; to se od té doby změnilo, a dnes se tento keychain logičtěji nazývá "System Roots".

Oč přesně jde?

Problém, na který se dnes podíváme, spočívá v tom, jak aplikace Mail (a zřejmě nejen ona, zdá se, že jde o obecnou chybu v systémových knihovnách) vyhledává certifikáty (resp. klíče, jež jsou ovšem součástí certifikátů) pro podepisování a pro šifrování.

Nejprve si popíšeme projevy tohoto problému; jsou v zásadě dva, podle konkrétní situace může nastat jeden nebo druhý z nich.

Prvá varianta vypadá tak, že aplikace Mail dovolí bez problémů aktivovat šifrovací "zámeček" při sestavování nové zprávy; pokus o její odeslání však dopadne takto:

Druhá je malinko záludnější – dovolí bez problémů šifrovanou zprávu odeslat, nicméně odeslanou zprávu si po sobě již nepřečtete, vypadá nějak zhruba takto:

(Poměrně roztomilá varianta druhého případu může také spočívat v tom, že zprávu bez problémů odešlete a obsah odeslané vidíte – pak ale ukončíte aplikaci Mail, znovu ji spustíte, a ... ejhle, najednou "Unable to decrypt message".)

Příčiny

Co je příčinou problému? Inu, v principu je to velmi jednoduché: jde o to, že za jistých okolností Mac OS X najde – a pokusí se použít – nesprávný certifikát. S ním je samozřejmě spojen odlišný privátní klíč, a ten zprávu, zašifrovanou veřejným klíčem jiného certifikátu, ovšem dešifrovat nemůže.

Proč přesně knihovní kód někdy sáhne po nesprávném certifikátu není úplně zřejmé; zdá se ale, že problém spočívá v následujících třech bodech:

• při volbě certifikátu se ignoruje předvolba identity;

• při volbě certifikátu se ignoruje nastavení důvěry;

• při volbě certifikátu se použije první (neexpirovaný) certifikát, aniž by se při neúspěchu zkoušely ostatní.

Jelikož předvolby identit ani nastavení důvěry jsme si dosud nepopisovali, podívejme se na všechny tři body malinko podrobněji, ačkoli z hlediska vlastního obsahu tohoto článku jde spíše jen o odbočku:

Předvolba identity

Mac OS X předpokládá, že identit můžeme mít více, a umožní nám zvolit, kterou z nich chceme používat (jak ovšem sama nutnost psát tento článek ukazuje, zdá se, že to až tak úplně nefunguje, bohužel).

Postup je velmi jednoduchý: v aplikaci Keychain Access označíme požadovaný certifikát, a z kontextové nabídky (nebo z nabídky "File") vybereme "New Identity Preference...". V dialogovém lístku pak vyplníme to, pro co má vybraná identita být používána – v případě šifrování elektronické pošty tedy naši e-mailovou adresu:

Zadaná preference se uloží do keychainu – pozor, do defaultního, což nemusí být ten, v němž zvolený certifikát je! – jako nová položka typu "identity preference", a Mac OS X ji nadále při volbě identity použité pro práci se zadanou e-mailovou adresou bere prioritně v potaz... někdy, snad.

Chceme-li tuto volbu změnit, otevřeme prostě zmíněnou novou položku; chceme-li ji zrušit, položku v keychainu smažeme.

Nastavení důvěry

Další možnost, kterak ovlivnit způsob, jímž knihovny Mac OS X pracují s tím kterým certifikátem, je nastavení důvěry: na požadovaný certifikát v aplikaci Keychain Access poklepeme (nebo jej označíme a vybereme službu "Get Info" z nabídky "File"). To otevře nové okno, v němž jsou dva bloky informací – "Trust" a "Details". Detaily prostě zobrazují detailní informace o obsahu certifikátu; "Trust" naproti tomu umožňuje nastavení pravidel pro práci s ním:

Je asi zřejmé, že "Always" znamená, že certifikát lze vždy použít, "Never" že by jej systém neměl považovat za důvěryhodný za žádných okolností, a také to, že šedé položky níže (je jich ve skutečnosti více než na snímku obrazovky) umožňují nastavit důvěru individuálně pro každou z různých variant použití certifikátu – my samozřejmě vedle obecného "When using..." můžeme pro Mail alternativně použít "Secure Mail (S/MIME)".

Volba certifikátu

Zdálo by se logické, aby systém výše uvedených pravidel důsledně využíval – a navíc v případě, kdy pro případné dešifrování nalezne několik alternativ, aby vyzkoušel všechny, dokud nenajde tu, jež funguje (nebo nevyčerpá všechny). Bohužel, v praxi tomu tak zřejmě není.

Samozřejmě, co se tam doopravdy děje, to bez zdrojových kódů Apple nelze zjistit; podle mého testování (jež se zdá být konsistentní i se zkušenostmi jiných) to vypadá, že

• certifikát se vybírá podle e-mailové adresy, která je v něm uložena;

• je-li více certifikátů s touž adresou, předvolby identity se zcela ignorují;

• je-li více certifikátů s touž adresou, nastavení důvěry se zcela ignoruje;

• prvý certifikát, jehož adresa odpovídá a jehož platnost dosud nevypršela, se použije;

• aplikace Mail si sestavuje seznam platných certifikátů při spuštění; běží-li tedy delší dobu, může být to, co využívá, nekonsistentní s aktuálním obsahem keychainů.

Přitom se zdá, že "prvý" z předposledního bodu je v podstatě náhodné "prvý, který se najde při prohledávání keychainů".

Z toho v podstatě plyne, že máme-li v systému více platných (ve smyslu doby platnosti, nikoli nastavení důvěry) certifikátů s touže e-emailovou adresou – máme smůlu.

Kontrola stavu

Zjistit, který z certifikátů vlastně systém používá, není zcela jednoduché; v některých situacích ale pomohou následující triky:

Podpis a jeho kontrola

Chceme-li zjistit, kterým certifikátem Mail podepisuje odeslané zprávy, je to poměrně jednoduché: odešleme podepsanou zprávu – např. sami sobě; pak stačí klepnout na symbol podpisu (ať již po přijetí, nebo jen v seznamu odeslaných zpráv), a Mail zobrazí detailní informace o použitém certifikátu:

Poznámka: pokud řádek "Security" v hlavičce odeslané (nebo přijaté) zprávy nevidíme, je to – bohužel – normální, narazili jsme na další prastarou a dosud neopravenou chybu aplikace Mail. Stačí přepnout na kompletní hlavičku ("Long Headers" z nabídky "View / Message") a zpět (nyní "Default Headers" z téže nabídky), a řádek se objeví – samozřejmě pokud je zpráva podepsaná nebo šifrovaná.

Standardní certifikát podle Mac OS X

Zdálo by se, že certifikát, jímž se podepíše zpráva odeslaná s "From: nějaká adresa" je právě a vždy standardní certifikát pro tuto adresu podle názoru systému; bohužel tomu tak není zdaleka vždy (a to je právě příčina problémů, jimiž se v tomto článku zabýváme).

Jednou z možností, jak ověřit, co si Mac OS X momentálně domýšlí stran certifikátů, je aplikace Address Book: v ní jsou e-mailové adresy, pro něž certifikát existuje, opatřeny příslušnou značkou – klepneme-li na ni myší, certifikát se nám zobrazí:

Vidíme-li zde jiný certifikát než ten, jímž Mail naše zprávy podepisuje, lze očekávat problémy velmi záhy!

Certifikát, jímž se šifrovalo

Asi nejsložitější je ze zašifrované zprávy zjistit informace o certifikátu, který byl k šifrování použit. RFC (standard formátu) obsahuje poměrně vágní formulace typu "měl by obsahovat, ale může... a nemusí..."; nicméně experimenty ukazují, že zprávy, zašifrované v aplikaci Mail, vždy obsahují odkaz na certifikát representující autoritu, jež ten certifikát, jímž je šifrováno, vydala (sám certifikát, jímž je šifrováno, ale ve zprávě je pouze v případě, že je zároveň podepsaná).

I tato informace je ale mnohdy cenná – umožňuje např. na první pohled rozlišit, zda byla zpráva zašifrována pomocí certifikátu Thawte, VeriSign, či vlastního (ať již samostatně stojícího, nebo založeného na vlastní certifikační autoritě, jejíž jméno samozřejmě známe).

Máme-li nečitelnou zašifrovanou zprávu, zobrazí ji aplikace Mail jako přílohu "smime.p7m"; nejjednodušší a nejrychejší je prostě tuto přílohu otevřít v TextEditu (nejspíše prostě vhozením); název autority, jež vystavila šifrovací certifikáty – obvykle jich je samozřejmě více, neboť zpráva bývá typicky zašifrována přinejmenším pro odesilatele a příjemce – vidíme hned na začátku souboru.

Chceme-li vidět detailní informace – ne že by to nějak zásadně pomohlo –, můžeme

• přepnout zobrazení zprávy na textový nezpracovaný formát ("Viev / Message / Raw source");

• zašifrovaný obsah ve formátu Base64 (celistvý sloupec zcela nesrozumitelného textu) označit a zkopírovat do schránky;

• otevřít okno aplikace Terminal, a v něm zadat příkaz "pbpaste | openssl base64 -d | openssl asn1parse -inform DER".

Ten zobrazí detailní informace o obsahu – z nichž se ale nedozvíme o mnoho více, než z rychlého nahlédnutí do souboru "smime.p7m" v TextEditu.

Poznámka: koho to zajímá, tedy příkaz pbpaste získá obsah schránky – jímž je v našem případě zašifrovaný text ve formátu Base64 –, příkaz openssl base64 -d jej dekóduje do formátu "DER", a příkaz openssl asn1parse -inform DER zobrazí jeho detaily. Ačkoli příkaz openssl asn1parse v principu může načítat data rovnou ve formátu Base64, vyžaduje bohužel, aby před a za nimi byly oddělovače "-----BEGIN PKCS7-----" a "-----END PKCS7-----"; je snazší použít výše popsaný trik, než je tam ručně doplňovat.

To je vše hezké, ale co s tím?

Jednoduché řešení výše popsaných problémů bohužel neexistuje – nebo o něm alespoň nevím (pokud je někdo zná, samozřejmě doufám, že je popíše v diskusi k článku).

Relativně nejpoužitelnější řešení pro ty, kdo potřebují pracovat s více různými certifikáty identit, jež všechny obsahují touž e-mailovou adresu, a jež se mi podařilo nalézt, je:

• uložit každou identitu do samostatného keychainu;

• keychainy s identitami, s nimiž zrovna nepracujeme, uzavřít a vyřadit ze seznamu keychainů, jež se automaticky prohledávají ("Edit / Keychain List" v aplikaci Keychain Access). Mimochodem, zdá se, že je bezpečné takto "odstranit" i certifikační autoritu, na níž je aktivní certifikát založen;

• kdykoli nastane jakýkoli problém, zkontrolovat defaultní keychain (tj. ten, do nějž aplikace standardně ukládají nové položky – obvykle jde o keychain "login"), zda se v něm z podpisů neobjevil "nesprávný" certifikát. Je-li tomu tak, smazat jej;

• po změnách restartovat aplikaci Mail.

Pro kontrolu certifikátů je příjemné, že aplikace Keychain Access umí prohledávat všechny keychainy, a nalezne libovolný certifikát, platný pro danou e-mailovou adresu, bez ohledu na jeho jméno: stačí vlevo dole v bloku "Category" zvolit "My Certificates" a e-mailovou adresu zapsat do vyhledávacího pole vpravo nahoře: