ZeroBin – sdílení textů

Na Internetu je k dispozici řada „pastebin“ služeb, které umožňují vkládat texty a odkazovat na ně. Uživatelé si tak nemusí hned zakládat weby nebo blogy, aby sdíleli kus textu s ostatními. Většina těchto služeb má tu vlastnost, že sdílený text je přístupný nejen čtenářům, ale i provozovateli služby (a komukoli, kdo má přístup k síťové infrastruktuře a serverům), což nemusí být vždy žádoucí. Proto vznikla webová aplikace ZeroBin, díky které se data šifrují už v prohlížeči uživatele vkládajícího text a opět se dešifrují až v prohlížeči čtenáře. V češtině si o fungování ZeroBinu můžete přečíst v článku Diskrétní sdílení textů.

1.5.2012 20:50 | xkucf03 | Zajímavý software

Komentáře

[Max]

To nasadili děcka od Anonymous, ne? Viz anonpaste.tk, který je teď off.
Zdar Max

[Zopper]

Anonpaste.tk nasadily děcka od Anonymous? Já myslel, že to nasadila CIA, či některá jiná služba...

[pavlix]

To se vylučuje?

[anon]

Aha ono se to za # totiz nikam neposila. Vychytany.

[Harvie.CZ]

Pokud to ovsem nekam neposle javascript vhodne podstrceny neduveryhodnym kodem na serveru...

[l4m4]

Technická vychytávka pěkná. Ale otázku distribuce klíčů (v tomto případě URL fragmentů) pouze správným osobám v podstatě pouze odkládáme.

Když to hodím na pastebin, zašifrované šfrovnáím s veřejným klíčem (a případě použitím steganografie), který rozšifrují jen správné osoby, tak se nedá jen tak leaknout URL, které umožňuje přečtení, dekódování je explictní krok u příjemce. A nejsem-li paranoidní, tak co řešeím?

[anon]

Me napada ze to nemusi byt kezeny je na text a stejny princip.by mohl pouzit tteereba rapidshare ... I kdyz rozbalovat treba 2gb v js browseru..

[cezz]

V principe mozes client side sifrovat uz teraz. (Minimalne archivy z heslom su pomerne bezne, nech uz je to bezpecne akokolvek)

[l4m4]

Archivy s heslem jsou v principu bezpečnější než toto, protože distribuční kanály hesla a odkazu na archiv jsou zcela oddělené.

[xkucf03]

To jo, ale chtělo by to nějak standardizovat, aby šlo dešifrovat už během stahování – takhle musíš všechno stáhnout na disk a pak to teprve prohnat přes procesor a uložit na jiné místo na disku.

[luky]

wget -O - | whatever

[xkucf03]

Jo, souhlas, ale když stahuješ třeba z nějaké služby, kde musíš opisovat kód nebo na něco klikat, tak to není zrovna pohodlné – musel bys stopnout stahování, které začal prohlížeč, zkopírovat si URL a stáhnout přes wget (a doufat, že tě to server nechá stáhnout podruhé).

P.S. a ano, je to primárně chyba těch služeb – za normálních okolností by to byl obyčejný odkaz, který by sis prostě zkopíroval…

[Jendа]

Není problém v tom, že tvůj prohlížeč neumí poslat stahovaný soubor pajpou do stdin libovolného procesu?

(můj bohužel taky ne)

[xkucf03]

To taky

Někde jsem viděl plugin do FF, který předává* ty stahované soubory KGetu a ten je stahuje. To by možná šlo použít – místo KGetu by byl jiný program, který by pozdržel stahování (nebo spíš stahoval do bufferu) a zeptal se tě, co s tím chceš dělat – třeba bys mohl napsat příkaz, kterému to předat rourou. Možné to určitě je, otázka je, jestli už to někdo napsal…

*) a často bude potřeba předat kromě URL i sušenky nebo HTTP Basic jméno a heslo.

[chrono]

Problém je, že to nijako nerieši "man-in-the-middle" útoky, takže to až tak bezpečné nie je.

[ASS]

a co https pristup? :)

[Josef Kufner]

Tím si moc nepomůžeš. Provozovatel si to může odposlechnout tak jako tak a různé instituce si můžou bez problému pořídit vhodný certifikát.

[xkucf03]

S tím certifikátem to není tak jednoduché a taky uživatel může mít něco jako Certificate Patrol a podvrhu si všimne.

Serveru ale potřeba věřit je, to je fakt -- tedy pokud nebudeš pokaždé číst ten JavaScript*. Tady je řešením ten desktopový klient -- pak se ze serveru stává skutečně jen poskytovatel diskového a adresního prostoru, ale do dat ti koukat nemůže (maximálně je může smazat, ale neví, co maže).

*) BTW: tady by se celkem hodilo nějaké podepisování kódu -- dejme tomu, že věřím autorovi aplikace, ale nevěřím provozovateli, tak bych kontroloval, zda kód neupravil. Nebo by aspoň prohlížeč mohl upozorňovat, že se JS od minule změnil...

[Jendа]

JS kód na šifrování vám posílá server při každé session, ne? Co když se v něm jednoho dne objeví backdoor?

[xkucf03]

No, posílá ho jen poprvé (pak už chodí HTTP 304 Not Modified), ale toho si uživatel stejně nevšimne, jestli se něco nezměnilo a nestahoval se znova...

Napsal jsem si BASH skript, který zašifruje standardní vstup náhodným klíčem pomocí OpenSSL a pošle na server, akorát to má drobnou vadu v tom, že server používá AES v CCM režimu (pravděpodobně) a můj OpenSSL ho neumí. BouncyCastle* knihovna to umí a zatím to vypadá jako jediná možnost, jak udělat desktopového klienta.

Taky by šlo interpretovat na desktopu ten původní JavaScript, ale říkal jsem si, že by bylo fajn mít dvě nezávislé implementace, aby se ověřilo, že to skutečně funguje a šifruje správně.

*) ale to je zase Java, na to se bude spousta lidí hnusně tvářit, i když mně osobně to nevadí

[kralyk z abclinuxu]

Jo, to je slabina tohohle systému. Řešit by to mohl 1) extension do browseru, což není úplně praktické, nebo a lépe 2) Crypto API v prohlížeči, což by do budoucna vůbec nebylo špatné.

[Harvie.CZ]

Existuji ruzne pluginy do prohlizecu... Opravdu se mi libi "encrypt the cloud", ktery je bohuzel symetricky... vic by se mi libil, kdyby treba pouzil kod "GPG4Browsers", tak by byl pro me zajimavejsi...