Ac s clankem 100% souhlasim, musim varovat pred tim, abyste hned zitra zacali na SMTP zapinat sifrovani. Pokud totiz budete anoncovat STARTTLS a pritom nebudete mit duveryhodny certifikat, prestane vam prichazet posta. Parkrat jsem si s tim hral a vetsina tech co SSL pouziva to ma implementovane spravne a uzavre spojeni, jakmile predlozite neplatny certifikat.
Nasadit duveryhodny certifkat zni strasne snadno, dokud se nepodivate do DNS a nezjistite, pro kolik ruznych jmen ho budete potrebovat, potazmo v kolika ruznych domenach musite predelat MX zaznamy, abyste vsude pouzili to jedno jmeno, pro ktere mate SSL certifikat.
„Parkrat jsem si s tim hral a vetsina tech co SSL pouziva to ma implementovane spravne a uzavre spojeni, jakmile predlozite neplatny certifikat.“
Což je možná formálně správně, ale přijde mi to nelogické - tedy alespoň dokud nemá protistrana šifrování nastavené jako povinné. Takhle se totiž dostáváme do situace:
- neumím STARTTLS, pošta mi normálně chodí nešifrovaná
- naučil jsem se STARTTLS, ale prokážu se certifikátem, kterému protistrana nevěří - a protistrana odmítne doručovat. Proč? Vždyť by doručila i plaintext. Nedůvěryhodný certifikát přece není o nic méně bezpečný než plaintext, se kterým nemá problém (naopak je bezpečnější, je potřeba MITM, nestačí pasivní poslech)
A ještě horší je to s ověřováním odesílající strany: pokud bych chtěl zabránit ověřováním certifikátu útoku MITM, tak musím (kvůli odstranění STARTTLS útočníkem) ověřit i certifikát druhé strany (ne pouze protistraně předkládat ověřený certifikát). Ale vzpomínám si, že jsem musel autorizaci odesílající strany (TLS klienta) přestat požadovat, protože jsou SMTP servery, které sice na TLS při odesílání přejdou, ale odmítnou se identifikovat certifikátem.
"lepší nedůvěryhodné TLS spojení než zcela nezabezpečené" - tak s tímhle nesouhlasím. Nedůvěryhodné TLS spojení dává pouze falešný pocit bezpečí, který je mnohem nebezpečnější než poctivě priznané nebezpečné spojení. Když si totiž nebudu nalhávat že spojení je zabezpečené, budu se podle toho chovat - nedůležité maily prostě pošlu, důležité zašifruji (např. pomocí GPG).
Navíc celé SMTP STARTTLS je dost pochybné z principu - když pomocí MITM z ohlašování schopností serveru odeberu STARTTLS, SMTP klient klidně pošle útočníkovi data nešifrovaná (ten je pak dál serveru už může poslat zašifrovaná).
A ještě jeden důvod proč SMTP STARTTLS je pochybné zapezpečení: poskytovatel hostingu SMTP serveru může být kdykoliv donucen vydat privátní klíč (např. dumpem paměti v případě VPS nebo obsahem disku kde klíč taky může být nešifrovaný), takže spoléhat na toto zabezpečení je opět pouze falešný pocit bezpečí. Myslím že Petr Šťastný si tohoto musí být vědom, jsem přesvědčený že kdyby firma ve které pracuje dostala takový soudní příkaz tak data klientů také vydá.
SMTP TLS v současné době na veřejném Internetu MITM nezabrání, to je ve článku zdůrazněno. Šlo by to jen kdyby úplně všechny servery používaly a současně vyžadovaly důvěryhodné certifikáty. Ale to aktuálně nejde. Takže pokud to někdo chce myslet s bezpečností svých dat vážně, musí použít end-to-end šifrování.
Také je potřeba rozlišit pohled, ze kterého se na to celé díváme. Třeba administrátor SMTP serveru může právě ovlivnit šifrování SMTP, ale end-to-end šifrování jde mimo něj. Naopak koncový uživatel neovlivní co se děje na cestě mezi odesílatelem a příjemcem (a 99,99% lidí je to úplně jedno a ani neví jak to funguje), ale může šifrovat své zprávy před odesláním.
Podle mého názoru zapnutím TLS na serverech admini rozhodně nic nezkazí. Bude to lepší než předtím. Samozřejmě je vhodné, aby admin dobře celé problematice rozuměl a byl si vědom výhod, nevýhod a možných komplikací (a třeba i toho falešného pocitu bezpečí).
Nesouhlasis zcela zbytecne ...
1) "duverovat" jakesi "autorite" - tedy zcela cizimu subjektu, se kterym nemam v uzavrenou ani zadnou smlouvu, a ani neznam jeho interni procesy ... je naprosta magorina
2) autorizovat certifikat kazdyho potencielniho komunikacniho parnera je zcela nerealny technicky
3) tudiz TLS neni nastrojem k overeni protistrany, ale nastrojem k zamezeni odposlechu dat cestou - a v takovym pripade je mi zcela uprdele, jaky certifikat protistrana pro sifrovani pouziva.
Samo, mohl bych (rekneme) jeste maily rozrtidit dle 3 kriterii
a) ty, ktere prisly od certifikovaneho a autorizovaneho subjektu
b) ty, ktere dorazily sifrovanym kanalem, ale neplati pro ne bod a (pricemz netusim, zda nekde cestou nesly kanalem zcela nesifrovanym)
c) ty, ktere dorazily jako open text
A samozrejme, presne totez plati trebas pro https, kde je pro me kdokoli s selfsignet certifikatem naprosto stejne duveryhodny, jako kdokoli s certifikatem od verisignu. V oboou pripadech, pokud uz se rozhodnu certifikatu "duverovat", dam si do stromu duveryhodnych jen a pouze prave ten jedinej certifikat.
Tak to uz je zcela na me, ovsem. Kdyz se mi nekdo na ulici predstavi "Pepa z depa" ... tak mu taky verit muzu a nemusim. Stejny je to s tema certifikatama. Kdyz si po vyskoceni oblibene hlasky o "neduveryhodnem" certifikatu tento pridam mezi duveryhodne, tak jediny co vim je to, ze priste komunikuju se stejnym subjektem - tedy tim, kdo ma ten klic pod kontrolou. A kdo to realne je, je mi dost casto zcela jedno.
Az budu mit potrebu komunikovat zabezpecene se snowdenem, tak si snim vymenim klice na ryzovem papire, ktery vzajemne po overeni pred sebou zblazjneme (samo, s nalezitou dobou nasledneho dohledu, aby doslo k dokonalemu straveni) ;D.
Říkáš to vše dobře, ale ještě bych chtěl poukázat na jednu natolik samozřejmou věc, že může leckdo na ni zapomenout.
Nestačí přijmout jméno neznámého cizince a použít jeho self-signed certifikát. Ještě je třeba věřit, že zrovna on je jediným držitelem soukromého klíče. Osobně bych řekl, že zde je takový self-signed certifikát důvěryhodnější než složitý řetězec certifikátů končící u neméně pochybné CA.
Ciste z principu pravdepodobnosti ... defakto neni co resit, selfsigned je radove bezpecnejsi. Uz jen proto, ze utok vedeny na nejakou tzv "duveryhodnou" autoritu je o nekolik radu pravdepodobnejsi.
Mimochodem, ted sem si tak vzpomel, ze kdysi sem nekomu zarizoval nejaky podpis pro bankovnicvi, a co me dostalo do kolen, ze sem se kolem toho asi mesic s bankou dohadoval, protoze oni chteli vse generovat na svy strane ... s tim ze klic nasledne klientovi predaji na diskete (na nicem jinym to neumeli) ... a ja se snima dohodoval kvuli tomu, ze sem jim hodlal dat k dizpozici pouze verejnou cast klice. Nakonec sem se dohadal na nejakyho admina, kterej mi samo odkejval, ze mam pravdu. Ale kterej ustav choromyslnych to byl si bohuzel uz nepamatuju ... ovsem myslim ze kdyz strelim nekam kolem KB/CSOB ze nebudu moc vedle.
Nemuzu, protoze se tak nechova ... trebas revokovat ho klidne muze ta autorita, a ja ani drzitel stim nic neudelame. Jiste, muzu tuhle ficuru pominout a nepouzivat ji.
Navic uz jen to, ze ten certifikat je nekde evidovanej = potencielni bezpecnostni riziko. Jednoduse se vi komu patri (nebo se to aspon tusi) a to v mnoha pripadech je celkem zasadni problem.
„a ja ani drzitel stim nic neudelame. Jiste, muzu tuhle ficuru pominout a nepouzivat ji.“
No vždyť o to právě jde - chovej se k němu jako k selfsigned, když ti CA vadí! Selfsigned taky nerevokuješ, tak revokace ignoruj.
„Navic uz jen to, ze ten certifikat je nekde evidovanej = potencielni bezpecnostni riziko. Jednoduse se vi komu patri (nebo se to aspon tusi) a to v mnoha pripadech je celkem zasadni problem.“
To si teda upřímně řečeno nedokážu moc představit (ostatně ten selfsigned je vystaven na veřejném mailovém serveru)…
Jakou mam moznost si overit, ze ty procesy dodrzuji? Aha, presne nulovou. Kolik tech "overenych" autorit uz vydalo certifikaty v rozporu s temi procesy? Vim minimalne o desitkach pripadu. A to jsou jen ty, kdy se to proflaklo. Realne jich bude minimalne o rad nebo dva vic.
Jedinej duverychodnej zpusob jak overit certifikat je ho ziskat primo od dotcene osoby. A ani to nezaruci, ze jej nepreda nejake treti osobe.
U státem akreditovaných autorit má možnost kontroly určitě stát. Nevím, jak je to u zařazení mezi důvěryhodné autority Firefoxu nebo Microsoftu, zda tam existuje nějaká možnost kontroly. Každopádně to, že nic nevíte o interních procesech CA, je jen váš problém. Pokud jste chtěl napsat, že nemáte možnost ověřit si dodržování stanovených postupů, neměl jste psát, že o interních procesech nic vědět nemůžete.
U státem akreditovaných autorit má možnost kontroly určitě stát.
No jistě, viz DigiNotar :-))))))
Statem "akreditovane" autority jsou naopak naprosto neduveryhodne. Na ty uplatnuju vseobecny ban.
Mimochodem, mr Jirsak jiste chodi pravidelne na audit ke kazde "autorite", vcetne tech statnich, takze jiste muze napsat, jak to tam chodi ... Ono totiz sehnat certifikat na "pepu z depa" neni nijak zasadni problem. Staci nejakyho nabrat na ulici a dat mu na pivo.
Má ten váš argumentační postup nějaký název? Já bych to nazýval třeba "krok stranou". Vždy něco napíšete, a když vám někdo oponuje, napíšete "to nevadí, ale" a vymyslíte si něco nového. Nevadí vám ten drobný detail, že takhle žádnou svou tezi nikdy neobhájíte?
Nevím, na základě jakých dojmů považujete za nedůvěryhodné všechny státem akreditované autority. Ani nevím, co se změnilo, že jste před pár komentáři o interních procesech autorit nevěděl zhola nic, a teď už víte, že není problém získat certifikát na "pepu z depa". Za to bezpečně vím, že certifikát "pepy z depa" vám pro konfiguraci TLS pomůže jedině tak, že jím podepíšete objednávku, aby vám to nakonfiguroval někdo, kdo tomu aspoň trochu rozumí, a neplete si osobní a serverový certifikát.
I tupec jako jirsak kterej placa zcela z cesty by moh aspon tusit, ze serveru je zcela uprdele jakej certifikat se pouzije, maximalne tak vyskoci hlaseni nekam do logu, ze nejde o certifikat urceny pro server.
A jelikoz je zaroven rec i o sifrovani komunikace klientem, tak by i jirsak moh tusit, ze pro takovy ucel je takovy certifikat zcela spravny a korektni (zcela bez ohledu na to, co si plka stat/"autorita" ve svych pravidlech).
Nehlede na to, ze jaksi ty statem certifikovane autority v zadnem pripade nevydavaji zadne serverove certifikaty ... mozna tak maximalne jako zcela soukromou akci, na kterou se ovsem zadny statni dozor nevztahuje (to by ovsem mr Jirsak jakozto auditor taky mohl aspon tusit).
Takze jirsak necht dal resi jak je povoleny TLS bez "duveryhodnyho" certifikatu vlastne na nic, a mi vsichni ostatni, budeme vesele dal posilat maily pomoci TLS/SSL se selfsigned certifikaty, protoze nam je celkem jedno kdo je protistranou, nebot vsichni vime, ze tento typ zabezpeceni komunikace funguje jak funguje.
Proč věřit organizaci, která není zrovna moc závislá na ochotě zákazníků jí za její služby platit? Jaká je tu motivace chovat se čestně?
Proč mít mezi důvěryhodnými certifikačními autoritami nějaké, které se používají jen na pár webů, které nejspíš nikdy nebudu potřebovat? A proč důvěřovat třeba čínské vládě?
to: Filip Jirsak
o tom jak to "interne" chodi u "statem uznanych CA" se muzete dovzdelat zde: http://www.youtube.com/watch?v=XCjoJePnRBY
pripadne zde http://www.youtube.com/watch?v=ibF36Yyeehw
Jestli mi něco neuniká, tak pokud se použije šifra s (EC)DHE, tak samotné pozdější prozrazení soukromého klíče nestačí k prolomení šifry. Diffie-Hellman tam zajišťuje perfect forward secrecy a jen soukromý klíč nestačí k dešifrování komunikace. K tomu by bylo nutné znát ještě klíč vyjednaný Diffie-Hellman výměnou, což z odposlechnuté komunikace nelze.
Nebo mi něco uniká?
to P: Myslim ze ti neuniklo nic- jeto tak jak rikas. Pri pouziti DHE (Diffie-Helman-Ephemeral) ani prozrazeni pocatecniho klice neznamena zkompromitovani cele nasledujici (odposlechnute) komunikace. Pokud vladnes anglinou tak tady to rozebiraji https://www.grc.com/securitynow.htm
--> Episode #411 | 03 Jul 2013 | 103 min. Listener Feedback #171
Myslim ze jeto nak ke konci= odpovidaj tam na otazky posluchacu a 1 z nich je prave ta tvoje. Pokud davas prednost psanemu textu tak tady je prepis celeho podcastu
https://www.grc.com/sn/sn-412.htm
=jeto lepis na vyhledavani :o) takze zadej jen DHE anebo Ephemeral a jses tam kde potrebujes.
Zrejme jsem se prehlid' = ten podcast ohledne DHE na kterej odkazuju je tento:
Episode #412 | 10 Jul 2013 | 95 min.
SSL & Perfect Forward Secrecy - link na prepsanej text podcastu je ale spravne=
https://www.grc.com/sn/sn-412.htm
staci dat ve FF vyhledavavni v textu a treba ECDHE a jses kde potrebujes! ;o)
Omlouvam se za prehmat.
Jenže pak by celé SSL bylo skoro k ničemu. Útočník MITM by prostě použil svůj certifikát – a nebylo by jak se MITM útoku bránit.
Problém není v tom, že se po STARTTLS vyžaduje důvěryhodný certifikát, problém je v tom, že není snadné pro některé domény SSL vynutit. Na webu se to řeší poučením uživatelů „do banky jedině přes HTTPS“, bude potřeba umět stejně instruovat i SMTP klienty. Ideální by bylo mít na to příznak v DNS (a pak už tam rovnou může být i ten certifikát…).
Za současné situace každopádně odmítnutí nedůvěryhodného certifikátu při komunikaci mezi servery, které se neznají, ničemu nepomůže. Protože nemá smysl dělat MITM, stačí udělat něco jako stripSSL a projde to. Aktivní útok je tak jako tak možný, pasivnímu útoku (v případě bezpečnosti použitých šifer apod.) zabrání i self-signed certifikát.
Kdyby dnes ten protokol fungoval tak, že neúspěšný pokus o navázání SSL spojení nevadí, bude se později muset vytvářet ještě další protokol, který bude odolný i proti MITM.
Se současnou implementací ale má odesílatel možnost volby. Pokud chce někam e-maily posílat bezpečně, povolí pro danou doménu jenom SSL, případně zafixuje CA certifikátu příjemce nebo rovnou jeho certifikát. Pokud použití SSL nevyžaduje, měl by si klient neúspěšné pokusy o navázání SSL nějakou dobu pamatovat a při opakovaném posílání SSL nenavazovat.
Je to stejné, jako u HTTPS. Tam také uživatel řekne, že vyžaduje HTTPS, prohlížeč se pokusí navázat bezpečné HTTPS spojení, a pokud to nejde, měl by uživateli dát na výběr, zda pokračovat i s nezabezpečeným HTTPS nebo HTTP. Akorát u toho e-mailového klienta nevolí uživatel dodatečně, ale spíš správce předem určí pravidla.
Certifikáty v DNS řeší protokol DANE, ale ten se musí nejprve dostat do všeho softwaru, do povědomí lidí a musí na něj všichni přejít. Pak toto všechno bude mnohem jednodušší a nezávislé na certifikačních autoritách. Ale to bude ještě mnoho let nebo desítek let trvat. Mezitím se musíme spokojit alespoň s něčím.
V Postfixu nedávno přibyla podpora pro TLSA záznamy z DANE, ale zatím je to v alpha fázi. Jsou zmíněny i v README - http://www.postfix.org/TLS_README.html.
Zatím bych DANE/TLSA podporu v Postfixu bral jako experimentální, protože její autor Viktor Dukhovni si vymyslel, že reinterpretuje RFC 6698 "trochu podle svého" - např. zaměňuje certificate usage 0 a 2.
Existence TLSA záznamu ještě neznačí, že se musí TLS použít (na to bohužel zatím žádný záznam neexistuje).
„Jenže pak by celé SSL bylo skoro k ničemu. Útočník MITM by prostě použil svůj certifikát – a nebylo by jak se MITM útoku bránit.“
Já se pozastavoval nad tím, že když útočník podvrhne svůj certifikát, tak se spojení přeruší, ale když prostě smaže z capabilities "STARTSSL", tak se mu e-mail vesele pošle.
„Problém není v tom, že se po STARTTLS vyžaduje důvěryhodný certifikát, problém je v tom, že není snadné pro některé domény SSL vynutit.“
S tím jednoznačně souhlasím.
„Na webu se to řeší poučením uživatelů „do banky jedině přes HTTPS““
Ještě by to chtělo „do banky jedině přes HTTPS a pozor na certifikát…“.
„Ideální by bylo mít na to příznak v DNS (a pak už tam rovnou může být i ten certifikát…).“
Přesně tak.
Já se pozastavoval nad tím, že když útočník podvrhne svůj certifikát, tak se spojení přeruší, ale když prostě smaže z capabilities "STARTSSL", tak se mu e-mail vesele pošle.
Je to sice nelogické, ale když vedle sebe dáte požadavek na bezpečné TLS a zpětnou kompatibilitu (nešifrované SMTP), vyjde z toho tohle. Jiná řešení jsou ještě nelogičtější, proto tohle vyhrálo.
Nechápu. Dokážete vymyslet nějaký attack vector, který půjde provést v konfiguraci (1), ale nepůjde provést v konfiguraci (2)?
(1) Poštovní server pošle mail ve všech třech případech (protistrana nepodporuje STARTTLS, protistrana má nedůvěryhodný certifikát, protistrana má důvěryhodný certifikát)
(2) Poštovní server pošle mail pouze pokud protistrana nepodporuje STARTTLS nebo protistrana má důvěryhodný certifikát; pokud protistrana má nedůvěryhodný certifikát, mail nepošle
Ale ne ... sak se podivej na jirsakovo argumentaci ... ty si prece myslis, ze v pripade ze protistrana pouzije nejaky certifikat, ze jde o zcela konkretni protistranu ... sice nevim proc by sis to mel myslet, ale jirsak si to zjevne tak predstavuje ... mno a protoze ja jako utocnik te chci presvedcit o tom, jak moc sem duveryhodnej, tak si vygeneruju certifikat mno.... spokojenost bude oboustrana ... nebo ne? ;D
Me by zajimalo, jestli taky jirsak pri kazdym spojeni overuje OCSP (pokud teda aspon tusi vocogo) ... a pokazdy, kdyz srv neodpovi (=tak 50% pripadu ...) odmitne mail prijmout, bez ohledu na platnost certifikatu. Protoze to je jedinej spravnej a bezpecnej pristup.
Proto ff (by default) zrusil zobrazovani protokolu ... aby zvysil ten pocit bezpeci a aby se user nezabejval takovou zbytecnosti jako je protokol ... ;D
Certifikat v domene uz je ... a je tam uplne khownu. Ale jo, pridejme tam jeste dalsi a dalsi ... kupodivu ale existence mailserveru neni nijak podminena existenci domeny a naopak.
Navic tu uz minimalne par let existuje nastroj, kterej muze (z casti) poskytnout overeni protistrany ... a defakto nikdo ho nepouziva. jop, mluvim o SPF. Takovej ten trivialni textovej zaznam kterej rika, ktery servery sou za danou domenu opravneny odesilat maily.
Jinak (kupodivu) je mail zalozenej prave na tom, ze mi muze napsat kdokoli, aniz bych ho musel predem znat. Kdybych mel dovolit dorucovani jen tem "duveryhodnym" .. tak bych se snima nejdriv musel nejak seznamit ... abych jim moh duverovat ...
„Certifikat v domene uz je ... a je tam uplne khownu.“
Pokud by klient podporoval pinning (třeba SSH už umí, jinde nevím), tak ne.
„kupodivu ale existence mailserveru neni nijak podminena existenci domeny a naopak.“
Jako že posíláte maily na jenda@[77.87.241.77] nebo co tím myslíte?
„Navic tu uz minimalne par let existuje nastroj, kterej muze (z casti) poskytnout overeni protistrany ... a defakto nikdo ho nepouziva. jop, mluvim o SPF.“
Myslím, že řešíte úplně jiný problém. Tady se řeší odposlech, nikoli podvržení.
„Jinak (kupodivu) je mail zalozenej prave na tom, ze mi muze napsat kdokoli, aniz bych ho musel predem znat.“
No ale minimálně musí znát mailovou adresu. Nemohl by k ní znát i asymetrický klíč, kterým má zprávu zašifrovat?
Dane,
Viktor Dukhovni připravil draft se specifikací použití DANE pro SMTP a zároveň vyrobil funkční implementaci pro Postfix, která už je obsažena v posledním snapshotu vývojové verze 2.11.
Mám připravené PPA pro Ubuntu i s krátkým návodem, jak to zprovoznit:
https://launchpad.net/~ondrej/+archive/postfix+dane
O.
Celou cestu ohlídat nejde: v hlavičkách je to sice zapsáno, ale tomu nemůžete zcela věřit (informace může být po cestě zfalšována útočníkem MITM).
Nicméně většina e-mailů prochází jedním důležitým "veřejným skokem": to když je poslána z (posledního) serveru odesilatele na (první) server příjemce. U tohoto skoku lze TLS detekovat/vynutit (pokud ovládáte jeden ze serverů).
Internet i sifrovani obecne nejsou a nebudou pred odposlouchavanim zcela bezpecne. Tajne sluzby do rozsirenych "bezpecnych" sifrovani a sluzeb casem vzdy prosadi backdoor, staci trochu postrasit autora. Idealni komunikace je napsat zpravu na papir a poslat poslem, nebo lokalni sit vubec nepripojovat k internetu. Viz nedavne napadeni site Tor, nebo opravneny strach, co ted ma autor jiste az prilis svobodne distribuovane site o tom hodne vypovidaji.
TrueCrypt není open source, ale freeware se "source available". Vývoj je neveřejný. Na vývoji se nelze podílet. Tvůrci jsou anonymní. Neexistuje žádné veřejné code-review, které by provedl odborník kryptoanalytik. Neexistuje žádný veřejný výzkum, který by ověřil, že nabízené instalační soubory odpovídají těm zveřejněným zdrojákům.
Opravdu někdo založí svoji bezpečnost na takovémto softwaru?
Že TrueCrypt pochází přímo od tajným služeb je na úrovni dohadů. Ale opravdu někdo po případech Stuxnet a Snowden zůstal tak naivní, že si myslí, že takovéhle programy píše někdo anonymně po večerech pro dobrý pocit?
Lepší než drátem do oka...
http://www.root.cz/clanky/truecrypt-profesionalni-ochrana-dat-zdarma/
Ale jinak:
http://www.root.cz/clanky/nova-analyza-bezpecnosti-truecryptu/
(neboli, těch 63,5 KiB je zatím opravdu backdoor strašidlo, které zatím nikdo nevyvrátil)
A samozřejmě:
http://www.privacylover.com/encryption/analysis-is-there-a-backdoor-in-truecrypt-is-truecrypt-a-cia-honeypot/
Možnost detekce Hidden volume? http://www.root.cz/clanky/nova-analyza-bezpecnosti-truecryptu/nazory/399456/ (Neověřoval jsem dále.)
(Ale je fakt, že HV i z dalších důvodů není úplně plausibly deniable.)
http://www.pepak.net/bezpecnost/skryte-oddily-a-plausible-deniability/
Ostatně, ve článku http://www.pepak.net/bezpecnost/nova-analyza-bezpecnosti-truecryptu/ po něm někdo v diskuzi chtěl, aby se na to mrknul, a zatím tedy nic, bohužel...
TL;DR, ale v TC je to defective by design. https://www.abclinuxu.cz/clanky/steganograficke-souborove-systemy-a-verohodna-popiratelnost#proc-verohodna-popiratelnost-v-truecryptu-neni-uplne-verohodna
To já bych zase odhadoval že ty budeš od některé tajné bezpečnosti a budeš záměrně dělat dusno kolem TrueCryptu.
To že nikdo neověřuje zdrojové kódy oproti binárkám a vlastní funkčnost aplikace není pravda. Neděje se to zřejmě neustále a neděje se to zřejmě komplexně, už vůbec se to vždy neděje veřejně, ale děje se to.
Vzpomínám na celou řadu studijí. Myslím že naposledy jsem nejvíce viděl rozpitvanou verzi 6.1a.
V každém případě věřím, že pokud projdete pár fór (včetně toho TrueCryptu) tak se s výsledky některých testerů budete moci blíže seznámit.
V případě zásadní nedůvery je to jednuduché, TrueCrypt nepoužívat.
Bez zdůvodnění proč že má SW backdoor, nebo proč je špatně napsaný, působíte nedůvěryhodně mnohem více než zmíněný SW. Takový malý provokatér. Ale pokud něco opravdu víš, tak to uveřejni, takové zprávy jsou prověřovány mnohem více než kompletní sledování činosti TrueCryptu a kompletní procházení jeho kódu.
Je vás na Internetu hodně Martinů Prokešů, pokud by jsi náhodou byl ten z Ostravy tak je to jasné. Vy tam vyvíjíte nějaké sračky pro EU pro sledování lidí a monitoring Internetu a věřím, že klidně dostali zaplaceno i za demagogii a cosiální kecy.
Neni to OS v politickym slova smyslu, ale ma otevrene zdrojaky => kdokoli je muze analyzovat. Zatim se kupodivu nenasel nikdo, kdy by neco relavantniho namital.
Pro me a pro 99,99999% uzivatelu je to na presne stejny urovni, jako sifrovani integrovany do tuxe nebo do widli. Sou k tomu taky zdrojaky (i k tem widlim ...), ale nebudu venovat 1/2 zivota na to, abych to analyzoval.
A pokud se pak budeme bavit (trebas) o widlich, pak je to pro me daleko duveryhodnejsi appka nez widle samotne. Pro me, stejne jako pro tebe je totiz daleko pravdepodobnejsi, ze se ve tvejch datech bude chtit rejpat PCR, na zaklade podezreni ze znasilneni ... (nastroj prece mas ...) nez ze se o totez bude pokouset NSA. A jelikoz PCR nerozezna HDD od CDROM ... tak sem si temer jistej, ze i prosty xorovani by pro ne byla neproniktunelna sifra.
no na to ze v TrueCryptu maj (podle tebe) tajny sluzby backdoor tak ho asi moc nepouzivaj viz. http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-truecrypt/ Anebo zebysi to tajemstvi nechavali pro sebe i kdyz jde o bankere kterej pral $ pro drogovy kartely?? Tech pripadu kdy si urady vylamaly zuby na TC je vice=staci googlit. Na kod TC se divalo vicero lidi a neslysel jsem dosud ze by ten soft nekdo zpochybnil - ano pokud si user zvoli heslo Monkey12345 pak se doctes ze "byl odsouzen na zaklade dat zasifrovanych TrueCryptem", to ale jde o debilitu uzivatele nee o spatny ci zkrompromitovany crypto..... Ovsem u Bitlockeru uz bych si tak jistej nebyl-obzvlast ve svetle poslednich udalosti http://americablog.com/2013/08/leaked-german-government-warns-key-entities-use-windows-8-computers-potential-backdoor-nsa.html
„Tajne sluzby do rozsirenych "bezpecnych" sifrovani a sluzeb casem vzdy prosadi backdoor, staci trochu postrasit autora.“
To je dost odvážná myšlenka. Nemyslíte, že když je projekt OSS, občas by se na to přišlo? Neříkám, že ve všech případech, ale že by ani v jednom?
„Idealni komunikace je napsat zpravu na papir a poslat poslem, nebo lokalni sit vubec nepripojovat k internetu.“
To je bohužel pro mnoho lidí technicky nemožné (potřebují výhody elektronické komunikace a potřebují ji přes větší síť).
Stejnej problem jako "duveryhodnej" certifikat. Musis nejdriv vsem potencialnim pisatelum nejak sdelit verejnou cast svyho klice (a samo, idealne tak, aby oni meli jistotu, ze to je fakt tvuj klic). A jak to udelas, kdyz mail je z velky casti zalozenej na tom, ze ti muzou napsat lidi, ktery si nikdy nevidel?
A pak narazis na dalsi neprijemnost - nutnost ty klice pravidelne obmenovat, coz znamena si rekneme aspon jednu za rok poslat vzajemne nejaky mail s kazdym, s kym chces byt jen potencielne komunikovat.
No a ted si predstav, ze mas 20, 30let stejnej mail. Zna ho spouta tvych znamych, spoluzaku, ... a nekteri se ozvou trebas 1x za 10let ... (rekneme ti spoluzaci).
Můj klíč podepisují lidé co mě znají, což je lepší než nějaký certifikát. Změna klíče není problém. Je veřejně vystaven na serveru, podroben veřejné kontrole, tak při jeho změně si nový klíč každý stáhne. Nemusím nikomu nic posílat.
Každému pisateli svůj klíč můžu připojit k mejlu, nehledě k tomu, že mé mejly jsou podepisovány, tak není problém pro znalého dovodit, že šifruji.
Zjevně seš woknař, protože nemáš o tom vůbec páru. Linuxák tohle má v systému a šifrovat poštu pro něho není problém.
A budeš se divit. Woknaři v IT servisních firmách jedou na nějakém PGP a zákazník jim takto posílá přístupová hesla do systému. A moje GPG signature.asc dokonce jeden státní úřad vzal jako podpis a odpověděl mi na můj dotaz písemně s kulatým razítkem. :-)
A zvolil sis úplně blbý příklad. Pro mé známé a spol není problém v mejlu ověřit pravost mého klíče kontrolní otázkou.
Já neřeším odposlech pošty (komunikace) třípísmennými parchanty, ale její šifrování proti čtení obecně. A i když mi píšou šifrovaně lidi co jsem v životě neviděl, tak co si jako myslíš, že s nimi řeším?
Chjo ...
Jak vim, ze ten certifikat patri nejakymu skocdopolovi a ne voprsalkovi? To jako poznam z toho, ze to o nem tvrdi nejakej pepek vyskoc? Jo aha, on pepka vyskoce podepisuje zase nejakej co se menuje pius 14.
Ano, certifikat muzes pripojit k mailu ... a co kdyz ti budu chtit napsat za 2 roky? Aha, to sem vprdeli, to ti nejdriv musim napsat nesifrovane, aby ses ozval a poslal mi certifikat ... ale ty takovej mail v ramci "bezpecnosti" zrejme vubec neprijmes ... tak to asi nedostanes tu zakazku za 20M. Zato franta odvedle, kterej na sifrovani kasle, zakazku dostane, protoze mu mail dorazi.
Zjevne ses tupec, protoze pgp funguje uplne stejne v tuxovi i widlich (tedy "funguje" pokud se zrovna nepodela prislusny plugin - v obou pripadech). A kupodivu, urad ma povinost odpovedet i na zcela nepodepsany mail - a to zcela dle uredniho postupu, tudiz pokud ta odpoved vyzaduje uredni ukon, tak trebas i pisemne. Takze se namahas zcela zbytecne.
A samo, jako bonus ... pokud nebudu maily komplet preukladat, a budu je chtit uchovavat v puvodni (zasifrovane) podobe, budu nucen snimi nejak nekde, pokud mozno aspon v 10ti kopiich na ruznych mediich a mistech ... uchovavat prave ty klice, a to vsechny a navzdy, byt uz neplatne, protoze jinak ty maily uz nikdy neprectu.
No a to je pro tvou informaci jeden z mnoha opruzu stim spojenych, kvuli kterym to defakto nikdo nepouziva.
Bezpecnost je totiz fajn ... presne do okamziku, nez se z toho stane vopruz. V ramci bezpecnosti bych ti dal do auta 5tibodovy pasy. Sou o moc bezpecnejsi nez 3bodovy ... fakt bych chtel videt, za jak dlouho je z toho auta vytrhas.
„Jak vim, ze ten certifikat patri nejakymu skocdopolovi a ne voprsalkovi?“
Jak víš, že ta e-mailová adresa patri nejakymu skocdopolovi a ne voprsalkovi?
„Ano, certifikat muzes pripojit k mailu ... a co kdyz ti budu chtit napsat za 2 roky?“
Stále mi můžeš napsat a zašifrovat to mým prvním klíčem (2007). Při pohledu do své klíčenky vidím (funkční) klíče svých kamarádů, které mají běžně data 2002-2005.
„pokud nebudu maily komplet preukladat, a budu je chtit uchovavat v puvodni (zasifrovane) podobe“
To je jen a pouze tvůj problém, respektive problém tvého mailového klienta, že něco tak triviálního neumí udělat automaticky.
chjo ... kdybys aspon cet
Ten mail mi nejspis ten voprsalek rek osobne, ze ... a i kdyz si najdu neci mail na webu, tak je mi prevazne jedno kdo to je, ac se nejak jmenuje, tak snim resim nejakou konkretni vec. Tudiz je mi uprdele, jestli se menuje voprsalek nebo skocdopole. Pokud chci s nekym komunikovat zabezpecenym kanalem, asi mi to az tak jedno neni, ze. Protoze pokud mi to jedno je, je zbytecny cokoli sifrovat, kdyz stejne nevim, s kym si vlastne to DP posilam ... zejo.
Ty akceptujes maily podepsany neplatnym podpisem? Potom ale nedodrzujes naprosto nejzasadnejsi bezpecnostni pravidla => tvoje sifrovani je zcela khownu.
Boze a o cem myslis ze je tu celou dobu rec? Zeby o tom, ze sifrovani je neskutecnej vopruz? Zadnej klient ti toto nevyresi, protoze to nema zadny reseni. Pokud chces dodrzovat pravidla bezpecnosti a pripadne pravidla autenticity, tak musis velmi peclive vse zalohovat ... a kolik lidi veci zalohuje vubec nejak?
„Ten mail mi nejspis ten voprsalek rek osobne, ze“
Pokud ti ho nadiktoval, nemohl ti k tomu říct ještě 80 bitů identifikujících jeho klíč? V případě ústního předání to může být trochu opruz (je to 16 náhodných znaků navíc), ale třeba na vizitce je to v pohodě.
„Ty akceptujes maily podepsany neplatnym podpisem? Potom ale nedodrzujes naprosto nejzasadnejsi bezpecnostni pravidla => tvoje sifrovani je zcela khownu.“
Prosím rozvést. Mail podepsaný neplatným podpisem beru jako nepodepsaný.
„Pokud chces dodrzovat pravidla bezpecnosti a pripadne pravidla autenticity, tak musis velmi peclive vse zalohovat ... a kolik lidi veci zalohuje vubec nejak?“
Ale pak přijdou o ty maily tak jako tak a je jedno, jestli jsou šifrované nebo nešifrované, ne? A zálohování klíče - těch ~200 bitů se dá opsat na papír třeba ve formě 19 slov.
Jiste, kazdy prumerny uzivatel mailu si bezne pamatuje sifrovaci klice sve rodiny, vsech svych znamych ... aby jim mohl zcela bezpecne a sifrovane poslat mail ze sveho seznamu ...
Pokud ti poslu mail, ktery bude podepsan expirovanym klicem (nebo jim zasifrovan) tak se ti stejne dobre muzu predstavit jako papez, protoze ten klic muze uz davno postradat jakykoli prvky bezpecnosti. Proto se ty klice kupodivu meni.
A ne, o nesifrovane maily neprijdou, kdyz se jim zcela verejne valej vsude po netu. Kdezto kdyz prijdou o klice k tem sifrovanym, tak se muzou jit leda klouzat.
„Jiste, kazdy prumerny uzivatel mailu si bezne pamatuje sifrovaci klice sve rodiny, vsech svych znamych ... aby jim mohl zcela bezpecne a sifrovane poslat mail ze sveho seznamu ...“
Ne, ale pokud používá náhodné cizí počítače a náhodné freemaily, tak už ho GPG nevytrhne…
„Pokud ti poslu mail, ktery bude podepsan expirovanym klicem (nebo jim zasifrovan) tak se ti stejne dobre muzu predstavit jako papez, protoze ten klic muze uz davno postradat jakykoli prvky bezpecnosti.“
Samozřejmě, ale jenom kvůli tomu ho přece nezahodím.
Jen pro úplnost. To GnuPG (jinou dnešní a bezplatnou implementaci PGP neznám) pro Windows je otřesné a plné chyb. Bezchybně funguje snad jen při ruční práci, pomocí příkazového řádku, a to je prostě nepoužitelné pro běžnou práci.
Odmítám takovou katastrofu mít vůbec na disku. Použil jsem to jen párkrát, od té doby radši důvěryhodnost řeším pomocí hashe a statisticky, než bych to znovu instaloval a ověřoval ASC podpis. Tak asi tak.
mozna zkusit Bitmessage? :o) https://bitmessage.org/wiki/FAQ tady sem o tom napsal trochu vic http://www.root.cz/clanky/korporatni-bezpecnost-mobilne-sifrovat-end-to-end/nazory/ Za tu kratkou dobu co s tim experimentuju to chodi IMHO OK- jestli v tom jsou security holes zatim tezko rict -protokol je prevzatej z Bitcoin ale sami autori upozornujou ze projekt je v testovaci fazi a "Bitmessage is in need of an independent audit to verify its security. If you are a researcher capable of reviewing the source code, please email the lead developer." Zeby nekdo tady z Rootu? :o)
„A jak to udelas, kdyz mail je z velky casti zalozenej na tom, ze ti muzou napsat lidi, ktery si nikdy nevidel?“
Musel jsem jim nějak sdělit mailovou adresu. Proč jsem jim spolu s adresou nemohl sdělit i klíč? Při ústním předání je to nic moc, ale jakmile je to elektronicky nebo vizitkou, tak je to technicky naprosto v pohodě, ne?
„A pak narazis na dalsi neprijemnost - nutnost ty klice pravidelne obmenovat“
8Kib RSA nebo ještě lépe ECDSA nějakou tu chvíli vydrží. Pokud už jó chci obměňovat, můžu podepsat nový klíč starým a tento podpis opatřit časovým razítkem.
z jiného soudku: nezná někdo plugin pro chrome/firefox, který by pro každý web server posílal jiné hlavičky použitelné pro identifikaci uživatele napříč sítěmi? Tedy browser/os/jaké pluginy, verze atd.
Pokud dobře chápu PRISM, tak je to jeden ze způsobů, jak sniffery sledují pohyb uživatele napříč netem.
Nicméně, většina má tenhle otisk hodně shodnej s jinýma lidma, jen pár desítek procent je individuálních, dle těch statistik.
Takovej plugin/rozšíření neznám, ale udělat ho je primitivní. A možná už i existuje... (znám jenom User Agent Switcher, zkus si ho předělat, nebo to někomu dej k předělávce, nebo najdi nastavitelnější alternativu...).
Jak bylo receno, je to trivialni, ale prave tim se muzes dost dobre identifikovat. Lepsi je naopak posilat pokud mozno vsude totez a to prave to, co posila vetsina.
Potiz je trochu v tom, ze ty nekdy chces posilat jiste osobni upravy. Rekneme preferovane jazyky (na zaklade kterych by ti web mel nabidnou prislusnou jazykovou mutaci).
Jinak trebas user agent switcher - asi to neumi nijak automaticky, ale predpokladam, ze dodat tam nejaky random neni zasadni problem. Jen pocitej s tim, ze na zaklade toho co posles muzes dostat ponekud jinej web ... ;D
Prosim o vysvetleni.
Centrum.cz mi a stejne tak vsem, kdo u nej maji schranku umoznuje SMTP pres port 25, jinak ne. To preci neni sifrovane, to by museli umoznit port 587 nebo se mylim?
Seznam.cz mi umoznuje SMTPs pres port 465, teda Seznam je pro me bezpecny, narozdil od Centrumu.
Gmail opet umi smtps na portu 465 a Hotmail smtp na portu 587 TLS, teda sifrovane.
Takze me z toho vychazi nejhur Centrum.
Hmm... co myslis, jak je asi tak slozity ... zajit za spolu(zakem/chlastacem/pracovnikem/...), a rict mu "hele, potrebuju maily nakyho jendy". On rekne tak maximalne "nic sem ti nedal, nikdy sme se nepotlali", mrknem na sebe a tim je to vyreseny.
Nemluve o tom, ze pokud budu mit cileny zajem o neci maily, tak je to vzdy jen otazka nakladu a vynosu. A nakladove je prevazne daleko jednodussi (a predevsim levnejsi) si data proste koupit, nez je lovit nekde v siti.
Pokud se totiz bavime o hodnotnych datech, pak jejich hodnota za urcitych okolnosti muze byt dost zajimava na to, aby si potencielni zajemce to centrum cely koupil. A pokud se bavime o ochrane pres vsemoznymi statnimi smiraky, tak pouzivani freemailu a reseni tls na protokolu je proste lol. Mno a pokud se bavime o ochrane pred sousedem ... pak je ovsem vsechno v loji, kdyz dotycnej odesla maily pres tls, ale prijme je pres pop3, pripadne se prihlasi na web pres http (a sposta freemailu je "uzasne zabezpecena" tim, ze veskery sifrovani konci u zadani hesla).
„Hmm... co myslis, jak je asi tak slozity ... zajit za spolu(zakem/chlastacem/pracovnikem/...), a rict mu "hele, potrebuju maily nakyho jendy". On rekne tak maximalne "nic sem ti nedal, nikdy sme se nepotlali", mrknem na sebe a tim je to vyreseny.“
Zkusil jsem u známých adminů z Centra i Seznamu, neprošlo.
„Nemluve o tom, ze pokud budu mit cileny zajem o neci maily, tak je to vzdy jen otazka nakladu a vynosu. A nakladove je prevazne daleko jednodussi (a predevsim levnejsi) si data proste koupit, nez je lovit nekde v siti.“
Ne, mně k lovení dat stačí stoupnout si doprostřed města s Kismetem.
„Pokud se totiz bavime o hodnotnych datech, pak jejich hodnota za urcitych okolnosti muze byt dost zajimava na to, aby si potencielni zajemce to centrum cely koupil.“
Je jednodušší spustit ten Wireshark nebo si koupit Centrum?
„A pokud se bavime o ochrane pres vsemoznymi statnimi smiraky, tak pouzivani freemailu a reseni tls na protokolu je proste lol.“
Samozřejmě.
„Mno a pokud se bavime o ochrane pred sousedem ... pak je ovsem vsechno v loji, kdyz dotycnej odesla maily pres tls, ale prijme je pres pop3, pripadne se prihlasi na web pres http“
Samozřejmě že jsem předpokládal se SMTPs i IMAPs a HTTPS.
Hm, tohle je pro kocku, protoze jako koncovy uzivatel nemam zadny vliv na to, jak si naseldne servery vymenuji provoz a jak blbe to maji udelano, kolik spionaznich agentur si nekam vnutilo podvodny certifikat, ktery jim vydala nejaka prostituujici se certifikacni autorita a delaji tam MITM.... Inteligentnejsi mi pripada, kdyby konecne na Widlich mailovi klienti zacali podporovat GPG, vcetne Utlouku. Jak si to nesifruji sam, tak ten recept na babovku po babicce mailem stejne neposlu, protoze bych musel nekomu verit a protoze nevim, co na nej NSA ma, tak mu verit nebudu. Bohuzel, Widlaci typicky zadne sifrovani mailu k dispozici nemaji nebo jedou rovnou na Webmailu, takze ja sice muzu u sebe sifrovat, ale pak to nemam komu poslat.
...potom pošlete mail na Gmail, kde si ho po prenesení šifrovaným kanálom spracujú podľa vlastnej úvahy.
Horšie je, že otázne je aj šifrovanie samotnej správy (GPG, S-MIME, ...). Samozrejme, zabráni to Johnovi od Gmailu (alebo Ferovi na Seznam) aby si prečítal čo píšem, lenže NSA (podľa zverejnených informácií) zachytené šifrované emaily archivuje, vraj kvôli prípadnému neskoršiemu dešifrovaniu.
Takže čo je lepšie? Prečítajú a zahodia alebo odložená "naveky"? Sám odpoveď neviem, ale viem, že posielam aj emaily, ktoré nechcem aby boli nielen čítané, ale ani nikde archivované.
A to ochranu pred bezdôvodným narušovaním komunikácie deklaruje už Všeobecná deklarácia ľudských práv, v článku 12 :-(
Ani zďaleka sa nejedná o vyhodenie čohokoľvek kdekoľvek (vrátane defenestrácie). Toto považujem za nebezpečné, pretože to vytvára dojem, že kto šifruje je kriminálnik, či terorista (po starom partizán), a teda, že také šmírovanie je vlastne dôkazom neviny...
Pár nekriminálnych príkladov za všetky: u nás je napríklad povinné hlásenie pracovného úrazu emailom, vrátane osobných údajov urazených, ktoré by určite nemali byť dostupné komukoľvek. Alebo, v žiadosti o sprístupnenie informácií musíte uviesť svoje meno a adresu, a zase sme pri osobných údajoch. A v neposlednom rade, manželka vôbec nemusí vedieť, že tá siahodlhá porada je v krčme na rohu a jej obsahom je kritika súčasného stavu hokeja...
A jiný (donedávna) nekriminální příklad: whistleblowing. Ochrana zdroje informací pro novináře. A všechny případy, kdy z důvodů ochrany soukromí používáme záclony, kalhoty, plavky, šepot, neprůhledné desky, sejfy, slib mlčenlivosti, zpovědní tajemství, lékařské tajemství a čestné slovo.
Pochybuju že uložená "navěky", to by asi nezvládli...
Minimálně to zabraňuje tomu, aby monitorovali všechny maily. Záznam šifrované SMTP komunikace je komukoliv celkem k ničemu, z toho nevydolují nic bez klíče.
Není nemožné ten klíč získat, ale určitě to nejde dělat v takovém měřítku jako u otevřeného SMTP, kde je to téměř bez námahy. Jediné co se z šifrovaného SMTP dá vydolovat je informace o komunikujících stranách, to není moc k statistickému zpracování.
Šifrování SMTP není všelék, ale čtení mailů minimálně znesnadňuje. Když po vás půjdou, tak asi nasadí něco sofistikovanějšího, ale zabrání to masivnímu šmírování veškeré komunikace.
Přesně o tom to je. Stokrát nic umořilo osla. Pokud bude všechno šifrované, tak reálný výkon k dešifraci není a nebude hodně dlouho. A něco ukládat na dešifraci na pozdější časy by mělo smysl jen v nějakých případech, pokud bych chtěl na někoho něco vytáhnout v jeho 90 letech.
Samo, když po tobě půjdou, tak to lousknou. Ale mezi námi, když je to info ke spuštění akce, tak stejně bude pozdě a pokud o něco jde z hlediska dlouhodobé přípravy, tak se to neřeší elektronickými prostředky nebo si jimi předáváte nicneříkající signály, jejichž význam máte domluvené jinými a spolehlivými kanály.
Na každý pád by byly všelijaké šmírovací prosévače obsahu majlů (komunikace obecně) k ničemu.
"Na každý pád by byly všelijaké šmírovací prosévače obsahu majlů (komunikace obecně) k ničemu" No to bys tomu dal! A z ceho by pak vsechny ty sluzby zily? Gmail a spol POTREBUJOU mit moznost hrabat seti v emailech aby ti mohli nabidnout "cilene" sracky o ktery stejne nemas zajem :o)))) + aby te mohli "vyprofilovat" a prodat dal dalsim marketingovejm magorum, pripadne "kupcum ze statniho sektoru" podobne jak to delaj (aspon v USA) ISP a teleoperatori.....viz. http://www.youtube.com/watch?v=t0aQojDGSD4
Ta poznamka ze aktualne probiha setreni zda si teleoperatori neuctovali neopravnene prilis vysoke ceny kdyz federalnim uradum prodavali data o svych zakaznicich me opravdu pobavila- proste Wild West ruulez...gauner okrada gaunera :o)
"Tak nám zabili SSL", oznamuje pani Müllerová...
Dobre, SSL možno americkí kyberteroristi neprelomili, ale šifrovanie Google, Facebook, Microsoft, či Skype áno. Napadli kopu počítačov s cieľom zbierať kľúče, a hoci to nikde nepíšu, verím, že stroje CA sú medzi nimi. Myslím si, že certfikátom SSL (CA) už môžu dôverovať len tí, čo dôverujú USA, lenže to už prestáva byť postoj a začína to byť diagnóza.
Teraz vyšli najavo informácie o špicloch (tá moja paranoja prestáva byť paranojou), nabudúce vykĺzne zbierka kľúčov. SSL/TLS už asi ochráni len pred zvedavým susedom a ani to asi nie nadlho. Čo príde potom? Zrušenie súkromia celkom a vzývanie Veľkého brata? A to sú všetci presvedčení, že Orwell písal o východnom bloku...
Takže: "Paranoici všetkých krajín, spojte sa!" ... a emigrujme - na Alfa Centauri :-(