abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 23:55 | Zajímavý článek

Článek Refund of pre-installed Windows: Lenovo must pay 20,000 euros in damages pojednává o rozhodnutí italského soudu týkajícího se vracení nechtěných licencí MS Windows přibalených k notebookům Lenovo. Soud odmítl všechny námitky Lenova a potvrdil právo na odškodnění – vrácení poplatku za nevyužitou licenci uživateli. Nátlak na výrobce HW, aby povinně přibalovali MS Windows k prodávaným počítačům, je jednou z pochybných

… více »
xkucf03 | Komentářů: 2
včera 15:22 | Zajímavý software

Termy (GitHub) je multiplatformní terminál postavený nad frameworkem Electron. Může zaujmout automatickým doplňováním IntelliSense a integrovaným editorem z Visual Studio Code. Ke stažení je AppImage.

Ladislav Hagara | Komentářů: 0
včera 13:12 | Bezpečnostní upozornění

Univerzita Illinois objevila zranitelnost v Intel CPU u SoC Ring Interconnect. O zranitelnosti se mluví jako o "Lord of the Ring(s)". Výzkum byl zaměřen na procesory Skylake/Coffeelake, takže není jasné, zda postihuje i novější architektury. Procesory AMD používají jiné druhy propojení, takže tam je zatím stav neznámý, resp. vyžadoval by další výzkum. Podrobnosti naleznete na The Hacker News, samotná publikace pak viz: 2103.03443.pdf. Dále jsou k dispozici zdrojové kódy pro test zranitelnosti na GitHub - lotr.

Max | Komentářů: 10
včera 08:35 | Zajímavý software

Toužíte si prohlížet YouTube videa v konzoli? Pokud ano, je zde projekt ytfzf, který vám to umožní. Jedná se o bash script, který jako backend mj. používá youtube-dl.

Max | Komentářů: 3
7.3. 21:22 | Nová verze

Deno (Wikipedie), běhové prostředí (runtime) pro JavaScript a TypeScript naprogramované v Rustu, bylo vydáno ve verzi 1.8. Přehled novinek v poznámkách k vydání. Z novinek lze zmínit experimentální podporu WebGPU API. Cílem je podpora TensorFlow.js s GPU akcelerací.

Ladislav Hagara | Komentářů: 0
7.3. 15:44 | Nová verze

Byla vydána verze 8.00 linuxové distribuce SystemRescue, původně SystemRescueCd. Přehled novinek v changelogu. Linux byl povýšen na verzi 5.10.20. GParted na verzi 1.2.0. Xfce na verzi 4.16. Nově byl začleněn paperkey pro vytištění OpenPGP privátních klíčů.

Ladislav Hagara | Komentářů: 0
7.3. 14:33 | Komunita

Byly vyhlášeny výsledky soutěže firmy Adfinis o nejlepší šablony pro LibreOffice. Z třiceti přihlášených vybrala porota šest vítězů. Všechny šablony si lze prohlédnout a stáhnout na stránce s oznámením o výsledcích soutěže. Green cabinet připravuje překlady šablon do češtiny, obdobně jako to již učinili v případě šablon indonéské komunity.

Zdeněk Crhonek | Komentářů: 0
5.3. 20:22 | Pozvánky

Zítra proběhne jednodenní online konference InstallFest 2021. Na programu je celá řada zajímavých přednášek, workshopů a také stánků. Dění lze sledovat na Twitteru.

Ladislav Hagara | Komentářů: 3
5.3. 13:11 | Nová verze

Byla vydána nová verze 6.5 v Javě napsané aplikace pro komplexní návrh rozmístění nábytku a dalšího vybavení v interiérech Sweet Home 3D. Vyzkoušet lze online verzi. Nedávno byly aktualizovány také knihovny nábytku.

Ladislav Hagara | Komentářů: 1
5.3. 08:00 | Humor

Nové verze webových prohlížečů Firefox a Chrome byly vydávány každých 6 týdnů. Vývojářům Firefoxu se nelíbilo, že Chrome bude mít vždy větší číslo verze, proto se rozhodli vydávat nové verze Firefoxu každé 4 týdny. Aktuální stav: Firefox 86 byl vydán v 8. týdnu a Chrome 89 v 9 týdnu letošního roku. V kterém týdnu bude mít Firefox větší číslo verze než Chrome?

… více »
Ladislav Hagara | Komentářů: 46
Vzděláváte se formou hromadných online kurzů (MOOC)?
 (62%)
 (8%)
 (1%)
 (6%)
 (23%)
Celkem 169 hlasů
 Komentářů: 1, poslední 7.3. 11:50
Rozcestník

Java SE 7u25 a bezpečnostní chyba v Javadoc

Oracle vydal Javu SE 7u25. Opraveno je 40 bezpečnostních chyb, z nichž 37 je zneužitelných vzdáleně. Bezpečnostní chyba byla nalezena i v nástroji pro generování dokumentace Javadoc (VU#225657, frame injection). Je-li dokumentace přístupná pomocí webového serveru, měla by být opětovně vygenerována pomocí opravené verze Javadoc.

19.6.2013 11:42 | Ladislav Hagara | Bezpečnostní upozornění


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

19.6.2013 13:37 jehovista
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
To zas bude v diskuzich nablito.
Bedňa avatar 19.6.2013 14:10 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Neviem prečo? Java je predsa šmejďárna :)
KERNEL ULTRAS video channel >>>
20.6.2013 13:43 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
ano, utekaj si k svojmu jedinemu dokonalemu pure C99999
21.6.2013 14:59 mankind_boost
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Asi se všichni shodneme na tom, že Java (přinejmenším její implementace od Oracle) je naprostá žumpa.
21.6.2013 15:18 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
-1
19.6.2013 14:39 mankind_boost
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Na každém šprochu pravdy trochu.
19.6.2013 17:50 Miriam
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Bůůů, bůůůůů, kritika, rychle zacpat uši polštářem a schovat se do skříně
19.6.2013 15:06 ewew | skóre: 39 | blog: ewewov_blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Už by mohli dať bezpečnosť javy do poriadku. Vypnúť javu nie je riešenie, pretože veĺa stránok ani nefunguje bez povolenej javy.

Root v linuxe : "Root povedal, linux vykona."
Bedňa avatar 19.6.2013 15:46 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Nainštaluj si doplnok na vypínanie Javy a zapínaj len tam, kde si myslíš že by to mohlo byť bezpečné.
KERNEL ULTRAS video channel >>>
19.6.2013 15:52 8an | skóre: 30
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Dneska naštěstí už jenom pár specialit... I bankovnictví Komerční banky se konečně postupně Javy zbavuje.
If you build an operating system that even an idiot can use, only idiots will use it.
20.6.2013 13:45 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
a dava tam co? :D python s djangom?
21.6.2013 17:24 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
20.6.2013 00:21 j
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Takovy stranky jsou ovsem zcela nezajimavy. Rad vyhovim provozovateli - nema zajem o me (a potencielne me penize) => ja nemam zajem o nej.
20.6.2013 17:30 kolbert
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Reci o potencialnim placeni sluzeb/software me u Cechu vzdycky pobavi :)
19.6.2013 21:46 bluemoon
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Nejhorsi je to, ze java je na temer vsech informacnich a zakazkovych systemech, kde potrebujete elektronicky podepisovat zadosti a dokumenty.

Nedavno jsem s technickou podporou resil problem pristupu kvuli tomu, ze nas zakaznik pouzil token, ze ktereho nelze klic dostat a zakazkovy system po nem chtel pfx soubor jak s certifikatem tak klicem. Bylo mi z toho docela smutno, ze java obstarava pristup k ulozisti klicu.
20.6.2013 08:57 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Vzhledem k tomu, že to je prakticky jediný způsob, není se co divit. Alternativou je snad jen ActiveX pouze pro Internet Explorer, případně napsat a distribuovat vlastní plugin po vzoru Javy nebo Flashe.
20.6.2013 10:54 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Alternativou resp. správným řešením je vysrat se na „webové aplikace“ a udělat normální desktopovou aplikaci, ať už v Javě nebo třeba C++. Když už to má být web, tak se držet standardního API.
20.6.2013 11:13 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ne pokud je to určeno pro širokou veřejnost. Já si nebudu instalovat speciální aplikace banky, pojišťovny, finančního úřadu, pošty a bůhvíkoho ještě jenom proto, abych jim jednou za rok něco elektronicky poslal…

Standardní API na webu je dost mlhavý pojem – jinak dnes se tomu standardnímu API říká HTML5. Každopádně bych podporu pro elektronický podpis ve „standardním webovém API“ uvítal mnohem víc, než spoustu z mého pohledu spoustu zbytečností, které se do HTML5 dostávají.
20.6.2013 11:27 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Já si nebudu instalovat speciální aplikace banky, pojišťovny, finančního úřadu, pošty a bůhvíkoho ještě jenom proto, abych jim jednou za rok něco elektronicky poslal…
Ona by stačila jednoduchá GUI aplikace pod svobodnou licencí pro vyplňování a podepisování formulářů. Výstupem by byl buď podepsaný soubor (ten by uživatel sám odeslal e-mailem nebo třeba přes web) nebo by ho ta aplikace rovnou odeslala na nějakou webovou službu. Vstupem by byla definice formuláře + volitelně adresa webové služby. Stejná aplikace by šla použít pro víc institucí.

Alternativou je akceptovat data podepsaná GPG nebo OpenSSL a dodat jen nějaký skript, který podpis usnadní.

Každopádně bych podporu pro elektronický podpis ve „standardním webovém API“ uvítal mnohem víc, než spoustu z mého pohledu spoustu zbytečností, které se do HTML5 dostávají.

Souhlas, tohle by se hodilo. Jen je otázka, jak zajistit, aby uživatel podepsal skutečně to, co si myslí, že podepisuje – aby mu web nepodstrčil k podepsání jiná data, než se zobrazjí ve formuláři. Např. by tam bylo pomocí CSS skryté políčko „chci od vás dostávat spam e-mailem“ nebo „zavazuji se odebírat vaše služby příštích deset let“.
20.6.2013 11:53 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ta aplikace už existuje – říká se jí webový prohlížeč. Akorát ten e-podpis sama o sobě neumí…
20.6.2013 13:02 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ona neumí mnohem víc věcí (jako třeba bezpečně ukázat uživateli, co přesně podepisuje) a naopak umí spoustu zbytečností (z tohoto pohledu), rozhodně to není „jednoduchá GUI aplikace“.
20.6.2013 13:55 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Uživatel by neměl podepisovat XML, ale např. PDF vyrobené z toho XML (zároveň to XML je uvnitř vložené). To webové prohlížeče umí. Další obrovskou výhodou je, že webový prohlížeč má každý uživatel už nainstalovaný. A ta jednoduchá GUI aplikace by zase až tak jednoduchá nebyla. Pro praktickou editaci formulářů potřebujete formulář zobrazit v určité podobě (takže vykreslovací jádro), potřebujete tam mít nějakou kontrolu a doplňování (takže nějaký skriptovací jazyk), potřebujete napojení na externí číselníky (takže podpora HTTP komunikace). No a o moc víc už toho webový prohlížeč neumí – možná přehrávání multimédií. Ale nemá smysl psát zcela nový internetový prohlížeč, který akorát nebude umět přehrávat video.
20.6.2013 14:24 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Řešením je rozdělit podepisování a aplikaci (webovou nebo jakoukoliv jinou). Tedy aplikace dá uživateli data jako soubor, uživatel si je podepíše ve svém důvěryhodném nástroji a podpis nebo podepsáná data uživatel opět dodá aplikaci.

Jaký na to bude API (jestli soubor, socket, nebo volání funkcí), je už celkem jedno.

Nebude to sice tak jednoduché jako stisk jednoho tlačítka, ale aspoň se začnou uživatelé dožadovat, aby se podepisovaly otevřené a snadno čitelné dokumenty. To vůbec není případ obecného (třeba s vestavěným SWF objektem) PDF nebo jakýsi stovky kilobajtů dlouhý ad-hoc XML dokument (jako dnes vypadá daňové přiznání) nebo nějaký blob (jako dělají banky).

20.6.2013 16:25 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Myslím, že třeba ve webmailu je to jednoduché – buď to bude na jedno tlačítko přímo na webu, nebo uživatelé e-maily podepisovat nebudou. Souhlasím, že webmail a většina web* aplikací je nesmysl a bylo by možné napsat lepší a uživatelsky přívětivější desktopové aplikace. Jenže ty webové aplikace tady jsou, jejich desktopové ekvivalenty jsou ještě horší než ty webové, takže asi nezbývá, než se snažit aspoň ty webové aplikace nějak zkulturnit. Ostatně už se takhle do prohlížečů přidala podpora pro vícenásobný upload, pro drag-and-drop, pro přehrávání videa – takže elektronický podpis by byl jen další v řadě. Ostatně i v tom prohlížeči to může být konfigurovatelné a kdo bude chtít, může soubor předat své důvěryhodné aplikaci.
20.6.2013 16:42 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
buď to bude na jedno tlačítko přímo na webu, nebo uživatelé e-maily podepisovat nebudou
V tom případě je lepší, když podepisovat nebudou – vytvářelo by to pouze falešný pocit bezpečí a více zmatků. To bude lepší, když e-mail podepíše na serveru poskytovatel pomocí DKIM a na straně příjemce se to ověří.

Protože ve skutečnosti by to byl poskytovatel, kdo by měl nad podepisováním moc – nikoli uživatel. Ten by pouze stiskl to jedno tlačítko a JavaScript (právě stažený ze serveru poskytovatele) by cosi poslal na podepisovací API prohlížeče a nechal to podepsat uživatelem. Ale kdo zaručí, že to „cosi“ bylo totéž, co psal uživatel do HTML formuláře?

Oproti tomu podepisování na serveru je celkem rozumné řešení – většinou ti totiž stačí vědět, že e-mail pochází od nějaké organizace (domény) a nemusíš mít ověřenou identitu konkrétního odesílatele (osoby). Výhodou je, že koncový uživatel nemusí dělat vůbec nic, resp. dělá věci stejně jako dřív a je to bezpečnější. Pokud potřebuješ „end-to-end“ bezpečnost mezi konkrétními osobami, tak to vyžaduje trošku víc úsilí, znalostí a technického vybavení.
20.6.2013 16:52 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
To bude lepší, když e-mail podepíše na serveru poskytovatel pomocí DKIM a na straně příjemce se to ověří.

Leda v případě, že se c2s smtp nahradí něčím jiným, co bude schopno zaručit pravost odesilatelovy emailové adresy.
20.6.2013 16:59 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
V SMTP se klient ověří jménem a heslem – to určuje jeho e-mailovou adresu (společně s doménou serveru) nebo ho to alespoň spolehlivě identifikuje.

Když jako server dovolíš posílat z jiných domén, tak tato adresa už ověřená nebude, ale bude ověřené, že to poslal někdo z tvých uživatelů a ví se, kdo to byl. Na straně příjemce se pak zobrazí něco jako:
Odesílatel: franta@example.com (neověřeno)
Odesláno přes: example.net (ověřeno)
A víš, na čem jsi.
20.6.2013 16:54 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Já jsem si pod webmailem představoval GMail nebo Seznam e-mail. Ve firmách je asi přeci jen rozšířenější Outlook. Já bych přes GMail klidně v prohlížeči podepsaný e-mail poslal – nemám důvod Googlu věřit méně než třeba Microsoftu, AMD, Suse nebo Intelu. A šifrovat podpis s tužkou na papíře opravdu nebudu.
20.6.2013 17:47 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Takové šifrování/podepisování ale ztrácí smysl resp. posouvá se na úplně jinou úroveň – vypovídací hodnota takového podpisu (resp. šifry) je: nějaký uživatel, za jehož identitu ručí poskytovatel XYZ, poslal přes tohoto poskytovatele e-mail (resp. zašifrovaný e-mail si přečte osoba pověřená poskytovatelem XYZ).

Nic víc ti to neřekne. A pro tento účel bohatě stačí DKIM a TLS spojení mezi servery. Nedává smysl se trápit s nějakou atrapou dalšího šifrování/podepisování.

Pokud to má být „end-to-end“ bezpečnost mezi dvěma uživateli, je potřeba použít software, který je pod nezávislou kontrolou a který nikam neodesílá soukromé klíče.

P.S. já bych tedy Googlu ani Microsoftu jakožto americkým firmám nevěřil. Daleko víc budu věřit svobodnému softwaru, který si může proklepnout kdokoli od chlápků z NSA přes ruské a čínské hackery až po české programátory.
stativ avatar 20.6.2013 19:03 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Pokud je to v JavaScriptu, tak to běží lokálně na počítači uživatele, a tudíž v tomhle smyslu není žádný rozdíl mezi nějakou speciální aplikací a JS v prohlížeči.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
xkucf03 avatar 20.6.2013 19:21 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Třeba se jednou dopracujeme k tomu, že to tak1 bude, ale zatím je mezi nimi značný rozdíl. JS se stahuje pokaždé znova2 a server mu může podstrčit, co chce a i to průběžně měnit3. Desktopovou aplikaci si jednou stáhneš, jednou si zkontroluješ elektronické podpisy, hashe, pročteš si její zdrojáky nebo si necháš udělat audit (dle svého uvážení) a pak ji používáš a aplikace funguje pořád stejně. V případě aktualizace si uděláš diff zdrojáků, nový audit nebo věříš autorům aplikace, každopádně to máš pod kontrolou a věci se dějí podle tvého.

[1] což vyžaduje určitou infrastrukturu, ne až tak složitou, ale zatím to prostě chybí
[2] případně se bere z mezipaměti, ale to uživatel neovlivní – naopak server si dle svého uvážení může vynutit tichou aktualizaci aplikace – uživatel nic nepozná
[3] webová aplikace, která jednou fungovala dobře a spolehlivě může najednou začít uživateli škodit, aniž by uživatel něco udělal (např. nainstaloval novou verzi)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.6.2013 21:59 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Baník pyčo!
20.6.2013 22:04 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
V každém případě dokud takové API (nevím o tom že by vznikalo, nebo má někdo nějaké info?) nebude a prohlížeče ho nebudou podporovat, tak se nepohneme. A rozhodně se musí to api navrhnout velmi kvalitně, aby nenastal problém s bezpečností. Zde ale architektům html technologií celkem věřím, protože jsou hodně paranoidní. Jako příklad dám třeba možnost javascriptu udělat fullscreen. Ve flashi naprosto normální věc (nemožnost dát si přes celou obrazovku video na youtube by asi každého nasr...), ale přes js (html5 video) to otravuje potvrzením, protože by někdo právě mohl vykreslit něco podvrženého (třeba ve fullscreenu celý nový prohlížeč, doufat že se trefil do verze a vzhledu OS a doufat, že tam netušící uživatel zadá přihlašovací údaje do e-bankovnictví :-D - ve flashi no problem, ale stejně to nikdy nikdo neudělal :-D).
Baník pyčo!
xkucf03 avatar 20.6.2013 19:13 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
P.S. já bych tedy Googlu ani Microsoftu jakožto americkým firmám nevěřil.

Tohle je celkem jednoduchý a funkční obchodní model:

Vláda poskytuje:

  • peníze daňových poplatníků (výnosné státní zakázky)
  • boj proti „pirátství“
  • poškozování konkurence
  • průmyslovou špionáž v zahraničí

Firma vyvíjející uzavřený software poskytuje

  • informace o zneužitelných bezpečnostních chybách
  • backdoory na přání
  • data domácích uživatelů
  • data zahraničních uživatelů (vhodné mj. pro průmyslovou špionáž)
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
21.6.2013 11:20 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
V EU nikoho nezajímá, že jsem poslal e-mail přes GMail. Když ale ten e-mail bude podepsaný mým kvalifikovaným certifikátem, má v rámci EU právní platnost jako vlastnoručně podepsaný.

Do toho svobodného prohlížeče si přece klidně můžete implementovat funkci, která zkontroluje, že JavaScript poslaný serverem odpovídá zkontrolovanému vzoru.

Ten svobodný software nespouštíte na procesorech vyrobených americkými firmami?
xkucf03 avatar 21.6.2013 19:16 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
V EU nikoho nezajímá, že jsem poslal e-mail přes GMail. Když ale ten e-mail bude podepsaný mým kvalifikovaným certifikátem, má v rámci EU právní platnost jako vlastnoručně podepsaný.
Pokud ale ten soukromý klíč svěříš Googlu[nebo jinému „cloudovému“ poskytovateli – a to takovým způsobem, že si ho klidně může poslat na svůj server, aniž by sis toho všiml], tak to ztrácí smysl a vypovídací hodnota takového podpisu je stejná, jako hodnota DKIM podpisu.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
21.6.2013 23:40 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Místo toho ho můžu poskytnout svému poskytovateli desktopového poštovního klienta nebo šifrovacího programu. Stejně tak ho poskytnu výrobci operačního systému, systémových knihoven, základní desky, procesoru a dalšího hardware... Těm všem také nevěříš a všechno si kontroluješ? Nebo máš někde hranici, a spoustě subjektů věříš -- výrobci hardware, správci tvé distribuce, vývojáři tebou používaného opensource softwaru? Tak já mám prostě tu hranici o kousek vedle a mezi ty důvěryhodné subjekty bych v tomto případě zařadil i GMail.

Vypovídací hodnota není stejná, e-mail podepsaný kvalifikovaným certifikátem má v EU právní váhu. To, jak jsem ten podpis vytvořil, nikoho nezajímá (pokud nedojde ke sporům), to, že svěřím privátní klíč GMailu je moje riziko. Já to tedy zatím dělám tak, že e-mail podepíšu svou utilitou (která ale používá implementaci podepisování od Oracle resp. původně Sunu) a pak podepsaný e-mail vložím do fronty na svém SMTP serveru. Ale mít možnost poslat to přímo přes GMail, udělal bych to -- a necítil bych se méně bezpečný, než dnes, zato by to bylo mnohem pohodlnější.
21.6.2013 23:42 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Navíc tady byla celou dobu řeč o podepisování v prohlížeči, takže bych privátní klíč neposkytoval Googlu jako poskytovateli GMailu, ale Googlu jako autorovi Chrome :-)
xkucf03 avatar 22.6.2013 10:42 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Ty opravdu nevidíš rozdíl mezi tím když:

  • Google1 ti2 v jediné HTTP odpovědi pošle pozměněný JS, který ukradne tvoje klíče, a dál posílá zase standardní JS.
  • Autor softwaru jednou za čas zveřejní novou verzi programu včetně zdrojových kódů, poskytne všem tu stejnou verzi, projde to přes distribuce, kdokoli ten kód může zkontrolovat a staré verze se archivují (obvykle s digitálním podpisem autora) a lze zpětně dohledat, co se kdy změnilo (+ k tomu máme i veřejně přístupné úložiště verzovacího systému).
?

[1] nebo nějaký MITM s přístupem k jeho důvěryhodným certifikátům
[2] selektivně jenom tobě – nikdo jiný se o tom dnes nedozví a nejde to zpětně dohledat

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
22.6.2013 12:05 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Implementace podepisování v prohlížeči by opravdu nemohla být udělána tak hloupě, aby se JS dostal k privátnímu klíči -- to by pak byla na nic.

Proti zaslání pozměněného JS se přeci lze bránit doplňkem v prohlížeči, který bude kontrolovat, že se JS nezměnil. Stejně jako jiné doplňky kontrolují, že se nezměnil HTTPS certifikát.

Z mého pohledu v tom rozdíl není. Buď Googlu věřím, že ten privátní klíč neukradne -- ne proto, že by se na to mohlo přijít, ale že to prostě neudělá. Pak mezi těmi dvěma případy není rozdíl. Nebo mu to nevěřím a beru to tak, že jediný důvod, proč klíče neukradne, je ten, že by se na to mohlo přijít. To je asi tvůj případ -- ale já služby takového poskytovatele nebudu používat vůbec. Navíc autor tvé distribuce taky může selektivně jenom tobě poslat podvržený balíček s webovým prohlížečem, který ukradne privátní klíč a vzápětí se nahradí standardním balíčkem.

A ještě jedna drobnost: "kdokoli může kód zkontrolovat" je z hlediska bezpečnosti nulový přínos. Bezpečnost zvyšuje pouze to, když někdo kód zkontroluje. Těch případů, kdy se spoléhalo na to, že někdo něco může udělat, ale pak se ukázalo, že to nefunguje, protože to ve skutečnosti nikdo nedělá, jsou miliony (ne jen v oblasti softwaru, ale třeba v ekonomice nebo v politice).
xkucf03 avatar 22.6.2013 14:09 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Navíc autor tvé distribuce taky může selektivně jenom tobě poslat podvržený balíček s webovým prohlížečem, který ukradne privátní klíč a vzápětí se nahradí standardním balíčkem.

To není zdaleka tak jednoduché: neví, ze kterého zrcadla stahuji, jestli nepoužívám nějakou proxy resp. jakou mám IP adresu (nemluvě o tom, že za jednou IP může být X dalších uživatelů nebo celé sítě), nikam nepíšu jméno a heslo. Naopak u webové aplikace je ta identita uživatele jasně svázaná s HTTP relací (cookie). Co se týče zpětné dohledatelnosti, je to taky úplně jinde: po podvrženém balíčku zůstanou soubory + digitální podpis, po podvržené HTTPS komunikaci nezbude nic (pokud ji explicitně nezachytáváš a nearchivuješ).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
22.6.2013 16:12 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Jediný rozdíl je v tom, že e-mail zná tvou identitu skrze přihlašovací údaje, zatímco distribuční místo balíčků tvou identitu možná nezná. Co se týče zpětné dohledatelnosti, psal jsem už v minulém komentáři, že podvržený balíček po sobě může zahladit stopy po té, co vykoná svou práci. Na rozdíl od JavaScriptu totiž má v systému rootovská práva, takže po něm žádné soubory zbýt nemusí.

To, že se třeba na OpenSSL dělá bezpečnostní audit zdrojáků, je sice fajn, ale v tom OpenSSL se může k privátnímu klíči dostat taky glibc nebo jádro, a ty už tak důkladným bezpečnostním auditem neprocházejí. Navíc je to pořád kontrola zdroje, ale nemáte zaručeno, že k vám na počítač se dostane OpenSSL z toho zkontrolovaného zdroje.
22.6.2013 16:48 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Na každý váš případ spiknutí lze nalézt protiopatření. Pokud jste tak paranoidní, tak si binutils, gcc, glibc, linux a openssl můžete stáhnout a zkompilovat sám. Ostatně řada distribucí takhle funguje. A pokud jde o binární distribuce, tak si myslíte, že třeba Red Hat vyhodí milióny za certifikaci, a pak bude distribuovat poškozenou binárku?
22.6.2013 17:09 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Na každý váš případ spiknutí lze nalézt protiopatření.
Stejně jako pro ten podpis e-mailu v prohlížeči.
Jendа avatar 23.6.2013 17:47 Jendа | skóre: 76 | blog: Jenda | JO70FB
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Pokud jste tak paranoidní, tak si binutils, gcc, glibc, linux a openssl můžete stáhnout a zkompilovat sám.
Jak ověřím pravost zdrojáků, které stahuji?

Ne, srsly, můj ISP automaticky analyzuje stahované tarbally a když je v něm Makefile, tak do něj přidá exec jeho backdooru. Co s tím můžu dělat?
A pokud jde o binární distribuce, tak si myslíte, že třeba Red Hat vyhodí milióny za certifikaci, a pak bude distribuovat poškozenou binárku?
Ano, myslím. A nemusí to být RedHat, může to být kterýkoli z jeho zaměstnanců, který má nad podepisováním kontrolu, může to být kterákoli vláda, která má nad RH moc, a může to být kterýkoli hacker, který naboural kteréhokoli z těchto zaměstnanců nebo vlád.

Vy si vážně myslíte, že když DigiNotar vyhodí milióny za certifikaci, tak pak bude prodávat MITM certifikáty?
23.6.2013 20:39 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ne, srsly, můj ISP automaticky analyzuje stahované tarbally a když je v něm Makefile, tak do něj přidá exec jeho backdooru. Co s tím můžu dělat?

Chytří pánové vymysleli hashovací funkce a asymetrickou kryptografii. Mně třeba FTP GNU ukazuje takové soubory s příponou sig. Mně třeba rsyncová zrcadla Gentoo ukazují soubory Manifest. Mně třeba stejné soubory nabízí look-a-side cache Fedory nebo podepsané zdrojové balíčky Red Hat Enterprise Linuxu nebo GNU/Debianu. A dokonce ty soubory vypadají stejně z různých sítí a přes různé protokoly.

Řekl bych, že možnostem, jak si ověřit původnost zdrojáků toolchainu, může kdejaký notář či tak zvaně důvěryhodná instituce závidět.

Ano, myslím. A nemusí to být RedHat, může to být kterýkoli z jeho zaměstnanců, který má nad podepisováním kontrolu,

Zrovna z pozice podepisujícího zaměstnance to tak snadné není. Zdrojáky musí někdo nacpat do verzovacího systému, zdrojáky musí nějaký systém zkompilovat, někdo musí balíček otestovat, někdo jej musí podepsat, po podpisu jej musí vrátit do systému, a tak dále. A různé kroky dělají různí lidé. Ti lidé často ani nemají přímý přístup k daným systémům, pouze s nimi komunikují. A všude se táhnou kontrolní součty, logy a zálohy. Z tohoto pohledu útočit na konci řetězce je čiré bláznovství. To už je rozumnější nechat se zaměstnat jako vývojář, který stojí na úplném začátku, protože ten už v podstatě vaří z vody. I když ani ten to nemá bez rizika, protože toho křížově kontroluje jiný vývojář a vedle toho ještě bezpečností tým se baví pročítáním kódu a různé systémy v různých fázích dělají rozdílové testy.

může to být kterákoli vláda, která má nad RH moc,

Myslíte vlády, které brečí, jak jim firmy utíkají s daněmi za hranice? Myslíte nad firmou, která sice má vedení v Severní Karolíně, ale v podstatě veškerý provoz je rozprostřen po celé planetě?

a může to být kterýkoli hacker, který naboural kteréhokoli z těchto zaměstnanců nebo vlád.

Jistě, že jednorázový incident se může přihodit. Proto ale máme logy a zálohy, abychom mohli rozsah útoku odhalit, oběti varovat a učinit protiopatření.

Vy si vážně myslíte, že když DigiNotar vyhodí milióny za certifikaci, tak pak bude prodávat MITM certifikáty?

Však taky skončil. Jenom to ukazuje, že nelze bezmezně věřit jedné straně, ale je třeba křížově kontrolovat. Přesně tak, jako lze ověřit zdrojáky toolchainu.

24.6.2013 00:37 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ad hashovací funkce a balíčky -- když se tohle všechno dá použít na stažení zdrojáků v C++ nebo zkompilované binárky Thunderbirdu, proč by úplně ten samý mechanismus nešlo použít pro stažení JavaScriptu GMailu?

Ad podepisování distribučních balíčků -- nezapomněl jste napsat, že nepopisujete Linux, ale Hurd 1.0? Se správou distribučního balíčku osobní zkušenost nemám, ale všude jsem vždy četl, že balíček má v distribuci správce jednoho nebo žádného, jen o velké projekty typu KDE se stará tým lidí. Z pozice vývojáře opensource a správce opensource projektu zkušenost mám, a křížové kontroly jiným vývojářem, bezpečnostní tým a různé systémy, které dělají v různých fázích rozdílové testy -- možná v nějakém paralelním hodně vzdáleném vesmíru. Tohle platí možná pro OpenSSL, neplatí to ani pro jádro nebo glibc.
24.6.2013 01:32 jas | skóre: 13 | blog: blag
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Popisovany proces sa zrejme netykal upstreamu, ale RHELu.

24.6.2013 07:38 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
proč by úplně ten samý mechanismus nešlo použít pro stažení JavaScriptu GMailu?

Velmi omezeně. Kód Gmailu distribuuje jenom Gmail. Nikdo jej nearchivuje, nepodepisuje, ani neredistribuuje. Navíc samotný Gmail vám nedistribuuje zdroják, ale až výsledek překladu. Minimálně je prohraný všelijakými kompresory a zatemňovači. Taky se kód liší pro různé uživatele nebo země. A taky pro různé user agenty. Nehledě na to, že se mění jako ponožky (prohlédněte si třeba druhou stránku výsledků vyhledávače Googlu – samotná data se dodávají jako javascript – v HTML nejsou).

Ad podepisování distribučních balíčků -- nezapomněl jste napsat, že nepopisujete Linux, ale Hurd 1.0?

Popisoval jsem změnu kódu v komerční distribuci. Konkrétně v RHEL, když si ho předchozí komentář vzal na mušku.

Se správou distribučního balíčku osobní zkušenost nemám

Já ano.

balíček má v distribuci správce jednoho nebo žádného

V nadšeneckých distribucích tomu tak bohužel je. Očividně je mezi linuxáky málo lidí ochotných něco dělat. To je asi důvod, proč existují distribuce jako CentOS nebo Scientific Linux nebo nakonec Ubuntu.

Tohle platí možná pro OpenSSL, neplatí to ani pro jádro nebo glibc

Přijďte se podívat příští jaro na den otevřených dveří do brněnského Red Hatu. Návštěvníci přicházejí s mylnou představou, že je to jeden hacker vedle druhého, co se hrabe v jádře.

24.6.2013 12:21 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Už to psal Petr, je to trochu shrnu:

  • Obfuskovaný JS nelze považovat za zdrojový kód.
  • Ve webových aplikacích splývají data a spustitelný kód – data se neustále mění, nemůžeš je pořád znova a znova kontrolovat, aplikace by byla nepoužitelná. Spustitelný kód by to kontrolovat chtělo, ale nikdy nevíš, zda ti ho web nepodstrčí uvnitř měnících se dat.
  • I ten spustitelný kód se mění na webu příliš často, aby ho šlo efektivně kontrolovat (a nezabilo to použitelnost aplikace), mnohdy se i liší pro prohlížeče, uživatele, státy… Stačí se podívat jak často Google a jiné podobné firmy mění SSL certifikáty – kvůli tomu je jejich kontrola dost problematická, na uživatele neustále vyskakují nějaká varovná okna, až nakonec kontroly vypne… s JavaScriptem by to bylo podobné, ale ještě o dost horší.
22.6.2013 15:24 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Distribuce distribuce už ti byla vysvětlena. Já dodám, že na citlivé programy, zrovna kryptografické knihovny, se běžně dělají certifikace, které zahrnují čtení zdrojáků.
20.6.2013 15:47 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ne, správným řešením je slušná integrace klientského PKI do prohlížečů (a evoluce TPM do něčeho, co může fungovat jako trvale zastrčená smartkarta).
20.6.2013 15:59 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
A jak bys třeba podepsal takovou banalitu, jako komentář na tomto webu? A jak bys ho před podepsáním zobrazil uživateli, aby si mohl zkontrolovat, že podepisuje skutečně to, co podepsat chce?
20.6.2013 16:49 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Relativně rychle implementovatelná možnost (změny jen v prohlížeči): součástí JS API prohlížeče by byla funkce, které by se předala data (xhtml + css: pro opakovatelnou prezentaci a zároveň rozšiřitelnost) k podepsání. Prohlížeč by data znovu zobrazil, dal na výběr klíč, po odsouhlasení uživatelem podepsal a vrátil zpět.

Systémovější možnost: v systému by běžel démon se speciálními právy, který by se kompletně staral o správu soukromých klíčů. Aplikace by pak data předala spolu s mime typem tomuto démonovi, ten by si zavolal prohlížecí program pro dotyčný mime typ, zobrazil data uživateli atd.

Jinak je to míněno jen jako api pro webové stránky - pokud stránka podpis nebude vyžadovat, jůzr by o něm prakticky neměl vědět. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJRwxY7AAoJELElzQAiwz4kF0IP/3GxwrRUTu6h9XfsEkTZVimM X2BN6QzEYFJ9dryU3I/DGcW56aNmAuwjndM9qtK4hp+7gJjgHqgJhn6JEU5DF5te 54/DnxrI25TOLIXE3bFFntkcrd4ZbTYl/h7yvQYf/M8Y+ORVL3ha1Pki4yUJ9ykn N2+h3su3r+kIcBNKiEG+23H3R6AJL3Ah5MxDMBbvu6ZDPDGDGf4FjMLXnXDICkRA UD/fHkUOKegQ5SWA8OkDW0aTmzW9g41Va/4+mzRbsYYoK3G+YtuawboiigZW+IG6 onrx87X6VmvKAm3UksikqkyF/0pcE8ZKUPrdVQHT0DEOchrxZiKVD4xsXs7y7UHV pwHi16tUUlOrBkFCLpT2dHheRiD5mTbkjnfCJbm+xzmn7hJi9PFn5s26ddlUUfjV bolzaS3+hhNEbKPdAjNu88/XtJp+fjfi9ER9ZX5UK0ZqrMvdjhqaYndGAHfg8Xtg GBmp9dcQu1PTSuGPn1U1V8xVkL50E1JhjLe3rdy23Qni6sXsPwXW18quC/xUG4ol TB9ex9GQ6TqZE33p4gpXEZmDERQ+2joARRFV6tX1SaFbjKfIffAcZMJ/llqhLin0 1/1TG+MRKVIpBakBFlZiZ+rdoGwGUMTYlYbSJt86BDb4mqdZ19Q+xBwQHQmemDHi xbCN1EOZwerf85xg0HZY =LVGu -----END PGP SIGNATURE-----

;-)
20.6.2013 17:11 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
data (xhtml + css: pro opakovatelnou prezentaci a zároveň rozšiřitelnost) k podepsání.
A o tom to je :-) Teď už „jen“ zbývá standardizovat tento formát dat a definovat API (pár metod).

A otázka je, jestli by to mělo být XHTML (+CSS). XHTML je stále hodně zaměřené na prezentaci informace, ne až tolik na sémantiku. Bylo by potřeba podporovat další jmenné prostory, aby ta data mohly mít nějakou strukturu a strojově čitelný význam (a nebyla to zprasenina). To už by bylo lepší, kdyby to bylo obecné XML a k němu XSLT generující nějakou podmnožinu XHTML (+CSS). Uživatel by viděl vygenerované XHTML, to by si zkontroloval a podepsal by vstupní XML dokument a XSLT šablonu (ty by si mohl zkontrolovat volitelně).
21.6.2013 10:08 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
XHTML je stále hodně zaměřené na prezentaci informace, ne až tolik na sémantiku.
Což je v pořádku. Uživatel podepisuje to co vidí on - co si tam pro zjednodušení (strojovou čitelnost) přidá webový program je jen její problém ...
Bylo by potřeba podporovat další jmenné prostory
který je velmi jednoduše řešitelný právě jmennými prostory.

Pointa: podepisovaná data mají být statická a jednoznačná. XSLT je stejně jako JS turingovsky úplný jazyk, proto bych ho v takovém místě viděl jen velmi nerad.
21.6.2013 10:21 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Když podepíšeš data (XML) i program (XSLT), tak to jednoznačně určuje výstup (XHTML) i když i ten můžeš klidně taky podepsat.
21.6.2013 14:28 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
XSLT má parametry. A parametry lze předat z vnějšího prostředí. A to nemluvím o externím DTD.
21.6.2013 14:44 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Parametry by byly prázdné a externí DTD zakázané (stejně jako volání nestandardních funkcí).
20.6.2013 16:55 j
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Uplne jednoduse. Srv by predal prohlizeci to, co mas podepsat a ten by to klientovi zobrazil. V takovym prvku by nefungovalo zadny scriptovani, zadny skryvani, pokrocily stylovani ... A prohlizec by to pro jistotu moh vzit, a klientovi ulozit do archivu v podobe podepsane bitmapy.
20.6.2013 17:15 Bubak | skóre: 16 | blog: Čtvrtá cenová
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Hm, a kdo mi zaruci, ze ten prvek neni nafixlovanej a podvrzenej? Myslim, ze nejsem sam, kdo by necemu takovemu klic do paratu nedal...
... máš jen mrtvou kočku a poškrábanýho jezevčíka ...
20.6.2013 21:57 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
To jde zajistit bez problému pomocí modálního dialogu, javascript umožňuje vyskočit jen pár okýnek (alert, confirm), ale neumožňuje jejich stylování. A i kdyby, tak potvrzením falešného dialogu by přece neproběhlo šifrování, to až s potvrzením pravého (nemodifikovatelného -> dělal by ho prohlížeč, ne html + js + css) dialogu ;-).
Baník pyčo!
mirec avatar 21.6.2013 18:56 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Občas to nie je potrebné.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
20.6.2013 21:58 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
+1
Baník pyčo!
20.6.2013 12:09 mmm
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
To je lež, alternativou je zcela standardní JavaScript, který je v každém prohlížeči.

Takový Mega zvládá JavaScriptem šifrovat a dešifrovat celé mnohagigabajtové soubory, vážně si myslíte, že podepisování by byl problém?
20.6.2013 12:16 mmm
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Tady třeba hotová JS knihovna:

jsrsasign - opensource free RSA signing/validation, ASN.1, PKCS#5/8 private key X.509 certificate and CRL library in pure JavaScript
20.6.2013 12:21 mmm
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Jinak s lokálními soubory se dá pomocí JavaScriptu už dlouho standardizovanou cestou pracovat, viz File API, např.:

Reading files in JavaScript using the File APIs
20.6.2013 12:58 Franta
Rozbalit Rozbalit vše JavaScript a podepisování v prohlížeči
  1. Já ale nechci dát nějakému pochybnému JavaScriptu* staženému bůhví odkud dát svůj soukromý klíč, aby si s ním mohl dělat, co chce (třeba odeslat na server a pak jím podepisovat cokoli mým jménem). Bylo by potřeba JS API pro práci s bezpečnostním zařízením (ať už HW token nebo SW úložiště – byla by tam abstrakce, takže by bylo jedno, co to je), které dostane hash/dokument k podepsání a vrátí podpis (ale nikdy neposkytne samotný klíč).
  2. Jak bude uživatel vědět, co přesně podepisuje? Co když HTML formulář/stránka zobrazuje něco jiného, než co JS nakonec nechá podepsat tvým klíčem?

*) tím nemyslím tu knihovnu, ale JS, který mi přijde z webu, který ji používá

stativ avatar 20.6.2013 14:02 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: JavaScript a podepisování v prohlížeči
A s pochyným java appletem problém nemáš?
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
20.6.2013 14:38 Franta
Rozbalit Rozbalit vše Re: JavaScript a podepisování v prohlížeči
Vždyť píšu, že by to měla být svobodná desktopová aplikace.

A vytvářená někým nezávislým – někým jiným, než kdo mě nabádá k jejímu použití (pojišťovny, banky, stát atd.). Takovou aplikaci by měl vyvinout např. někdo z akademické sféry, skupina odborníků + vše pod veřejnou kontrolou.

Java Applet (resp. jakákoli na míru psaná a od daného subjektu stahovaná aplikace) je stejně tak nevhodný jako ten JS. Jde o princip, že ten (resp. jeho SW), kdo po tobě chce nějaký podepsaný dokument, dostane tvůj soukromý klíč – to je zásadní chyba.
20.6.2013 13:30 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Nejde o samotné šifrování, ale o přístup k privátnímu klíči. Ten máte v méně bezpečném případě v souboru na disku – a k tomu se přes standardní JavaScript nedostanete (v HTML5 je na to rozšíření, ale to nepodporují všechny prohlížeče). V bezpečnějším případě máte privátní klíč na kartě nebo tokenu a softwarově se k němu vůbec nejde dostat. Pracuje se s ním přes ovladač, kterému pošlete data k zašifrování a vrátí se vám zašifrovaný výsledek. K tomu ovladači se přes JavaScript nedostanete už vůbec nijak.

Takže standardní JavaScript nestačí a tvrzení o Javě jako jediném prakticky použitelném nástroji není lež.
21.6.2013 16:18 mmm
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Většina bankovních řešení, které se běžně používají a vyžadují Javu, jí vyžadují právě a jen kvůli tomu podpisovému klíči v souboru na disku. Tohle JavaScript skutečně jednoduše nahradí. To že File API z HTML 5 nepodporují některé staré verze prohlížečů není argument, stejně by byl uživatel nucen nainstalovat Javu (a tím snížit bezpečnost), takhle je nucen nainstalovat jen novější verzi browseru (a tím bezpečnost naopak zvýšit).

Pokud někdo vyžaduje řešení s bezpečnostními klíči na čipové kartě (které samozřejmě je bezpečnější, to nerozporuji), holt se musí s Javou smířit. Ale naprostá většina toto řešení nepoužívá a není tak důvod proč by měli být nuceni instalovat skrz na skrz děravou Javu.
21.6.2013 16:58 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Tohle JavaScript skutečně jednoduše nahradí.
Možná by stálo za to se při tom nahrazování na chvíli zastavit a zamyslet se, jaký má tohle „řešení“ smysl. Kryptografie při takovém použití nemá smysl a stejně dobře by posloužilo jméno a heslo nebo libovolný soubor (plnící funkci dlouhého hesla), který bych jen přiložil k odesílaným datům. Efekt by byl stejný.
21.6.2013 17:04 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
P.S. aneb až se s bankou budeš někdy hádat jestli jsi nějaký platební příkaz zadal nebo ne, tohle je úplně na nic. Banka ti mohla soukromý klíč kdykoli v minulosti ukrást a ten příkaz jím teď podepsat. Nikdo už nezjistí, jestli se to stalo nebo ne, jestli příkaz podepsala banka nebo ty. Je to na nic a nemá to o nic vyšší vypovídací hodnotu než když si banka zaloguje do databáze, že ses tehdy a tehdy přihlásil správným jménem a heslem a zadal určitý příkaz.

Funkční by naopak bylo, kdybys měl soukromý klíč, který nemusíš nikdy nikomu dalšímu dát, příkaz jím podepíšeš pomocí softwaru, který sis sám vybral a bance předáš pouze příkaz s podpisem.
21.6.2013 23:53 Filip Jirsák
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
File API je reálně v prohlížečích dostupné pár měsíců. Java bývala v prohlížečích běžně dostupná, bývala bezúdržbová a bezpečná. Elektronické bankovnictví není aplikace, která se bude každých pár měsíců komplet předělávat podle toho, jaké jsou zrovna módní trendy u webových prohlížečů. Navíc by to byla další komplikace pro uživatele -- pokud máte certifikát v souboru, použijte tohle, pokud na kartě, použijte něco jiného...

Skrz naskrz děravá Java byla otázka několika dnů na jaře, než Oracle vydal záplatu. Ty dnešní opravy pokud vím opravují bezpečnostní díry v Javě, ale ne v zavaděči appletů/JNLP. To znamená, že i s tou děravou Javou by uživatel musel odsouhlasit minimálně spuštění appletu, ne-li zvýšená oprávnění. To znamená, že pouze nainstalovaná Java není nebezpečná, bezpečnostní díru by mohla zneužívat až ta spuštěná bankovní aplikace -- která ale stejně tak může zneužít to File API.
Jendа avatar 23.6.2013 17:42 Jendа | skóre: 76 | blog: Jenda | JO70FB
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Sakra, flame, který jsem prošvihl!

Mohl byste prosím popsat nějaký attack vector, kterému podepisování pomocí appletu dodaného službou zabrání?

Diskuzní zkratka: Při posledním flame s vámi na toto téma jste nadhodil:
  • že by se musela spiknout skupina zaměstnanců, která dělá applet, a která dělá webové rozhraní
  • že uživatel může podvržený applet dokázat
Na první jsem odpověděl, že applety nedělám, ale myslím si, že applet může posílat HTTP požadavky v kontextu stránky, ve které je spuštěn; na druhé, že uživatel by si musel všechny verze bankovních appletů ukládat a v případě problémů zajistit soudní zkoumání několikamegového souboru.

Na tyto argumenty jste již neodpověděl, proto jsem problematiku považoval za vyřízenou. Teď to tu vidím znovu - můžete mě prosím seznámit se změnou situace?
Jendа avatar 23.6.2013 17:50 Jendа | skóre: 76 | blog: Jenda | JO70FB
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
xkucf03 avatar 23.6.2013 18:04 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc

Ještě než se rozjede další kolo flamu, tak bych rád poznamenal, že je potřeba rozlišovat dva případy:

  • JS aplikace stažená společně s webem má přístup k soukromému klíči a sama provádí šifrování nebo podepisování
  • klíče jsou uložené na bezpečném místě a JS aplikace k nim nemá přístup – jen volá nějaké funkce prohlížeče

První případ je tragický a kontraproduktivní (falešný pocit bezpečí), kryptografie je zde zcela zbytečná a zavádějící a soukromý klíč plní jen roli jakéhosi dlouhého hesla.

Druhý případ by mohl být užitečný, pokud by ho někdo standardizoval a napsal potřebné nástroje – je to jen otázka vhodného API a GUI.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.6.2013 13:41 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Ake je len v mode pindat na bezpecnost javy, ze je to derave a co ja viem co ... Ale vidite, ze sa s tym aspon nieco robi a vychadzaju desiatky oprav a patchov, zda sa mi, ze to zacalo pred nejakym casom, ze sa do toho Oracle tak obul a cisti to ... Co to maju nechat tak? Nerobi sa nic -> zle. Opravuju to, este horsie ...
20.6.2013 13:59 washeck | skóre: 4
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
V první řadě by stačilo, aby ke každé aktualizaci (pro Windows) nepřibalovali malware (konkrétně Ask Toolbar). Je tam sice checkbox, že ho nechceš, ale 1) při rychlé aktualizaci to snadno přehlédneš 2) minule u mě kvůli nějaké chybě tato část dialogu nebyla zobrazena a odškrtnout jsem to nemohl. Odstranit tu sračku ze všech prohlížečů je práce na zbytek dne. Doufám, že java se rychle odebere na stejnou cestu jako flash.
20.6.2013 14:12 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
a aku mas alternativu? JVM tu s nami bude este velmi dlho v roznych podobach, ty by si asi zapichol Javu hned aj so Scalou, Groovy, Closure ... zachvilu sa bude tlacit Ceylon atd. Ja nehovorim, ze Java je nebesky jazyk, ale predstava, "ze java se rychle odebere" je ... mylna?
20.6.2013 14:31 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Je to samozřejmě pitomost. Jestli se někomu nelíbí práce Oraclu, tak může Javu klidně převzít a dělat lépe – je to svobodný software (na rozdíl od sraček typu Flash, Silverlight apod.) a otevřená platforma.
20.6.2013 14:53 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
:) no samozrejme, ako napriklad OpenJDK? Neviem ... ja sa na OpenJDK pozeram ako na Javu druhej kategorie, ked je "bordel" v Oracle Jave, potom si velmi neviem prestavit, co to musi byt v OpenJDK ... Alebo myslis este niekoho uplne noveho?
20.6.2013 15:52 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
ja sa na OpenJDK pozeram ako na Javu druhej kategorie
A to proč?
20.6.2013 16:21 bbbb
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
skus si par minut o oracle vs openjdk pogooglit a uvidis aj sam ... ludia mali s openjdk problemy, IDE na tom islo pomalsie, fonty v openjdk bola hroza ... ja viem ze openjdk je referencna implementacia ale ja asi verim viac oracle jak open source (ano, ukrizujte ma za to :D)
20.6.2013 15:14 washeck | skóre: 4
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Teoreticky ano, ale v praxi většina aplikací, na které jsem narazil, vyžadovala nejen oficiální Javu, ale někdy i konkrétní verzi (viz též Maxův komentář). Nevěřím, že rozumně použitelná alternativní reimplementace něčeho tak rozsáhlého v dohledné době vznikne a proto spíš doufám v postupný útlum celé platformy.
20.6.2013 15:21 Franta
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Proč by proboha měla vznikat alternativní reimplementace, když máš od všeho zdrojáky a rozumnou licenci?? S útlumem běž do háje, nevíš, o čem mluvíš.
20.6.2013 16:36 washeck | skóre: 4
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Máš pravdu, že o Javě moc nevím, nezajímá mě. Na klientovi jsem java aplet neviděl už hodně dlouho (v tom spatřuju ten útlum) a na serveru potřebuju jedinou javovou aplikaci a to Geoserver. A ten, když jsem naposledy (cca 2 roky zpátky) zkoumal, uváděl, že s OpenJDK nefunguje. Teď jsem si dohledal, že šlo o chybu v dokumentaci (http://jira.codehaus.org/browse/GEOS-4365), ale na druhou stranu, když se v tom nevyznají ani javisti, necítím to jako zásadní neznalost.
20.6.2013 16:24 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Odstranit tu sračku ze všech prohlížečů je práce na zbytek dne.
Tohle jsem tu zahlédl už dřív - on u toho už nefunguje odinstalátor? Mně zatím vždycky, když jsem na tuhle mrchu u někoho narazil, stačilo otevřít v Ovládacích panelech panel pro odebrání programů a ty dvě položky týkající se Ask Toolbaru prostě odinstalovat...
20.6.2013 16:47 washeck | skóre: 4
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Plus po odinstalování projít všechny prohlížeče a změnit home page, odebrat vyhledávací add-on a nastavit zpátky Google (návod). Prostě ideální způsob, jak propagovat javu jako důvěryhodnou platformu.
20.6.2013 18:18 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
No nevím, nevybavuju si, že bych po odinstalování musel měnit homepage a vyhledávání, ale na druhou stranu dělal jsem to jen párkrát a už je to nějaká doba, takže ruku do ohně bych za to nedal. Tak jako tak pod pojmem "práce na zbytek dne" si představuju něco jiného, já to měl na pár kliknutí myši.

Nicméně souhlasím s tím, že ten šmejd nemá v instalaci Javy co dělat a Oraclu asi šibe, když to přibaluje (a navíc takhle debilním způsobem)...
Max avatar 20.6.2013 14:05 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Java SE 7u25 a bezpečnostní chyba v Javadoc
Jojo, už jsme dostali maila od Němců, abychom na javu 7u25 neaktualizovali, že v tom nejede jejich webová aplikace. Heh.
Zdar Max
Měl jsem sen ... :(

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.