Nějak jsem nepochopil, proč
- si zařízení nemůže vygenerovat klíč samo a lokálně, nikam ho neposílat
- zprávy bufferovat u odesílatele
- po spojení zařízení se spárovat třeba pomocí D-H a vyměnit si zprávy a potvrzení
Role serveru by byla jenom v tom, že by zařízením sdělil, že je protistrana online a zprostředkoval výměnu. Bez znalosti klíčů by hack serveru provozovatele byl na úrovni MiTM, třeba ISP. A navíc má metadata o tom, kdo, kdy a s kým komunikoval, jak požaduje legislativa...
Zařízení si klíče samo vygeneruje, ale veřejný klíč je potřeba předat protistraně. A ta nemůže bez ručního ověření vědět, zda dostala skutečně veřejný klíč vygenerovaný kamarádem nebo jakýkoliv jiný. Ověření předání veřejného klíče je obecně problém asymetrické kryptografie a třeba na webu ho řeší certifikáty. Pokud uživatel přijme libovolný klíč, pak není odolný proti MitM útoku.
Naopak, jedina cesta, jak mit jistotu, ze jde o me klice, je si je vygenerovat sam. Jakym zpusobem se dostane verejny klic, kam ma, je vec druha. A nejbezpecnejsi bude, dojit tam pesky treba s flash klicenkou :) Pokud nekdo chce co nejvice bezpecnosti, neni lepsi cesty. Stejne tak, jako kdyz si treba firma udela vlastni certifikacni autoritu, sice neoverenou, ale vsem zamestancum ji rucne prida do pocitace. Neni nad duverovat ruznym komodam apod.
Pokial potrebujem taku uroven bezpecnosti, ze mam kluce prenasat osobne offline kanalom, nebudem spravy prenasat komunikatorom typu what's app.
Tiez mam vaznu pochybnost o tom, ci je sprava lokalnej CA-cky spravcom, ktory vacsinou nema absolutne ziadnu bezpecnostnu previerku + vo vacsine pripadov firma ani len nepreveri, ci ma cisty register, naozaj bezpecnejsia ako dovera v nahodnu CA s akym-takym trackom.
Ale tady jsou servery, změna klíče může proběhnout tak, že se ověří proti serveru:
1. Zařízení si vytvoří servisní klíč (SK), s pomocí kterýho komunikuje se serverem.
2. Zařízení pošle veřejný SK na server.
3. Uživatel schválí na základě otisku na webu, že jde o jeho SK.
-- Změna klíče --
4. zařízení vygeneruje komunikační klíč (KK)
5. Zařízení oznámí serveru, že má nový KK a pošle podepsaný veřejný KK
-- Komunikace --
6. Protistrana chce poslat zprávu. Zašifruje ji a odešle na server (přímo to bez IPv6 nejde).
7. Server informuje, že je nový klíč a zprostředkuje jejich výměnu.
8. Protistrana obdrží klíč, jako by se nechumelilo (klidně na každou komunikaci jiný)
9. Protistrana pošle zašifrovanou zprávu
Za pravost certu pak ručí server, ale nemá k dispozici ani jeden KK a nemůže dešifrovat jinou komunikaci, než s ním s pomocí SK. Slabina je pak ověření KK na serveru, ale neumožní to podstrčit klíč třetí strany.
Takže jediná možnost je krádež identity, ale potom uživatel vidí, že krom mobilu a tabletu je na seznamu třetí zařízení a že mu nechodí zprávy.
Souhlasím s tím, že taková zranitelnost je blbá, ale to vyjádření není od Facebooku. Je od OWS, a je mi divné, že by obhajovali něco co by mělo backdoor. A s tím že by to uživatele zmátlo kdyby se zpráva neodeslala pri výměně zařízení mají naprostou pravdu, ale nastavení aby se to dotázalo jestli je změna klíče OK by tam přidat mohli.
Bolo by korektne uviest aj stanovisko samotnych Open Whisper Systems, ktorych sa samozrejme bezne media (ktore potrebuju senzaciu) nic nepytali.
https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/
Podla mojho nazoru nejde o backdoor, iba zle zvoleny default (malo by to standardne zobrazovat tieto spravy). Co sa tyka blokujuceho/neblokujuceho, myslim ze to je v poriadku, inak by to totiz prevadzkovatelovi WhatsApp umoznilo zistit, kto to kontroluje a kto nie.
Možná to ani není tak zlé. Jde o to, že máte službu pro (z hlediska IT) nedotčené masy. Nějaká zpráva o přegenerování klíče po reinstalaci aplikace spojená s dotazem (ano/ne) vede k tomu, že zhruba s 50% pravděpodobností tito nepolíbení uživatelé odpoví špatně (přijdou o dosavadní komunikaci nebo ji zpřístupní někomu jinému).
Co s tím chcete rozumně dělat?
To je jako šifrování disku na notebooku - pěkně chrání soukromí atd., ale v případě, že disk zhavaruje (chybné sektory), tak z nešifrovaného velmi pravděpodobně dostanete alespoň nějaká data, ze šifrovaného možná nic. A když je problém v notebooku (výměna základní desky, včetně TPM), tak s šifrovaným diskem jste totálně v háji.
Jistě je šifrování fajn, ale má to smysl nasadit na domácím notebooku zcela laického uživatele?
Hmm když už zmiňujete TPM a šifrování pro laiky - asi se bavíme o Bitlockeru? Tam je to myslím pořešeno docela OK, nejen že vás nenechá disk zašifrovat bez uložení recovery klíče někam externě (flashka), ale ještě máte možnost si klíč zazálohovat třeba do live účtu....nebo staromódně vytisknout a dát na nástěnku :-)
Takže pro lidi co zapomínají notebooky v autech ideální :) pro domácího s desktopem to je ale asi overkill.
U SSD disků asi ano, tam je to "všechno nebo nic".
Ale notebooky s plotnovými disky dostávám dost často do ruky se stížností "je to nějak pomalý", výjimečně až ve stavu "nejde spustit".
Stav "je to nějak pomalý" lze obvykle zachránit pomocí ddrescue a je jen otázka, kolik těch sektorů je vadných, jak moc a co v nich je. Tady to šifrování může, ale nemusí přečkat, resp. znemožnit záchranu dat.
Stav "nejde spustit" je často řešitelný aspoň natolik, že se většina dat přečte. Ale se šifrováním je vymalováno.
Jistě, že by si každý měl zálohovat - ale transparentně (do cloudu) to chce dost velký prostor v cloudu (=peníze), nebo pravidelně nějaký úkon (=kázeň). Cloud je navíc pro paranoiky problém, že data má někdo cizí.
Řeč je o lidi oborem IT téměř nepolíbené.
Ještě dodatek: tohle je už poněkud off-topic. Původně mi šlo o to, že perfektní zabezpečení je do jisté míry v protikladu ke snadnému používání. Jde o to, aby se do vašich dat nedostal každý hej-počkej, ale když o vás bude mít zájem někdo opravdu vlivný, tak každé zabezpečení skončí v okamžiku, kdy se jim dostanete do rukou (gumová hadice je mocný dešifrovací nástroj).
Jestli chcete dělat konspiraci, tak musíte počítat s tím, že i ten bezpečný kanál nemusí být bezpečný.
Pokud správně chápu článek, tak toto se udělat nedá. Server nevnucuje nový privátní klíč aplikaci. Server vnucuje nový veřejný klíč protistraně. Ve chvíli, kdy uživatel aplikace nezkontroluje, že takový klíč je opravdu věrohodný, může server podstrčit veřejný klíč, k němuž ale privátní klíč vlastní server sám.
Modelový příklad komunikace Boba a Alice, se třemi páry klíčů PKb1 + VKb1, PKb2 + VKb2, a PKa1 + VKa1 (P/V za privátní/veřejný, b/a za Boba/Alici (strana, která by podle něj měla šifrovat), 1/2 za různé klíče)
Alice Bobovi:
- Alice vlastní Bobův ověřený veřejný klíč VKb1.
- Alice šifruje zprávu pomocí VKb1 a posílá Serveru (pro Boba).
- Server si vygeneruje nový pár PKb2 a VKb2.
- Server předstírá, že Bob změnil své klíče a chce od Alice nově zašifrovat zprávu pomocí VKb2.
- Alice neobdrží žádné upozornění o změně páru. Její zařízení odesílá nově zašifrovanou zprávu pomocí VKb2.
- Server si nyní čte Alicinu zprávu, kterou dešifruje pomocí PKb2.
- Server posílá Bobovi původní zprávu (tu zašifrovanou pomocí VKb1).
- Bob dostává zprávu a dešifruje ji pomocí svého PKb1 a tedy nic netuší.
- Alice též nic netuší, protože její aplikace jí neřekla nic o záměně klíčů.
Takto server nemůže komunikaci modifikovat, ale může ji číst.
Následná odpověď Boba Alici:
Pokud zpráva není podepsaná Bobovým klíčem, Alice opět nic nezjistí. Pokud se zprávy podepisují (asi by se měly podepisovat), mohlo by Alici být podezřelé, že dostává zprávu zašivrovanou pomocí VKa1 a podepsanou pomoci PKb1, když bob dle serveru začal používat nový klíč PKb2. Jenže server může jednoduše předstírat, že Bob opět používá staré zařízení. Ve výsledku stačí 4 páry klíčů a ani jedné ze stran není nic podezřelé. Aplikacím se to jednoduše jeví jako když protistrana střídavě používá dvě různá zařízení.
Domnívám se, že titulek je zavádějící. Není pochyb o tom, že WhatsApp skutečně šifruje end-to-end. Že je možné vyměnit klíče je taky spíše bezpečnostní výhoda. Jedinou chybu tedy vidím v tom, že výchozí součástí komunikace by měla být přinejmenším nerušivá notifikace, že došlo ke změně klíčů.
Zarazilo mě tohle:
Server totiž může klientům nařídit, aby zatím nedoručené zprávy znovu zašifrovaly jiným klíčem a poslaly mu je. Příjemce se o této změně navíc vůbec nedozví a odesílatel jen v případě, že v nastavení výslovně zapne zobrazování varování týkajících se šifrování.
Jak se o tom může příjemce nedozvědět? Šifrovací klíč znají jen oba konce komunikace. Tedy pokud má být odposloucháváno, musí dojít ke změně klíčů na obou stranách.
Ještě je tu ta zásadní výhoda, že provozovatel nejspíše neví, které klíče byly klientem ověřeny a které ne. Útočník si tedy nemůže dovolit odposlouchávat plošně, protože dřív nebo později narazí na někoho, kdo ověření prodělal a na odposlech přijde. Když pak takový případ medializuje, služba okamžitě ztratí důvěru, případně více lidí se naučí ověřovat své známé.
Souhlasím, že titulek je zbytečně bulvární, stejně tak i zbytek článku si mele svou o bezpečnostní díře, bez potřeby vyrovnat se s faktem (je zmíněný i v reakci OWS), že by se naprostá většina uživatelů Whatsapp při zobrazení této notifikace nebyla schopná kvalifikovaně rozhodnout, co s tím.
Tím, že se o tom klient nedozví je myšlen klient ve smyslu uživatele. Klientská aplikace se o tom dozví, jde jenom o to, jestli o tom informuje uživatele.
Hlavně WhatsApp by default ukládá historii chatu k nim na server a ta není šifrovaná na straně klienta. Aby měl člověk jistotu, že se k obsahu jeho chatu WhatsApp nedostane, musel by zajistit, aby nikdo z jeho kontaktů toto ukládání neměl zapnuté, což je prakticky nemožné. WhatsApp tedy může šifrovat end-to-end, ale výchozím nastavením (jak tím ukládáním historie, tak tím vyměněním klíčů bez toho, aniž by to uživatel věděl) je natolik oslabeno, že IMHO postrádá smysl.
Já WhatsApp nepoužívám, takže z vlastní zkušenosti mluvit nemůžu, ale když jsem nastavoval WhatsApp na novém telefonu mojí máti, tak to automaticky obnovilo celou historii chatů a to si nikdy Google Drive nenastavovala nebo nepoužívala. Možná to umí nějak využít credentials k účtu Googlu, který už je v Androidu nastavený, a uživatele od nastavování zcela odstínit.
Nicméně i kdyby k tomu používali Google Drive, podstata zůstává stejná: obsah chatů, který by se neměl díky end-to-end šifrování dostat do rukou nikomu jinému než vám a protistraně, je uložená na serveru někoho jiného a očividně nezašifrovaná klíčem, ke kterému máte přístup jenom vy. Na úplně novém klientovi to dokázalo obnovit zálohu, aniž by to vyžadovalo přenos nějakého klíče ze starého.
Tady je srovnani WA vs Allo od Googlu vs Signal +co se kam skladuje https://theintercept.com/2016/06/22/battle-of-the-secure-messaging-apps-how-signal-beats-whatsapp/
"Že je možné vyměnit klíče je taky spíše bezpečnostní výhoda"
Muzu se zeptat odkdy je vyhoda ze server muze vymenit klice aniz by si toho vetsina useru vsimla jelikoz upozornovani na zmenu klicu je defaultne vypnuto??......a vy urcite znate to rceni "the slavery of default".....??
Signal tohle resi blokovanim dokud nedojde k znovu-verifikaci obou koncu, coz je presne to co by clovek od neprustrelneho crypto-messengeru cekal, a lidi od Whatsapp dobre vedi o cem je rec viz. "when a contact's key changes, should WhatsApp require the user to manually verify the new key before continuing....?"
Zrovna tak ty jejich zvasty o uniku metadat "The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM..."
Co soudruhum od Fejsbagu brani aby plosne vynucovali notifikaci zmeny klicu u VSECH ZARIZENI??
Kazdy user by se pak dozvedel ze se "s klicema neco stalo" a server soudruhu z FB by se dozvedel akorat ze nemuze zkouset ojebavat nikoho aniz by riskoval ze se na to prijde.
Kdyz uz se soudruzi tak zarikavaj jak jim strasne jde o privacy usera.....
Taktez obhajovat dodani odeslane zpravy za cenu jejiho "presifrovani" za zady klienta povazuju za naivni blabol v lepsim pripade, v tom horsim za zly umysl.
Co jim brani uskladnit zpravu lokalne a pushnout ji 2hymu konci az po overeni novych klicu?? Skladovani zprav na lokalu dokud nebude protistrana online delaly uz prvni verze Skypu nekdy pred 10ti lety.
A proc by vlastne musel probenout re-keying?
Proc by si nemoh' user zazalohovat svuj par klicu +dejme tomu i seznam kontaktu lokalne na nejakou flasku ci druhej komp?
Takhle to holt dopada kdyz se dobreho protokolu chytnou spatni lide.....
Mimochodem trochu to pripomina Apple=ten ma taky plnou hubu end2end sifrovani jenze skladovani a distribuci klicu pro iMessage zajistuji vyhradne servery Applu. Proto si taky sef FBI James Commey jeste nedavno tak liboval jak se s Applem vyborne spolupracuje kdyz potrebujou vylovit nejake zpravy a proto nechape proc se najednou Apple stavi na zadni a nechce jim pomoct cracknout to sifrovani v iPhonu (San Bernardino shooter case)
Muzu se zeptat odkdy je vyhoda ze server muze vymenit klice aniz by si toho vetsina useru vsimla jelikoz upozornovani na zmenu klicu je defaultne vypnuto??
Nevytrhávejte z kontextu. To, že upozornění na překlíčování by mělo být vidět jsem zmínil hned v následující větě. Možnost výměny klíče je rozhodně lepší, než pokud by byl klíč zabetonovaný navždy (například v SSH; byť tam jde často o jiný účel). Pak by stačilo ukrást mobil a následně rozšifrovávat veškerou budoucí komunikaci.
Co jim brani uskladnit zpravu lokalne a pushnout ji 2hymu konci az po overeni novych klicu?? Skladovani zprav na lokalu dokud nebude protistrana online delaly uz prvni verze Skypu nekdy pred 10ti lety.
Vždyť to přesně tak je. Jen s tím rozdílem, že tu není odsouhlasování od uživatele, protože se předpokládá, že uživatel souhlasí. Což je zcela opodstatněné s přihlédnutím k cílové skupině uživatelů (opět analogie s SSH: už jste někdy na dotaz o autenticitě serveru odpověděli jinak než „ano“?) Bdělý uživatel tedy v nejhorším případě vyzradí jedinou zprávu, následně zpozorní při notifikaci o změně klíčů a provede nové ověření protistrany.
@Ondrej Caletka
"Možnost výměny klíče je rozhodně lepší, než pokud by byl klíč zabetonovaný navždy (například v SSH; byť tam jde často o jiný účel). Pak by stačilo ukrást mobil a následně rozšifrovávat veškerou budoucí komunikaci."
Ja bych to tak jednoznacne nevidel=pokud prijdu o mobil, je tam klic "zabetonovany navzdy"tak jako tak.Coz je sice vopruz na 2hou stranu to ma tu vyhodu ze me to DONUTI VYGENEROVAT NOVY PAR KLICU+PROVEST AUTENTIZACI S MYMI KONTAKTY ZNOVU=PROTOZE PROSTE VIM ZE DOSLO KE ZMENE a taky nechci aby posilali zpravy na "starej klic"
Neriskuji tedy ze to za mymi zady bude delat server s pochybnym vysledkem/umyslem.
Jiny scenar je kdyz si potrebuju "zachovat identitu"+prenest ji=napr. si poridim novejsi mobil, upgrade firmwaru apod. Pak je vyhodne pouze nahrat puvodni klice a vyhnout se tak nutnosti autentizovat 50 starych kontaktu znovu.
"Co jim brani uskladnit zpravu lokalne a pushnout ji 2hymu konci az po overeni novych klicu??....
.......Vždyť to přesně tak je."
NE-tak to presne NENI. Aspon ne v pripade WA. Chovani ktere popisujete je chovani Signalu.
U WA pokud potencialni prijemce zpravy provede re-keying a zacne tim padem provozovat novy par klicu, zatimco ve fronte cekaji pro nej zpravy zasifrovane jeho puvodnim STARYM VEREJNYM KLICEM, server to zjisti a vyzve odesilatele k zasifrovani starych zprav prijemcovo NOVYM KLICEM KTERY MU PODSTRCI-a to je ten problem! Pokud totiz prijemce NEPROVEDE AUTENTIZACI=ZTOTOZNENI PRIJEMCE S TIMTO NOVYM KLICEM,NEMUZE SI BYT NIKDY JIST ZE TENTO VEREJNY KLIC SKUTECNE POCHAZI OD DEKLAROVANEHO PRIJEMCE A TUDIZ JE NEBEZPECNE JAKEKOLIV ZPRAVY ZNOVU POSILAT! Proste dokud neprobehne nova vzajemna autentizace obou koncu nelze vubec mluvit o end2end bezpecne komunikaci=presto nejede vlak a soudruzi od WA to muzou okecavat jak chtej.
Navic tim ze uzivatele nejsou defaultne na nic upozornovani +bavime se o uzivatelich ala FB (ktere jste charakterizoval sam presne viz."..že tu není odsouhlasování od uživatele, protože se předpokládá, že uživatel souhlasí. Což je zcela opodstatněné s přihlédnutím k cílové skupině uživatelů " :-)
tim si tato konstrukce koleduje o to ze se stane cilem najezdu hackeru, policajtu FBI a podobnych spolku....
"Bdělý uživatel tedy v nejhorším případě vyzradí jedinou zprávu, následně zpozorní při notifikaci o změně klíčů a provede nové ověření protistrany"
Opet mluvite o Signalu, WA zadne bdele uzivatele nema, a pokud si tech 5 chytrejsich nekde precetlo ze je dobry mit aktivovany notifikace a zaplo sito tak to tu miliardu dalsich BFU co nic netusej nezachrani.
"už jste někdy na dotaz o autenticitě serveru odpověděli jinak než „ano"?"
Pokud by se mi server prokazal klicem kde fingerprint nesedi s tim co ocekavam pak bych ho poslal do (_!_) protoze je jasny ze se nebavim se serverem ale s nakym chytrakem po ceste.
BTW aby to nebylo tak jednoduchy tak pri generovani klicu se vyrabi udajne rovnou 100 paru "pro pripad potreby" jak probiha jejich sprava je (aspon pro me) ponekud nejasny. Na mobilu uzivatele predpokladam nelezi protoze pri ztrate mobilu by to jaksi pozbyvalo smyslu, cili lezi pravdepodobne na serveru DOUFEJME ze jako zasifrovanej kontejner (jinak je to security masakr :-))) a otazka je jak snadno se k obsahu da dostat.
Pokud při ztrátě mobilu jednoduše vygenerujete nový pár klíčů, pak zcela evidentně nejde o jeden klíč zabetonovaný navždy, ale o systém, který umožňuje výměnu klíčů. Což je přesně systém, který používá WhatsApp a Signal – vyzkoušel jsem obě aplikace a chovají se prakticky totožně. Obě je možné používat velmi bezpečně, Signal bezpečnost více vynucuje a to je možná důvod, proč na něm nejsou žádní lidé. Jedinou opravdovou slabinou je, že WhatsApp vyzradí potenciálnímu útočníkovi jednu zprávu v okamžiku, aniž by mohl odesílatel ovlivnit, jestli ji chce odeslat. I tak to ale bdělý uživatel ihned detekuje.
Ani se Signalem nejste v bezpečí. Lidé si po něm píšou většinou v případech, kdy nejsou ve fyzické blízkosti, takže si klíče ověřit nemohou. Pokud se klíč změní, můžete změnu přijmout nebo odmítnout, nemáte žádnou šanci zkontrolovat, jestli je ten nový klíč správný, dokud ho neodsouhlasíte.
Koho šifrování zajímá, ten si notifikace zapne. Třeba já je měl zapnuté vždy, dokonce jsem se až do vydání článku domníval, že jde o výchozí chování. Když mi WhatsApp napíše, že došlo k výměně klíčů, zpozorním, zeptám se na příčinu protistrany a naplánuju nové ověření. Po tomto článku jsem dokonce pár svých známých navštívil osobně a provedl ověření klíčů, což je docela zábava. Velká škoda je, že si ani klient nepamatuje, které klíče už byly ověřeny a které ne.
Nemusí to tak dělat všichni a ani určitě nebudou. Spousta lidí bezpečnost neřeší a nepotřebuje. I pro ně je ale E2E šifrování bezpečnější, než kdyby tam nebylo. Ale samotný fakt, že tam možnost autentizace protistrany je, z toho dělá velmi bezpečný komunikátor. Pokud je navíc pravda, že servery nevědí, kdo má notifikace zapnuté a kdo ověřil klíče, jsou chráněni i uživatelé s laxním přístupem k bezpečnosti.
Pro srovnání: Telegram, který tvrdí, že podporuje E2E šifrované privátní chaty, nenabízí vůbec žádnou možnost autentizace. Hangouts ani nenabízí E2E šifrování. Signal je jistě bezpečnější, ale zase na něm nejsou žádní lidé ;)
Pokud by se mi server prokazal klicem kde fingerprint nesedi s tim co ocekavam pak bych ho poslal do (_!_) protoze je jasny ze se nebavim se serverem ale s nakym chytrakem po ceste.
Spravoval jsem pár serverů, kam lezli i jiní uživatelé, a vždycky když jsem změnil SSH klíče, počítal jsem, kolik z nich se ozve s žádostí o ověření pravosti klíče. Ani jeden. Takže asi tak.
"Signal bezpečnost více vynucuje a to je možná důvod, proč na něm nejsou žádní lidé."
Ne-duvodem je ze WA patri pod FB ktery ma urcite marketingove paky.
Signal je gratis opensource ktery zadnou megavelkou socialni sit neprovozuje, takze se o nem vetsina beznych BFU nikdy nedozvi.
"Jedinou opravdovou slabinou je, že WhatsApp vyzradí potenciálnímu útočníkovi jednu zprávu v okamžiku, aniž by mohl odesílatel ovlivnit, jestli ji chce odeslat. I tak to ale bdělý uživatel ihned detekuje."
Ne-opravdovou slabinou je ze uzivatel WA vubec nikdy nezjisti ze se do jeho komunikace vlozil MitM, pokud necha vse tak jak je to nastaveno v defaultu. Vzhledem k tomu ze cilova skupina pro WA jsou uzivatele FB (se vsim co k tomu patri) je naprosto naivni se domnivat ze tito BFU se z vlastni iniciativy budou prehrabovat v nastaveni a zvysovat si ho na vyssi security.
" I tak to ale bdělý uživatel ihned detekuje."
Myslim ze pocet "bdelych uzivatelu" by se v teto cilovce dal spocitat na prstech 1 ruky.
"Ani se Signalem nejste v bezpečí. Lidé si po něm píšou většinou v případech, kdy nejsou ve fyzické blízkosti, takže si klíče ověřit nemohou."
Fyzicka blizkost neni samozrejme potreba- to je naprosty blabol. Kdyby to tak bylo vetsina Americanu by ten soft vubec nemohla pouzivat protoze vzdalenosti v USA jsou obrovske.
Autentizaci je mozne provest vice zpusoby-viz tady je demo (@2h11m12s)
https://twit.tv/shows/security-now/episodes/555
Je dobry to skouknout cely od cca 1h48m kdy Gibson pomerne podrobne probira Signal protokol a jeho pouziti ve WA -je zajimavy ze video je z dubna 2016 a uz tenkrat se chytal za hlavu proc jsou notifikace defaultne vypnute+probira tam jake z toho plynou dusledky pro bezpecnost celeho systemu ;o)
Zaroven tam vysvetluje k cemu slouzi onech 100 jednorazovych paru klicu cosi kazdej uzivatel vygeneruje kdyz se zahlasi do systemu....... je to celkem genialni.
"Spousta lidí bezpečnost neřeší a nepotřebuje"
To ze spousta lidi bezpecnost neresi je bohuzel pravda-muze to byt ale take tim ze nevedi jak, nee kazdy je dostatecne technicky zdatny. To ale neznamena ze nema narok na ochranu soukromi (notabene mu pravo na soukromi priznava i Ustava) a na bezpecnost sve privatni komunikace. A tu by mu prave meli zajistit ti kdoz jsou technicky zdatnejsi = napr WA. Obzvlast kdyz do sveta vytrubujou jak jim desne jde o privacy uzivatele.....
To, ze by lidi "nepotrebovali" bezpecnost je nesmysl- Snowden kdysi na obdobny argument (trefne) odpovedel:
je to jako rict ze lidi nepotrebujou freedom of speech protoze momentalne nemaji co rict.
Je potreba si uvedomit ze prava ktera maji plosne lidi dneska, zdaleka nemeli vzdycky a trvalo mnoho let a potoky krve nez se k onem soucasnym pravum probojovali viz. zrovnopravneni lidi ruzne barvy pleti aka odstraneni otrokarstvi, zrovnopravneni zen aka priznani hlasovaciho prava, odstraneni monarchie aka obecne zrovnopravneni lidi aka zavedeni demokracie atd.
Je velmi snadne se zrici svych prav/prijit o ne ale je velmi tezke je pozdeji ziskat zpet.
Urcite se shodnem' na tom ze v dnesnim svete je tendence opacna = zvolna orezavat zakladni lidska prava hezky salamovou metodou samozrejme "pro vase dobro a vase bezpeci" viz "kdo nic spatneho nedela nema prece co skryvat"
"Pokud je navíc pravda, že servery nevědí, kdo má notifikace zapnuté a kdo ověřil klíče, jsou chráněni i uživatelé s laxním přístupem k bezpečnosti."
To teda opravdu netusim jak?? Tohle je FBI a podobnym spolkum uplne u (_!_)
Ti kdyz potrebuji dosahnout sveho cile tak je jim osud dotcene firmy naprosto sumak- viz Lavabit anebo posledni utok na Apple. Pokud budou citit ze se tak snadneji dostanou ke svemu cili, klidne provedou "kobercovy nalet" a jestli se na to pak prijde anebo to odradi uzivatele sluzby vubec resit nebudou......
"Telegram, který tvrdí, že podporuje E2E šifrované privátní chaty, nenabízí vůbec žádnou možnost autentizace. Hangouts ani nenabízí E2E šifrování."
O duvod vic Telegram nepouzivat.
Hangouts je Google- tam snad ani nikdo nic neocekava ne?
"Spravoval jsem pár serverů, kam lezli i jiní uživatelé, a vždycky když jsem změnil SSH klíče, počítal jsem, kolik z nich se ozve s žádostí o ověření pravosti klíče. Ani jeden. Takže asi tak."
Tak to je tristni. Tak to u tech serveru muze sedet sousedovic Zofka.
Za co tedy ty admini dostavaj zold mi neni jasny.
(nebyly to nakonec servery emericke DNC?? to by totiz ledacos vysvetlovalo :o))))))))
"...nerušivá notifikace, že došlo ke změně klíčů."
Coze, nerusiva notifikace? Pokud je notifikace zadna nebo nerusiva, je to to same, jako kdyz by bylo pouzito client-server sifrovani, ne end-to-end. Nemoznost potichu vymenit klice za jine je prave to, co zajistuje end-to-end bezpecnost! Jedine spravne chovani je viditelne indikovat ze konverzace neni zabezpecena, dokud nedojde k overeni klicu bezpecnym kanalem. To bude i BFU jasne a klice overi, pokud mu o to pujde.
Rušivá notifikace stylu Signal: „Došlo k výměně klíče, chcete se dál bavit? Ano/Ne“ má naprosto stejný účinek, jako nerušivá notifikace WhatsApp „Došlo ke změně klíče, podrobnosti zobrazíte klepnutím“
Přirovnávat to k Hop-by-Hop zabezpečení je hodně velká zkratka, když v případě hop-by-hop může provozovatel služby číst všechno pořád a v tomto případě tak smí činit pouze od výměny klíče do ověření totožnosti, o kterém neví, kdy a zda k němu dojde. Pokud to bude dělat, dřív nebo později se vyzradí, služba okamžitě ztratí důvěru a uživatelé se přesunou ke konkurenci. To mu za to rozhodně nestojí.
Kdo ověřovat nechce, nebude to dělat, ani když po něm budete chtít napsat verzálkami ANO při stoji na jedné noze, kdo ověřovat chce, tomu stačí jednoduché upozornění, že se klíče změnily a je třeba ověřit znovu.
"Rušivá notifikace stylu Signal: „Došlo k výměně klíče, chcete se dál bavit? Ano/Ne“ má naprosto stejný účinek, jako nerušivá notifikace WhatsApp „Došlo ke změně klíče, podrobnosti zobrazíte klepnutím“"
Nechapu proc neustale vychazite z (falesne) premisy ze uzivatele WA budou nejakym zpusobem upozorneni...........celej ten clanek/problem se toci kolem toho ze "lze vynutit znovu-vygenerovani klicu aniz by si toho uzivatele vsimli"
A kdyz uz resime jakou hlasku by bylo optimalni userum naservirovat co treba:
"vase protistrana zmenila identitu-dalsi pokracovani ve vasi vzajemne konverzaci neni bezpecne a muze byt odposlechnuto nekym dalsim-chcete provest novou autentizaci protistrany?"
A zadratovat to do klienta v defaultu- myslim ze tohle by nadzvedlo uz o dost vic BFU......
Nicmene naraazime tady na zname pravdy ze "making a bullet-proof crypto ain't easy" a "convenience is the enemy of security"
Cili jak udelat spolehlive crypto pro siroke masy ktere nechapou ani zakladni pojmy?
Castecne se o tom zminuje i tvurce Signal protokolu
http://arstechnica.co.uk/security/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/
Osobne si myslim ze pokud clovek slibuje "bezpecne spojeni" (a uzivatel na to spoleha) tak to "obcas bude trochu bolet" =jestlize protistrana zacne kouzlit s klicema tak proste narazi a bude se muset znovu verifikovat, coz se da snadno zaridit budto hlasem anebo potvrzenim QR kodu pres kameru kde i user vidit kdo mu ten QR kod vnucuje. OPRAVDU 100%ni overeni protistrany pri asymetricke crypto zrejme nikdy nebude vylozene pohodlne/na 1 klik. Samozrejme ze CA a podobne nesmysly nepripadaji v uvahu ani vystaveni verejneho klice nekam na key-server taky nic nezarucuje.
Je to holt jako ockovani u doktora-neni to prijemne ale vime ze je to nutne :-)
"it's better be safe than sorry"
PS: kod Signalu auditoval Matthew Green=ten samej typek co auditoval TrueCrypt viz.https://www.wired.com/2016/07/meet-moxie-marlinspike-anarchist-bringing-encryption-us/
Threema není opensource, takže je úplně stejně nedůvěryhodná jako WhatsApp (upřímně i tomu WhatsAppu bych důvěřoval více, protože alespoň používá Signal protokol, který je objektivně lepší - nicméně ve výsledku to je stejně jedno, do proprietární aplikace může kdykoliv někdo umístit backdoor).
Pokud nechcete sdělovat telefonní číslo, pak je nejlepší možností Wire (nevyžaduje tel. číslo, taktéž používá Signal protokol a je opensource).
"Kromě toho aplikace během aktivace posílá phonebook uživale na servery signálu."
seznam kontaktu potrebuje mozna proto aby k nim moh priradit prislusny verejny klic kterym zahaji sifrovani.... Navic komu ktere cislo volalo a kdy+jak dlouho jsou info ktery La Policia bez problemu dostane od telco, takze s tim moc tajnosti nenadelas....
Tady je clanek o tom jaky data od Signalu nedavno dostali frajeri z FBI kdyz nakraceli s prikazem od soudu.
http://thehackernews.com/2016/10/signal-messenger-fbi-subpoena.html
http://www.dailydot.com/layer8/signal-subpoena-privacy-gag-order