Rozšíření End-to-End pro Chrome

Google na svém blogu věnovaném počítačové bezpečnosti představil rozšíření pro Chrome s názvem End-to-End. Jedná se o rozšíření, pomocí kterého lze v prohlížeči Chrome dle OpenPGP standardu šifrovat a dešifrovat zprávy, digitálně je podepisovat a samozřejmě také ověřovat jejich podpisy. Rozšíření je v alfa verzi a zatím není dostupné v Internetovém obchodě Chrome. Zdrojové kódy rozšíření jsou k dispozici pod licencí Apache. [Slashdot]

4.6.2014 03:00 | Ladislav Hagara | Zajímavý software

Komentáře

[xxxxxxxxxxx]

At si s Chrome vytřou zadek kolaboranti nSSa!!!

[xm]

Začínáš znít jako člověk, kterého by měli každou chvíli odvézt ve svěrací kazajce do Bohnic. Nechceš se na to vykašlat a raději se věnovat opensource CADu?

[Bedňa]

Mno keď chceš informácie o spolupráci tak si ich nájdeš.

To že je Chromium otvorené ešte neznamená že tam zmrdíci nezamontovali nejaký StackOverflow. To je akoby si čakal že zlodej bude niekedy jednať čestne.

Bohužiaľ najlepšie nástroje na foréznu analýzu sú uzavreté a nepoznám žiadny slobodný funkčný. Jedine odstrániť všetky upozornenia s kompilátora a najať si partiu programátorov :)

[g.g]

Jsem si téměř jist, že Stack Overflow se do instalačky Chrome nevejde; ten web se za ty roky pořádně rozrostl.

[Bedňa]

Som si istý že je už v základnej výbave

[marek_hb]

trolluješ, zbláznil ses, nebo se jen nedaří v práci/vztahu???

[Nikola Ciprich]

v jakém vztahu?

[marek_hb]

no - dobrej dotaz ... - myslel jsem se ženskou, ale vůbec jsem si neuvědomil, na jakém webu to píšu ... - tady je tolik možností .... :)

[P.T.]

Doufám, že nechcete zamlčovat nebo dokonce napadat jiné druhy vztahů.

[marek_hb]

to ani smykem, jen jsem rád za svoji heterosexuální úchylku - i ta mi sama o sobě dost komplikuje život :)

[Jura]

Proč do technické diskuse taháte osobní invektivy ? To spíš vypadá, že Vy neumíte vést technickou diskusi.

S pozdravem

Jura

[anonym]

Bubububu, rychle si všichni smažte ten satanský google a nainstalujte hodný MSIE nebo Safari než u vás zazvoní agenti NSA.

[R]

A ktory z nich je pre Linux?

[JirkaH]

oba tri

[R]

V uzavretom prehliadaci od tejto firmy to fakt ma zmysel...

[xm]

Zapomínáte, že zdrojové kódy Chrome jsou opensource v podobě projektu Chromium (který na Linuxu spokojeně používám). Samotné binární Chrome je samozřejmě nesmysl na Linuxu instalovat...

[Conscript89]

Az na to, ze jde o stejne zdrojove kody neni nikdo schopen overit, leda tak zamestnanci googlu (a par zasvecenych).

[kralyk z abclinuxu]

U Chromia, který si distribuce kompilují ze zdrojáků, přece tenhle problém není...

[little.owl]

U OpenSSL byly take kody k dispozici .... a nakonec ten bug objevili nahodou nejakou heuristikou.

[kralyk z abclinuxu]

Ale tak jistě, nechtěl jsem říct, že opensource zaručuje bezpečnost - viz na co jsem reagoval...

[xm]

Jak není nikdo schopen ověřit? Koukal jste na ty zdrojové kódy? Chromium je má velmi přehledné, oproti Firefoxu je to ještě zlaté.

[xm]

(podotýkám celou dobu je řeč o Chromiu - používat pod Linuxem binární Chrome je nesmysl)

[David Jaša]

U některých distribucí to tak jasné není - Chromium není v repu a jsou jen nepodepsané buildy, zatímco gůgl dělá podepsané buildy chrome ve vlastním repu.

[Pali]

A aky je rozdiel medzi buildami nepodpisanymi a buildami podpisanymi googlom? Myslim ze obom sa da verit rovnako...

[little.owl]

U Googlu prochazeji exploity dukladnym QA.

[Bedňa]

http://www.abclinuxu.cz/zpravicky/rozsireni-end-to-end-pro-chrome/diskuse#23

[Conscript89]

Zapomínáte, že zdrojové kódy Chrome jsou opensource v podobě projektu Chromium

(podotýkám celou dobu je řeč o Chromiu - používat pod Linuxem binární Chrome je nesmysl)

Reagoval jsem na prvni tvrzeni, to druhe je nepravdive :)

[Vantomas]

Už asi zprovoznili ty jejich kvantové počítače a tak si můžou dovolit tlačit šifrování mezi lidi

[696]

"pomocí kterého lze v prohlížeči Chrome dle OpenPGP standardu šifrovat a dešifrovat zprávy"

Uživatel zašifruje a Google dešifruje už na počítači uživatele s využitím výpočetního výkonu počítače uživatele.

[PanZvedavy]

+1

[R]

Netreba ziadny vypoctovy vykon, prehliadac sa dostane priamo k nesifrovanym datam... A uzivatel este tymto pokusom o bezpecnost oznaci zaujimave data.

[Alfonz Mucha]

Ao je to tak - je to normalny-prahobycajny marker zaujimavych dat...

[Zdenda]

Chrome 35 je úplně na nic a na h.vno! Kterou hlavu napadlo skončit s podporou Java pluginu?

[mca]

Managorskou? Jak jinak Te maji donutit jedinemu spravnemu reseni = jejich sluzby? Cloud VPS, Cloud iKVM? NSA backup? Kbyby tam ta Java zustala, tak bys mohl ovladat treba takove IPMI Supermicro a nekoupil bys jejich variantu.

[Petr "Glubo" Sýkora]

Tak vzhledem k tomu, jak je Java děravá, tak je to vcelku dobrý krok kupředu.

[Bedňa]

Java sa dá skonvertovať do JavaScriptu. Tieto opatrenia čakajú všetky prehliadače, rovnako ako časom odzvoní doplnokom (addons).

Je to bezpečnostné opatrenie, pretože je menej náchylné na chyby udržovať HTML5 a JavaScript ako množstvo všelijakých splátanín okolo. HTML5 s JS dokáže dnes už všetko čo Flash, Java, doplnky, takže odpadla nutnosť niečo také udržiavať.

Pomocou asm.js a emscripten dokáže spraviť aj celkom svižný port desktopovách aplikácií. Unreal Engine 4 je už tiež naportovaný.

Môžeš si testnúť aj niektorú z hier.

[little.owl]

. HTML5 s JS dokáže dnes už všetko čo Flash, Java

Byt javu a flash nerad, mam o tom urcite pochybnosti.
Kazdopadne obe technologies nejsou podporovane na mobilnich platformach => na webu jsou mrtve.

[Bedňa]

• Local storage
• Interaktivita so serverom cez XHR2
• Prenášanie súborov, FileReader, XHR2, saveAs
• Beh na pozadí - WebWorkers
• Prehrávanie médií
• Komunikácia v reálnom čase WebRTC
• Websocket
• Canvas
• Skriptovanie
• Konverzia z najznámejších jazykov Java, Python, C, C++ ...
• Framebuffer

Momentálne ma nenapadá čo by sa nedalo spraviť. Druhá vec je kvalita prevedenia. Svojská implementácia, takže buď si programátor zvykne na iný spôsob zápisu a logiky, alebo siahne po nejakom like C frameworku.

[Filip Jirsák]

Stále nejde v prohlížeči něco elektronicky podepsat privátním klíčem uloženém na čipové kartě nebo v systémovém úložišti (resp. kdekoli jinde, než v souboru na disku).

[Bedňa]

Aj to ide, len nie tak jednoducho ako v desktopovej aplikácií, proste si ten kľúč musíš vyhľadať na USBéčku. Viem si predstaviť aplikáciu ktorá by ho automaticky skopčila do local storage a možno už také niečo aj existuje, ale nepátral som po tom.

[Jendа]

Aj to ide, len nie tak jednoducho ako v desktopovej aplikácií, proste si ten kľúč musíš vyhľadať na USBéčku.

Počkat, jako že už je v JS nějaké obecné USB API, nebo je tam nějaké API pro asymetrickou kryptografii? Nebo jak „vyhľadať kľúč na USBéčku“? Pod tím si představím, že si javascript pustí něco jako lsusb.

[Bedňa]

Sorry, to som práve išiel spať, táto odpoveď je na úplne inú otázku, ktorú tu ale nikto nepoložil.

To fakt nieje možné. Celkovo kryptografia v prehliadačoch je v alfa verzií (zrovna s tým bojujem), ale niečo sa dá dozvedieť napríklad tu.

[petr_p]

Existuje Webcrypt. Je to lokální HTTP server, který má přístup ke kryptografickému materiálu nebo modulům a umí všechny potřebné věci (generovat klíče, podepisovat, šifrovat). Webová aplikace z cizího serveru mu předává data přes přesměrování v HTTP. Jedni tvrdí, že je to budoucnost, druzí, že je to webová pitomost.

[Filip Jirsák]

Možností, jak něco takového implementovat "přímo v prohlížeči", je spousta. Mne ale zajímal současný stav, tj. něco, co jde dnes nasadit na web a bude to fungovat většině uživatelů.

[petr_p]

Dnešní stav je, že uživatele bezpečnost ani soukromí nezajímá, proto neexistuje nic, co „bude fungovat většině uživatelů“. A obávám, se že na předpokladu se nic nezmění. Takže jediným tahounem bude fragmentovaná národní státní správa se vším, co k tomu patří. Tomu bude odpovídat i výsledek a rychlost konvergence k jednotnému standardizovanému a přenositelnému řešení.

[Filip Jirsák]

Pro ten elektronický podpis něco, co bude fungovat většině uživatelů, existuje - právě Java. I když Oracle dělá hodně pro to, aby to platit přestalo, a teď se přidává i Google a Mozilla.

Že nezajímá bezpečnost a soukromí uživatele, to se ještě dá pochopit. Jenže oni na to z vysoka kašlou především vývojáři webových prohlížečů, a to je mnohem horší. Respektive oni "bezpečnost" používají jako marketingovou vějičku, v zájmu "bezpečnosti" vymýšlejí nesmysly, a věci, které by bezpečnost opravdu zlepšili, důsledně ignorují.

[petr_p]

A podařilo se vám donutit security.provider, aby aplikace automaticky používaly PKCS#11 modul? Já jsem taky čekal, že to bude samo fungovat, ale buďto to nedělalo nic, nebo segfaultovalo.

[Filip Jirsák]

Myslíte z Java pluginu použít privátní klíč zpřístupněný přes PKCS#11 modul prohlížeče? To jsem nezkoušel, ale nenapadá mne důvod, proč by měl mít uživatel certifikát pro elektronický podpis dostupný v prohlížeči, kde ho stejně nijak nevyužije. A pokud uživatel dostane certifikát do PKCS#11 modulu v prohlížeči, má ho snad dostupný i v OS – tedy ve Windows a na MacOS, pod Linuxem vlastně systémové úložiště certifikátů neexistuje…

[David Jaša]

pod Linuxem vlastně systémové úložiště certifikátů neexistuje…

viz p11-kit, který se pomalu začíná rozšiřovat.

[petr_p]

Máte kryptografické zařízení, se kterým lze mluvit přes PKCS#11, třeba prostřednictvím PKCS#11 modulu OpenSC. Takový modul umí používat OpenSSL, GnuTLS, NSS a tedy i lecjaký program. Například webový prohlížeč.

Pak máme JDK, který si bohužel dělá vše po svém. Ale údajně to má umět. Pak lze předpokládat, že javový applet při podepisování namísto PKCS#12 souboru použije PKCS#11 modul, z kterého si uživatel vybere klíč a zadá PIN. V tomto případě je tedy webový prohlížeč irelevantní.

[Filip Jirsák]

JDK bohužel kvůli multiplatformnosti nezbývá nic jiného, než si to řešit po svém. Ale pokud se to kryptografické zařízení umí zaregistrovat na Windows nebo Apple do systému, může s ním Java mluvit přes systém.

Přímé použití PKCS#11 modulu je také možné, ale předpokládám, že u aplikace spuštěné z Java pluginu bude problém v tom, že to vyžaduje načtení nativní knihovny ze systému, což by neměl bezpečnostní modul pluginu povolit.

[little.owl]

Takový modul umí používat OpenSSL, GnuTLS, NSS a tedy i lecjaký program. Například webový prohlížeč.

Mne to zatim nikdy moc nefungovalo pod Linuxem, viz treba zde.

Pouzivam Yubikey NEO a tam jsem s Javou nemel problem.

[petr_p]

Včera jsem si opět zkusil SunPKCS11 s OpenJDK-1.7.0 a už téměř funguje. Kromě podstatné chyby, že má rozbité procházení slotů.

[petr_p]

To je Firefox. Ten je rozbitý záměrně.

Předchozí verze neuměly použít kryptografické zařízení připojené až po spuštění Firefoxu. Prý kvůli chybným proprietárním PKCS#11 modulům. Teď jsem si vyzkoušel 30. verzi a ta naopak se celá zablokuje v nějakém futexu.

Rovněž NSS neumí pracovat s jednou databází z více procesů, takže není možné použít ten samý modul z Firefoxu a Thunderbirdu najednou. To je kvůli tomu, že ve Windows se na bezpečnost kašle, takže tam si procesy mohou krást autentizované PKCS#11 relace, což v OpenSC je schválně kvůli bezpečnosti vypnuté. Jenže Linux není v očích Mozilly business case, takže na opravu peče.

Jinak řečeno cokoliv na NSS je odsouzeno k záhubě. Díval jsem na Midori s gcr a libsoup, které je postaveno nad GnuTLS, jenže to dělá banda Gnomáků, se kterými není žádná domluva. Nehledě na to, že je to prorostlé s Gnome.

On ale vývoj je těžký i na nižších úrovních. Opravil jsem používání OpenSSL enginů v cURL. Jenže opravu engine_pkcs11 (implementace OpenSSL enginu nad PKCS#11) jsem neprotlačil, protože správce vůbec nereaguje, třebaže ten samý člověk v OpenSC je docela aktivní. Takže lokálně mi kryptografické moduly v cURL aplikacích pěkně fungují, ale nikdo jiný si to užít nemůže. Ještě zvažuji, že přeportuji cURL backend pro GnuTLS na trojkové rozhraní, které PKCS#11 umí. To současné dvojkové umí jen soubory.

[little.owl]

Diky, ta odpoved me trochu zaskocila. Pak chapu lidi, co sahnou po Jave.

[Filip Jirsák]

Pokud jde o původní kontext diskuse - elektronický podpis v prohlížeči, pak je Java jediná reálná možnost. Vedle ní už zbývají jen nativní pluginy pro každý prohlížeč, které by si uživatelé museli instalovat - a to není řešení pro veřejný web, které by mělo "prostě fungovat".

[David Jaša]

Rovněž NSS neumí pracovat s jednou databází z více procesů, takže není možné použít ten samý modul z Firefoxu a Thunderbirdu najednou.

to se snad týká jen berkeley db, kterou doufám FF ani TB nepoužívají a v dohledné době by už ani neměla být defaultní, nebo se pletu?

[petr_p]

Nevím v čem jiném je problém, každopádně Firefox mi nový profil pořád vyrábí s BerkeleyDB.

[Filip Jirsák]

Privátní klíč se ukládá na smartcard nebo token proto, aby se k němu nikdo nedostal. Takže vaše teorie, kterou jste si právě vymyslel, je zajímavá, nicméně troskotá na několika věcech:

• privátní klíč na smartcard, tokenu nebo v HSM není z venku dostupný,
• neexistuje nic jako "vyhledat klíč na USBéčku",
• neexistuje žádný široce implementovaný standard, který by umožnil z webového prohlížeče nějak manipulovat přímo s USB zařízeními

No a ten privátní klíč nemusí mít s USB vůbec nic společného, může být uložen v nějakém HSM, se kterým se komunikuje jinak, než přes USB, může být teoreticky uložen třeba v samostatném serverovém procesu (po Heartbleed by to bylo dost rozumné opatření).

[pavlix]

po Heartbleed by to bylo dost rozumné opatření

Řekl bych, že úplně stejně rozumné jako předtím.

[Filip Jirsák]

Existuje nějaká iniciativa, která by se snažila něco takového implementovat na Linuxu, třeba pro Apache? Nebo toho lze docílit se současnými nástroji? Na Windows se k tomu dá použít systémové úložiště certifikátů, a dříve by mne nikdy nenapadlo, že může být bezpečnější privátní klíč uložit tam a ne si ho obhospodařovat přímo v aplikaci.

[pavlix]

Není mi jasná souvislost s mým příspěvkem. Pokud tě zajímá Apache, pak nevidím důvod proč neprojít jejich webové stránky nebo nepoužít vyhledávač. Existuje pro Linux hromada software, který umí pracovat například s PKCS#11, ale neumím ti z hlavy vysypat který všechen software to podporuje, případně který podporuje jiné protokoly. V praxi se hodně používají i věci jako OTP tokeny, které fungují nezávisle na podpoře v klientských aplikacích a v serverových aplikacích vyžadují jednoduchý autentizační modul.

[Filip Jirsák]

Vzhledem k tomu, že spousta serverového softwaru používá OpenSSL, očekával bych implementaci spíš tam. Dnes umí OpenSSL pracovat s privátním klíčem v souboru, nebo může komunikovat s nějakým HSM. Úplně stejně by mohl komunikovat se „softwarovým HSM“. Pro spoustu instalací by to bylo dostatečné řešení – pokud má někdo nějaký VPS, asi k tomu nebude pořizovat nějaký USB token. Já nevím o žádném enginu do OpenSSL, který by „softwarový HSM“ implementoval, Googlem jsem nic nenašel (ale jenom hádám, na co se jej vlastně ptát). V mainstreamu asi zatím nic takového neexistuje, ale třeba už někdo na něčem takovém dělá, a třeba o tom někdo z diskutujících ví.

[pavlix]

SoftHSM

[Filip Jirsák]

Díky. Takhle nějak jsem si ten projekt představoval

[pavlix]

Seznámil jsem se s ním v souvislosti s DNSSEC a FreeIPA, tedy je to něco, u čeho se očekává reálné použití.

[Bedňa]

Jj som pako.

[David Jaša]

Přidej si do nssdb "kulky" (modul coolkey) a zkus to ještě jednou.

[g.g]

U Chrome se dá kompilovat i do PNaCl. Takže čistý výsledek by měl být ten, že software v C/C++/Javě by měl schopný běžet ve všech prohlížečích, a v některých dokonce i rychle.

[chrono]

To je ale problém Oracle a nie Google (nikto nebráni Oracle urobiť ich Java plugin aj s Pepper rozhraním). :)

[R]

Takze Google si vymyslel vlastne PPAPI (ktore ziadny iny browser nepodporuje) a teraz odstranil podporu NPAPI a je to problem Oracle? A je to este aj problem IcedTea, ze?

Mne ten Chromium 35 uz nejde ani spustit (illegal instruction), tak som ho vyhodil. Problem vyrieseny.

[chrono]

Samozrejme že je to problém Oracle. V Linuxe sa NPAPI používa viac-menej len kvôli Flash (a možno trochu kvôli tej Jave), takže skôr či neskôr budú musieť prehliadače pod Linuxom podporovať PPAPI (pretože Flash v inej verzii nebude). ;)

[jadd]

Verze 11.2 ti nestačí? Mě stačí i 10.2. Nebo jaký fleš nebude?

[chrono]

Áno, keď Adobe prestane vydávať bezpečnostné opravy pre Flash 11.2, nič mi nebude brániť poslednú verziu používať aj ďalej. Bude také niečo podporovať aj Firefox, alebo ten plugin zablokujú (ako to napr. urobili pri niektorých verziách Java pluginu)?

[chrono]

Každopádne je možné, že o tri roky, keď prestane Adobe vydávať opravy pre 11.2, už nikto nebude Flash používať.

[R]

Jednoducho povedane: Google sa sprava rovnako ako M$ - vymyslia si svoj "standard" a potom nutia vsetkych ostatnych ho implementovat.

[chrono]

Nikoho do ničoho nenútia. Ak bude chieť Oracle, aby ich Java fungovala v Chrome/Chromium, tak to budú musieť nejako riešiť (inak môžu PPAPI ignorovať).