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

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Odkud pochází fotografka Anne Erhard?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Software

Slušný člověk nešifruje!

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:

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Tipy a Triky  

 » Rubriky  » Software  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

hmmm

Autor: ED Muž

Založeno: 09.03.2010, 08:04
Odpovědí: 0

Jak to napsat... výborný článek, který nepotěší. Ale je strašně dobře, že tu je. Díky za takové články, jen houšť a větší kapky. Tak zase váhám, jestli si pořídit tu datovou schránku nebo ne..... mě by se to líbilo, ja pořád hledám nějaké zatoulané dopisy, ale funguje to? Myslim funguje to použitelně? Nebo je tostejně zamotané jako ten Mail.app Díky.

Odpovědět na příspěvek

RE: hmmm

Autor: MaG Muž

Založeno: 09.03.2010, 09:40

Zkuste se na to podvat z jineho pohledu (a ted me asi par lidi ukamenuje). Urad Vam posle do datove schranky dokument o 110 stranach. Pote ho budete z konkretniho duvodu potrebovat v papirove podobe, coz znamena nechat si notarsky overit kazdy list, nebot bez overeni je to jen list papiru co jste si doma vytiskl....
Co vy na to ?

Odpovědět na příspěvek

RE: RE: hmmm

Autor: Pavel F. Muž

Založeno: 09.03.2010, 10:11

Otázka zní, jak často budete muset konvertovat z elektronické do papírové podoby? Pokud dostanete například elektronický rozsudek od soudu, tak si ho ponecháte v elektronické podobě. Pokud ho budete muset někomu předat/předložit, tak jim ho předložíte v elektronické podobě. Má to stejnou právní váhu jako předložení papírové originálu nebo ověřené kopie (autorizované konverze).

Odpovědět na příspěvek

RE: RE: hmmm

Autor: Ed Muž

Založeno: 10.03.2010, 08:43

No to je samozřemě taky možné a nebylo by to levné. Ale naštěstí mi nikdy nic takového nepřišlo, a snad ani nepřijde. Jde mi o tohle. Pkud jse postřehli novelu (nevím jak se ten zakon jmenuje přesně) v doručování "úřední" korespondence, tak pokud si ji nevyzvednete do 10 dnu hodí Vám ji do schránky a bere se jako doručená. Budiž. Jenže tímto dnem běží lhůta na reakci.Po 30 dnech spadne klec a nedokážete že vám do té schránky nikdo nic nehodil. Pokud ovšem máte DS ( se všemi necnostmi) je úřad povinen použít DS. Čili nevidím to jako konfortní řešení, ani levné řešení ale přeci jen alespoň nějaké řešení tohoto problému. Ta novela totiž umožňuje v podstatě cokoliv změnit bez vašeho vědomi. A pak že nejsou VOGONI.

Odpovědět na příspěvek

RE: hmmm

Autor: AniMuk Muž

Založeno: 09.03.2010, 09:48

Datove schranky jsou nejvetsi nesmysl a podvod v dejinach tehle zaprodane republiky a jak pise prispevatel dole za kazdou stranku na poste zaplatite 30Kc, protoze si dokumenty ktere vam zaslaji pres DS jen tak nevytisknete nebo ano ale je to jen car papiru. Za tenhle nesmysl by mel jit nekdo sedet. At zije cechoabsurdistan! Pokud si chcete precist vse potrebne o DS jdete na Lupa.cz vyslo tam pomerne dost clanku na toto tema.

Odpovědět na příspěvek

RE: hmmm

Autor: Koniklec2 Muž

Založeno: 09.03.2010, 10:36

Ono záleží na tom, co považuješ za použitelné. Systém datových schránek má pro valnou většinu uživatelů jeden velký zádrhel. Datové zprávy jsou v systému datových schránek uchovávány po dobu 90 dnů, pak jsou automaticky smazány a dále jsou uchována pouze některá metadata datových zpráv. Datová zpráva od orgánu veřejné moci (přibližně synonymum slova "úřad") je tzv. autorizovaná, tj. má platnost originálu - ovšem pozor - jen do chvíle, kdy datovou zprávu (prakticky její přílohu) uživatel překopíruje mimo datovou schránku, což musí, aby si zajistil existenci zaslaného dokumentu v datové zprávě po uplynutí devadesátidenní expirační lhůty v systému DS. V tom okamžiku se z dokumentu stává běžný, neautorizovaný dokument, který má právní platnost prosté kopie. Přímo uživatelské rozhraní systému DS má proto volbu Odeslat ke konverzi, což znamená, že dokument bude "čekat na konverzi" po stanovenou dobu (u mě to bylo 26 dní). Uživatel musí v této době jít na kontaktní místo Czech POINT a tam si nechat tento dokument autorizovat jeho vytištěním s autorizační doložkou, pokud chce mít v ruce originál. Datové schránky jsou i z tohoto důvodu naprostým paskvilem a přinesou jako bonus oproti běžné poštovní korespondenci jen možnost úřadům elektronicky autorizovaně odpovídat nebo zasílat korespondenci, což je ovšem možné i cestou použití elektronického podpisu bez datových schránek. Závěr je takový, že jsou absolutně na nic. Datové schránky však nelze v dohledné době zrušit, neboť byly částěčně financovány z evropských peněz a u těch platí podmínka, že projekt musí minimálně 5 let fungovat, jinak se prostředky vrací.

Odpovědět na příspěvek

RE: RE: hmmm

Autor: koniklec2 Muž

Založeno: 09.03.2010, 12:13

Ještě doplnění: Pokud uživatel uloží celou datovou zprávu (tj. nejenom samotnou přlohu), pak ji může používat jako ekvivalent originálu listiny.

Odpovědět na příspěvek

RE: RE: hmmm

Autor: Jarda Muž

Založeno: 10.03.2010, 09:02

Máte bohužel pravdu. Výhodou DS je rychlé doručování, nevýhodou zpoplatnění autorizované konverze. Pokud ale bude nutné dokument uchovat, neobejdete se bez a.k. nebo budete muset požádat úřad o vystavení tištěného stejnopisu (opět za poplatek).

Odpovědět na příspěvek

RE: RE: RE: hmmm

Autor: Pavel F. Muž

Založeno: 23.03.2010, 15:42

NESMYSL! Pokud si chcete DS uchovat, tak si prostě uložíte na disk a je stále platná, protože má v sobě stále "obálku" podepsanou ISDS.
To jako soud vydá rozsudek a po 90 dnech přestane platit?!? :-)))

Odpovědět na příspěvek

RE: hmmm

Autor: OC Muž

Založeno: 19.03.2010, 02:38

Datové schránky jsou zlo intergalaktických rozměrů.

Mimochodem, někdo se níže v diskusi zmiňuje o konversi. To je neobyčejně veselá věc v souvislosti s datovými schránkami; vizte prosím zde:

http://www.lupa.c
z/clanky/stalo-se-elektro
nicky-podpis-pry-plati/na
zory/275061/vlakno/#o2750
61

Odpovědět na příspěvek

Nepěkné novinky

Autor: hroch32 Muž

Založeno: 09.03.2010, 09:09
Odpovědí: 0

To jsou mi tedy nepěkné novinky, co ty mamlasové zase prováděli??? Zprávu o brouku jim už předpokládám někdo poslal.

Odpovědět na příspěvek

RE: Nepěkné novinky

Autor: matej Muž

Založeno: 09.03.2010, 09:59

....sifrovat se da na macku v pohode, jen je lepsi se vyhnout built-in nastrojum apple a zainvestovat treba do PGP. PGP pouziva aplikacni proxy a klidne muzete sifrovat zpravy odesilane z/do apple mail, thuderbird atd.

On i cely FileVautl stoji taktez za prd :) Pokud nekdo mysli bezpecnost opravdu vazne ma "bohuzel/bohudik" na macku k dispozici jen PGP.

Odpovědět na příspěvek

RE: RE: Nepěkné novinky

Autor: Pavel F. Muž

Založeno: 09.03.2010, 10:06

Jeden o koze, druhý o voze. Článěk pojednává o šifrování mailů přes S/MIME, nebavíme se o PGP řešení, kde na obou koncích musím mít PGP. Kdežto S/MIME má prakticky každý e-mailový klient.

Odpovědět na příspěvek

RE: RE: RE: Nepěkné novinky

Autor: matej Muž

Založeno: 09.03.2010, 10:43

to sice ano ale prave ze ta "implementace" drhne ? nebo ne ? :)

pokud si opravdu s nekym vymenuji duverna data, je PGP jasna volba, kombinace PGP & GnuPG je schopna pokryt veskere mozne kombinace na strane prijemce i odesilatele napric OS.

A dale, pokud uchovam duverna data, potrebuji ( mel bych potrebovat ) sifrovany file system, jinak je cela idea bezpecnosti o nicem, sice si pisu "sifrovane" ale veskera "zdrojova" data ( indicie k nim )mam nekde na disku nesifrovana...( neberu v uvahu VileFault :)

Problematika je trochu sirsi a preci mi nebudete tvrdit, ze sifrujete s kazdym ? Kdo ma potrebu sifrovat, sifruje a vetsinou i prijemce vi "ktera bije" a dokaze se zaridit, ostatni je jen kdyby, coby :)

Nic proti S/MIME, ale z celkoveho uhlu pohledu jsou mnohem lepsi a sofistikovanejsi reseni, ne jen pro ty co sifruji aby se nereklo :)..nebo aby se reklo vow :)

Hezky den.

Matej

Odpovědět na příspěvek

RE: RE: RE: RE: Nepěkné novinky

Autor: OC Muž

Založeno: 19.03.2010, 02:33

No, šifrovat _by rozhodně bylo správné a rozumné s každým_!!!

Ani já tak nečiním, z technických důvodů (zdaleka ne každý má vhodně zkonfigurovaný poštovní klient). Ale je to špatně. Děláme velkou, velkou chybu. Což zjistíme velmi nepříjemným způsobem ve chvíli, kdy nám padne na hlavu něco jako RIPA III, a kdy těch pár šifrovaných věcí bude automaticky podezřelých (zatímco kdyby se šifrovalo vše, mohl by si Velký Bratr hodit korunou, co ho zajímá, a co ne).

PGP je velmi dobré; bohužel na Macu je s ním technický problém -- nakolik je mi známo, GPGMail v Irbisu dosud nechodí, a je otázka, zda vůbec kdy bude. Ale možná jsem jen nedával pozor a mezitím to v sen:te vyhackovali?

Odpovědět na příspěvek

Oldthinkers unbellyfeel Ingsoc!

Autor: Oldthinker Muž

Založeno: 09.03.2010, 20:24
Odpovědí: 0

Jen přisadím pro případné pomatence kteří by se mohli chytit hesla "Slušný člověk nemá co skrývat." a vzali ho jako pravdu.

Pokud se tedy někdo z čtenářů považuje za "slušného člověka který nemá co skrývat", žádám Vás tímto veřejně o sdělení následujícího:
- výše čisté mzdy
- délka vašeho penisu
- jak často spíte s manželkou
- PIN a číslo bankovní karty
- zůstatek na bankovním účtu
- kopii daňového přiznání
Další dotazy individuálně...


Ta
kže znovu: opravdu nemá "slušný člověk" co skrývat?...

Odpovědět na příspěvek

RE: Oldthinkers unbellyfeel Ingsoc!

Autor: OC Muž

Založeno: 19.03.2010, 02:29

Problém je, že minimálně tři ze zmíněných údajů (a patrně více) sice nejsou dostupné veřejně, ale má je k dispozici stát :(

Zajímáte-li se o tuto problematiku, doporučuji

http://www
.dfens-cz.com/view.php?ci
sloclanku=2008011204

Odpovědět na příspěvek

Dotaz na zabezpečení bez dig. podpisů

Autor: Pern Muž

Založeno: 09.03.2010, 21:44
Odpovědí: 0

Měl bych dotaz. Díky sérii článků od Ondřeje Čady jsme zavedli šifrované emaily na "vnitrofiremní" korespondenci a to celkem dobře funguje.Problém je, že je občas potřeba si vyměňovat důvěrnější emaily s někým cizím, pokaždé někdo jiný, kdo zpravidla (nikdy) šifrování emailů nepoužívá.

Existuje nějaký jednoduchý způsob, jak předat šifrovaný soubor (smlouvu) někomu třetímu, aniž by prošel školením o používání certifikátů? Něco jako Dropbox public folder, ale aby byl soubor (dostatečně) chráněn heslem?

PS: Jestli jsem to dobře pochopil, popsané problémy se týkají jen případu, kdy mám více certifikátů k jedné emailové adrese.

Odpovědět na příspěvek

RE: Dotaz na zabezpečení bez dig. podpisů

Autor: OC Muž

Založeno: 19.03.2010, 02:24

No... v podstatě jediná možnost, jak si šifrovaně dopisovat s někým, "kdo tomu nerozumí a rozumět nechce", je (a) aby dotyčný měl mailový klient, podporující S/MIME, (b) postarat se o to, aby mu nějak někdo nainstaloval nějaký certifikát.

Ačkoli možností je samozřejmě víc (poměrně excelentní z mnoha hledisek je PGP), tato jediná je pro uživatele jednoduchá. Ostatní tak jednoduché nejsou.

U smluv apod. to lze ještě řešit uložením do šifrovaného image; popisoval jsem to někde v počátcích seriálu, nejjednodušší je složku, jež se má zašifrovat, hodit myší na aplikaci Disk Utility.

V tomto případě ale je potřeba ještě vyřešit problém předávání klíčů.

Odpovědět na příspěvek

RE: Dotaz na zabezpečení bez dig. podpisů

Autor: OC Muž

Založeno: 19.03.2010, 02:25

P.S. přesně tak. Tedy -- aspoň doufám :) Nikdy jsem na tento ani podobný problém nenarazil, pokud více různých certifikátů s touž adresou nebylo.

Odpovědět na příspěvek

 

 

Vložit nový příspěvek

Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: