OpenSSL 1.0.2g a 1.0.1s - DROWN (diskuse)

[hmmm]

Prijde mi, ze lide co ty knihovny pisou nejsou dostatecne kompetentni. Za tak dlouhou dobu by uz ty algoritmy mohly fungovat bezpecne. Nebo je tam delaji schvalne?

[Hans1024]

Lidi, co implementuji ty klicove protokoly asi povetsinou jsou kompetentni, i kdyz i tak je to vec, u ktere je snadne udelat chybu. Lidi, co kolem toho nabaluji dalsi veci a lidi co spravuji OpenSSL asi uz tolik kompetentni nebudou. V LibreSSL uz davno neni SSLv2. Zato vyvojari OpenSSL se az po teto nadherne chybe rozhodli, ze SSLv2 v defaultu vypnou (nikoli odstrani, protoze co kdyby nekdo potreboval provozovat nebezpecne zabezpeceni).

[Conscript89]

Ano, protoze nekdo muze provozovat third party aplikaci ktera bez SSLv2 nefunguje a tak potrebuje server co mu umozni komunikaci s SSLv2. Co se tyce bezpecnosti, tak takovou aplikaci potom jde protunelovat bezpecnejsim kanalem a vsechno je v poradku.
Vypnuti ve vychozim stavu, ale zachovani mi prijde naprosto v poradku a jako seriozni pristup.

[Hans1024]

Tak to je otazka, jestli chce OpenSSL byt knihovnou, ktera zabezpecuje komunikaci, nebo knihovnou hacku pro zprovoznovani proprietarnich humusu.

[Conscript89]

Jak se to vylucuje s funkcionalitou ktera je vypnuta a musi byt explicitne zapnuta?

[Hans1024]

Rekl bych, ze je to jenom symptom toho, ze se projekt OpenSSL nehodla zamerit na jednu vec, kterou bude delat poradne. Neni zrejme, ze neni moc dobry napad, aby jedna skupina lidi spravovala ve stejnem repozitari zaroven kriticky bezpecnostni SW a hromadu hacku? Tenhle konkretni se mozna zda sam o sobe neskodny. Jejich vlastni reimplementace mallocu uz takova sranda neni.

[Conscript89]

Bavime se o mallocu nebo o podpore protokolu?

[Hans1024]

Bavime se o tom, ze ty veci souvisi a reflektuji specificke chovani projektu. Pristupem, "nechame to tam, ale vypneme to" dojdes postupne k neprehlednemu vysledku, ktery bude plny ifdefu. Pridelavas si praci a komplikujes zjednodusovani kodu. Zvysujes sanci, ze ti neco proklouzne.

[Odin1918]

Jiste. Ale pokud to, na cem zavisi urcita podnikova aplikace, ktera na tom s ohledem na zivotni cyklus zaviset bude roky, vypnes, pak docilis jen toho, ze software nebude aktualizovan vubec.

[Hans1024]

A proc by me mel vubec zajimat osud te podnikove aplikace?

[chrono]

To tvrdíš, že SSLv2 využívajú len podnikové aplikácie?

[Hans1024]

Netvrdim, tim argumentuji oni. Jake dalsi hruzy to teda pouzivaji?

[Odin1918]

Za prve nejde jen o podnikove aplikace, ale i o ostatni. Kazdopadne i u tebe predpokladam, ze chces, aby byl svobodny software pouzivan a bran v uvahu. Je sice fajn, ze neco bude absolutne technologicky a ideologicky ciste (z tveho pohledu), ale problem bude, ze to nebude pouzivane.

[Hans1024]

Co se tyce nejakeho prosazovani svobodneho SW, myslim ze tlacit to pres funkcionalitu a lakat na ni korporace nema dlouhodobe moc smysl. Kdyz se nejaky kousek svobodneho SW prosadi jenom kvuli svoji bohate funkcionalite, tak za chvili muze prijit proprietarni SW, ktery bude lepsi, nahradi ho, a jsme tam, kde jsme byli. Jenom kdyz jsou si lidi vedomi vyhod svobodneho SW a na jejich zaklade ho preferuji, bude ten pozitivni efekt dlouhodobejsi.

Nedelam si iluze, ze by se timle lidi zacali masove zabyvat, a pokud na me jejich zarizeni nesmiruji a nijak mi neublizuji tak mi zas tolik nezalezi co na nich bezi. Argumenty jim samozrejme rad predlozim, ale podporu zastaraleho kryptografickeho protokolu mezi ne s dovolenim neuvedu.

[Pev]

Bavime se o tom, ze ty veci souvisi a reflektuji specificke chovani projektu. Pristupem, "nechame to tam, ale vypneme to" dojdes postupne k neprehlednemu vysledku, ktery bude plny ifdefu. Pridelavas si praci a komplikujes zjednodusovani kodu. Zvysujes sanci, ze ti neco proklouzne.

Já v tom též nevidím problém - backward compatibility (u knihoven i obecně) je důležitá věc.

[Hans1024]

Ja chapu vyznam zpetne kompatibility, ale myslim, ze podelavat kvuli tomu bezpecnost je blby napad. Ja nemuzu za to, ze kryptografie se vyviji prilis rychle na nejake korporatni molochy. Kryptografie neni jako stary software, ktery odhodlanim maintaineru zustane funkcni po desetileti. Kryptograficka metoda proste prestane byt bezpecna a nikdo s tim nic neudela. Ze strany neprizpusobivych korporaci (to nastesti nejsou vsechny) je to nekompetence a podcenovani problemu. Jednou tenhle pristup nekoho zabije.

[Chulda]

Jak je zpětnou kompatibilitou podělaná bezpečnost? Hrozí mi použitím správné verze nebezpečí? Pokud ne, tak co je podělané?

Je použitím openssh, který podporuje v1, podělaná bezpečnost?? Zabilo to někoho?

BTW, velké korporace s tím až takový problém nemají, jako naopak ty malé. Nemají dost peněz vyhazovat funkční věci z okna je proto, že není teoreticky tiptop.

[Jendа]

Jak je zpětnou kompatibilitou podělaná bezpečnost? Hrozí mi použitím správné verze nebezpečí?

Podle zprávičky, pod kterou diskutujeme, zjevně ano.

[Hans1024]

Nemají dost peněz vyhazovat funkční věci z okna je proto, že není teoreticky tiptop.

Pochopte, ze kryptografie, ktera "neni teoreticky tiptop", nefunguje.

[Conscript89]

A ktera dnes "je teoreticky tiptop" v realnym prostredi?

[Hans1024]

"teoreticky tiptop" je zrejme pejorativni oznaceni, proto jsem ho taky dal do uvozovek. Pokud je teda otazka myslena na funkcni ekvivalent SSLv2, serioznim kandidatem jsou nejnovejsi verze TLS s rozumnou sifrou.

[Jendа]

To je možné, ale někdy to nevadí, nebo třeba to zařízení nevlastním, nejsou na nové peníze atd., takže s tím nemohu nic udělat.

[Chulda]

pochopte, že pokud je to např. v izolovaném prostředí, tak je to úplně buřt. Teoreticky to není OK, prakticky ano.

[Hans1024]

Tak proc se v tom izolovanem prostredi pouziva sifrovani, kdyz neni potreba? A problemem neni nasazovani v izolovanem prostredi, ale to, ze udrzovanim zastaralych featur se ohrozuje bezpecnost vsech ostatnich, kteri tu knihovnu pouzivaji.

[Odin1918]

ohrozuje bezpecnost vsech ostatnich, kteri tu knihovnu pouzivaji.

To obecne neni pravda a tvuj vyrok by platil jen, pokud by dotycny pouzival ony nebezpecne featury. Cemuz se da zamezit tim, ze v defaultu budou vypnuty a jejich nebezpecnost bude dostatecne komunikovana. Pak lze predpokladat, ze to pouzije pouze ten, kdo vi, co dela. Kazdopadne to dotycny pouzije na vlastni nebezpeci.

[Hans1024]

Udrzovani zastaralych featur OpenSSL ma negativni vliv na bezpecnost i kdyz uzivatel ty featury nepouziva. To jsem rikal uz na zacatku diskuse. Ten ponechany kod pridelava praci a komplikuje refaktorovani a zjednodusovani knihovny.

[Odin1918]

Jiste. Ponechany kod s sebou nese jiste naklady, ale uzivatel by mel byt prednejsi. Vim, ze vy byste radeji hodil firemni uzivatele pres palubu, ale nastesti se podle vas svet neridi.

[Hans1024]

Ja nikoho nechci hazet pres palubu, jenom kvuli nim nechci snizovat bezpecnost ostatnich. Kdyz nejaky neschopny programator pouzije prehistoricky sifrovaci protokol tam, kde neni potreba, tak proc by na to meli vsichni doplacet zhorsenou bezpecnosti? Neschopne firmy jsou udrzovany v iluzi, kde jim vsechno funguje, a na jejich neschopnost kolektivne doplati ostatni - takhle ma fungovat trh?

[Jendа]

Tato zpravicka je ale o tom, ze he takova feature muze aktivovat omylem.

[Michal Kubeček]

K tomu už jsem se taky vyjadřoval.

[Odin1918]

+1

[Jendа]

Samozřejmě, že primárním problémem je, že někdo použil openssl tak, že se střelil do nohy. Protože ale zjevně nedokážeme zařídit, aby ho lidé používali správně, myslím, že další možné řešení je toto. Mimochodem není to jediný projekt, kterému se tohle stalo, například před měsícem tu bylo vzdálené čtení paměti SSH klienta přesně z tohoto důvodu.

[Odin1918]

Kdyz nekdo pouzije netcat tak, ze jej necha naslouchat na nejakem portu a to, co obdrzi od klienta, bude rovnou spoustet, jiste je to take streleni do nohy. Zakazeme netcat, aby se timto nebezpecnym programem nekdo neohrozil?

[Hans1024]

Zajimave je, ze jses to ty, kdo tady argumentuje pro to, aby ta knihovna resila dusledky neschopnosti programatoru, co ji pouzivaji. Kdyz se to dela kvuli prizni korporaci, tak je to OK, ale kdyz se to dela kvuli bezpecnosti, tak je to spatne?

[Jendа]

Když by netcat byl komplexní prehistorický software s podobnými funkcemi ukrytými hluboko v nastavení, určitě by se mi nelíbilo, aby taková věc šla drobnou chybou nastavení aktivovat.

Kdyby openssl mělo pověst dobře zdokumentované a snadno použitelné knihovny bez bohaté historie podobných průserů, asi by mi nevadilo, kdyby se tam SSLv1 s integritou zajišťovanou pomocí CRC32 a šifrou ROT13 nechalo.

[Chulda]

pletete si příčinu a následek.

Dříve to mohlo být šifrované, ale po problémech s bezpečností se mohlo najít jiné řešení zajišťující bezpečnost. Jenže původní bazmek jinou než obstarožně šifrovanou komunikaci neumí. Koupit nový bazmek kvůli novějšímu šifrování je ekonomický nesmysl.

Opravdu je takový scénář nad možnosti vaší představivosti? Protože tohle je to, s čím se se několikrát setkal během své praxe a to je to, co se vám snaží ostatní vysvětlit.

[Hans1024]

Ja si to dokazu predstavit, ale stale si nemyslim, ze by kvuli tomu bazmeku mela byt zhorsena bezpecnost ostatnich. Navic nekonecnou podporou funkcnosti nejakeho bazmeku odstranujete ekonomicke tlaky na vyrobce toho bazmeku, ktere by ho mohly donutit udelat kvalitnejsi nebo updatovatelnejsi bazmek.

[Odin1918]

Navic nekonecnou podporou funkcnosti nejakeho bazmeku odstranujete ekonomicke tlaky na vyrobce toho bazmeku, ktere by ho mohly donutit udelat kvalitnejsi nebo updatovatelnejsi bazmek.

Ale svobody software zde neni kvuli tomu, aby vytvarel na sve korporatni uzivatele nejake ekonomicke tlaky. Svobodny software je zde od toho, aby jej uzivatele mohli pouzivat a to i kdyz se to nejakemu Hansimu nelibi.

[Hans1024]

Ja nechci aby ta knihovna vytvarela ekonomicke tlaky, ja jenom chci aby neodstranovala prirozene ekonomicke tlaky, diky nimz jsou firmy zodpovedne za svou nekompetenci.

[Odin1918]

Nastesti se svet netoci podle toho, co chces ty.

zodpovedne za svou nekompetenci.

Nemusi se jednat o nekompetenci. U aplikace, ktera ma planovany zivotni cyklus treba 10 - 15 let, nemuzes zarucit, ze pouzite technologie nebudou za pet let od vzniku aplikace oznaceny za nebezpecne.

Proc asi v distribucich zustava stary a osklivy ifconfig, kdyz je obecne uz nejmene deset let povazovan za zastaraly a zly? Proc asi? Duvodem je zpetna kompatibilita. A to same plati i v pripade openssl. Je spatne hodit sve uzivatele pres palubu s tim, ze protokol, na kterem je zavisly jejich software, jednoduse prestavame podporovat, protoze se nam prestal libit. Osobne schvaluji medializaci onech problemu a klidne, at je to v defaultu vypnute, ale davat to pryc mi prijde opravdu spatne a je to krok proti uzivatelum.

[Hans1024]

Ale tady nejde o to, ze by se mi ten protokol "prestal libit", tady jde o to, ze uz neplni svou funkci a jeho dalsi udrzovani zhorsuje stav celeho projektu. Je trivialni v tom zbastlenem firemnim cemsi udelat moznost nesifrovane komunikace. Nechapu pristup, kdy prestat podporovat prasarny a hacky nekterych uzivatelu je spatne, zatimco zhorsovat bezpecnost vsem uzivatelum je OK.

[Chulda]

moment, zprávička je o tom, že některý SW stále použivá SSLv2 a skrz něj lze vést na něj útok.

Kde je ale, že podpora staršího protokolu v knihovně (ne v SW!) snižuje bezpečnost nového?

Tedy že implementace starší verze protokolu znemožňuje bezchybnou implementaci novějšího protokolu? A bavíme se o knihovně, ne o tom, že nějaký SW je špatně nakonfigurovaný.

[Hans1024]

Zpravicka je mimo jine o tom, ze se software donuti pouzit SSLv2 tam, kde to nikdo nezamyslel.

O vlivu nadbytecneho kodu na bezpecnost uz jsem tu psal nekolikrat a prestoze to nikdo nerozporoval, porad se nekdo dokola pta, jako by tu diskusi necetl. Je zjevne, ze udrzovani toho kodu pridelava praci a komplikuje refaktorovani a zjednodusovani.

[Chulda]

No, ale já tu podporu potřebuji na straně klienta, který si bez toho s bazmekem ani neškrtne. A používání obstarožního klienta připojeného k síti tu bezpečnost zhoršuje ještě více, ne?

Teda, kde to žijete, že si myslíte, jak zákazníci jsou ochotni utrácet milióny kvůli minoritnímu SW problému, který má navíc obstojné náhradní řešení.

BTW, ten výrobce třeba už neexistuje nebo ukončil podporu, takže o jakém tlaku to mluvíte? (to jsou mé zkušenosti z praxe a nikoli akademický příklad)

[Hans1024]

Podle me byste si mel problemy se svymi zakazniky a s bazmeky resit v jinem projektu a neocekavat od knihovny, ze je vyresi na ukor bezpecnosti ostatnich. Je idiocie resit hacky pro kompatibilitu v knihovne, ktera zabezpecuje znacnou cast Internetu.

Vztekli zakaznici nadavajici na nefunkcni vyrobky samozrejme neovlivni jenom chovani vyrobce, ale i konkurence.

[Chulda]

To jsme se nepochopili - to nejsou mé problémy, ale problémy různých firem, o kterých vím od jejich zaměstnanců, mých kamarádů.

Podpora starší verze protokolu je hack?

Opět nepochopení - ti uživatelé jsou spokojení s tím, jak jim to funguje. Nespokojení jsou s tím, že neexistuje úplná náhrada a/nebo že je výrazně dražší než stávající řešení. Za takové situace nebudou řešit náhradu jen kvůli akademickému purismu.

[Odin1918]

+1000

[Hans1024]

Ten zabezpecovaci protokol uz neplni svou funkci - zabezpeceni. A argumenty, proc ho tam nechat jsou, aby nekde neprestal fungovat nejaky humus, ktery je bud proprietarni, nebo u nej nekdo nechce zmenit par radku kodu. Je to hack.

Nevim, proc porad resite, jestli nejaci uzivatele budou nebo nebudou resit nahradu, podle mne je to irelevantni. Kdyz tem uzivatelum to SSLv2 skvele funguje, tak zrejme nepotrebujou zabezpeceni. Kdyz chteji provozovat proprietarni bazmeky s nefunkcnim zabezpecenim, proc si na to neudelaji nejakou ImaginarySSL? Oni misto toho chteji, aby jim to nefunkcni zabezpeceni poskytla knihovna, od ktere ostatni lidi ocekavaji funkcni zabezpeceni.

[Rezza]

A to je to krasne na open source - moznost udelat si fork, kdyz ma clovek vyrazne odlisny use case a pokud je tam alespon nejaky zajem, tak muze vykryt i ty mensi okrajove zajmy.

[R]

Presne tak. A nejde len o podporu na serveri. Ak mam server, co podporuje len SSLv2 a po upgrade klienta mi prestane fungovat pripojenie na server, tak dakujem pekne... A spravidla to nevypise ziadnu zmysluplnu chybu a v logoch nie je nic.

[Hans1024]

Pro komunikaci se serverem doporucuji pouzit enigmu. 20 let nebo 70 let zastaraly kryptograficky protokol, to zas tak velky rozdil neudela.

[Odin1918]

Doporucuji obcas vytahnout hlavu ven a rozhlednout se. V korporatni sfere je zivotni cyklus aplikaci typicky velmi dlouhy a je potreba podporovat i stare technologie, protoze je na nich zavisla spousta systemu. Pokud chce byt opensource software bran jako vazna alternativa, nesmi se na korporatni sferu vykaslat. Ja osobne jsem rad, ze se toto vetsinou nedeje. To vis, v korporatni sfere se nezahodi aplikace jenom kvuli tomu, ze nejaky Hansi drzkuje na internetu. :-P

[Hans1024]

Tak si holt OpenSSL musi vybrat, jestli chce delat realnou bezpecnost, nebo sluhu korporacim. Ale hosi od OpenSSL uz si asi davno vybrali, a proto tu mame LibreSSL.

S korporacemi opravdu nesoucitim a nehodlam si kvuli jejich neschopnosti nechat poslapavat bezpecnost. Korporace at se prizpusobi, nebo at chcipnou - tak to mas Odine rad, ne?

[Odin1918]

nebo sluhu korporacim

To neni o tom delat nejakeho sluhu. To je o tom udrzovat nejakou funkcionalitu a knihovnu aktualizovanou, dokud bezi zivotni cykly jiz existujicich aplikaci. Podobny pristup ma prece debian stable. Roky do nej nejsou pridavany nove funkce, ale bezpecnostni aktualizace pro nej vychazeji spoustu let. Je to perfektni reseni. Odstranit natvrdo funkcionalitu, na ktere zavisi existence spousty aplikaci, je chyba, ktera povede jen k nizsi oblibenosti dane knihovny.

S korporacemi opravdu nesoucitim a nehodlam si kvuli jejich neschopnosti nechat poslapavat bezpecnost.

To prave neni o poslapani bezpecnosti. Tim, ze funkcionalitu vyradis, docilis jen toho, ze se nebude aktulizovat vubec u existujicich produktu, a do budoucna nebude svobodny software vztah v uvahu pri dalsim vyvoji, protoze na nej neni spolehnuti.

Korporace at se prizpusobi, nebo at chcipnou - tak to mas Odine rad, ne?

Oni se prizpusobi, to se neboj, ale skoda bude, kdyz na tvuj pristup zacne doplacet svobodny software. Tvym pristupem docilime software, ktery bude sice ideologicky kristalove cisty a bezpecny, ale nebude jej nikdo pouzivat. Btw zkus se prosim podivat, kolik tech zlych firem prispiva napr. do kernelu. Uz jen toto by mohl byt padny duvod pro mirny soucit s korporatni sferou.

[Hans1024]

Me je ale opravdu jedno jaky software si korporace pouzivaji. O vetsinu jejich prispevku do svobodneho SW ani moc nestojim. Nektere jsou fajn, ale nezblaznil bych se bez nich. A ne vsechny korporace snad lpi na pouzivani SSLv2.

[Michal Kubeček]

…korporace… O vetsinu jejich prispevku do svobodneho SW ani moc nestojim.

V tom případě vám doporučuji přestat používat linuxové jádro, většinu jeho kódu totiž už nějaký pátek mají na svědomí právě ty zlé ošklivé korporace.

[Hans1024]

Vetsina jaderneho kodu opravdu neni potreba k pouzivani Linuxu.

A tahleta hra se zasluhama je stejne nesmyslna, jako u pro-copyrightove argumentace. Hitler ma zasluhy na obrovskem vedeckem pokroku v dusledku valky. Takze ted ty vedecke poznatky zahodime, protoze valku ani Hitlera jsme nechteli? Taky se mi zda, ze zbytecne podporujes jakousi predstavu nenahraditelnosti. Kdyz korporace neco uzitecneho udela, je zcestne tvrdit, ze kdyby to ta korporace neudelala, tak to neudela nikdy nikdo. Kdyz je po necem dostatecne velka poptavka, tak se najde nekdo, kdo to implementuje

Taky jsem netvrdil, ze vsechny korporace jsou zle a osklive. Jsou to proste entity, ktere se zpravidla snazi maximalizovat zisk, a zpusob, jakym to delaji, je v ruznych pripadech vyhodny nebo nevyhodny pro ruzne lidi.

[Michal Kubeček]

Vetsina jaderneho kodu opravdu neni potreba k pouzivani Linuxu.

Vhodně zvolená většina určitě. Ale opravdu věříte tomu, že lze totéž říct i o té většině, která byla dodána "korporacemi", tj. o té, o které prohlašujete, že o ni "ani moc nestojíte" a že byste se "bez nich nezbláznil"?

[Hans1024]

Ja nevim, co nechapete na definici slova "vetsina". Vetsinu kodu nepotrebuju = nepotrebuju ho vic, nez kolik ho potrebuju. Pripada mi zjevne, ze drtiva vetsina toho, cim korporace prispivaji pro mne nema vubec zadny vyznam - staci si zobrazit seznam commitu.

Mam pocit, ze tu resite nejake umele dilema ze bud musim podkurovat vsem korporcim, nebo neinteragovat s cimkoli na co kdy jakakoli korporace sahla. Ani jednu z tech dvou pozic nezastavam.

[Michal Kubeček]

Vetsinu kodu nepotrebuju = nepotrebuju ho vic, nez kolik ho potrebuju. Pripada mi zjevne, ze drtiva vetsina toho, cim korporace prispivaji pro mne nema vubec zadny vyznam

Jenže i z té části, kterou používáte, pochází většina od těch "korporací". Takže tvrdit, že o jejich příspěvky nestojíte, je buď zavírání očí před realitou nebo přímo lež.

Mam pocit, ze tu resite nejake umele dilema ze bud musim podkurovat vsem korporcim, nebo neinteragovat s cimkoli na co kdy jakakoli korporace sahla. Ani jednu z tech dvou pozic nezastavam.

Nejde mi o žádné podkuřování, ale o to, abyste uznal význam toho, čím přispěly a stále přispívají. Nebo ho aspoň přestal bagatelizovat.

[Hans1024]

Ja nic nebagatelizuju, ja jenom rikam, ze pro mne (a dost mozna i pro nektere jine uzivatele Linuxu) toho vetsina nema vyznam a ze kdyby to ty konkretni korporace nenapsaly tak to neznamena, ze to nenapise nikdy nikdo. To prece neznamena, ze chci, aby zadna korporace nikdy nic neprispela, nebo ze odmitam sahnout na jakykoli jejich prispevek. I kdyby cely projekt Linuxoveho jadra chcipnul (coz se asi nestane) nebo proste neexistoval, tak se z toho nezblaznim. Ale to prece neznamena, ze chci aby Linux chcipnul, nebo ze ho odmitam pouzivat.

Opravdu nechapu, o co vam porad jde.

[Pev]

Vetsina jaderneho kodu opravdu neni potreba k pouzivani Linuxu.

Hahaha Čím to nahradíte? kFreeBSD? (Hurd je nepoužitelný, pokud jste uživatelem *BSD, tak už tedy nepoužíváte Linux). Nebo snad používáte GNU Linux-libre a obejdete se bez většiny wifi (nesvobodný firmware), spousty audia a videa ovladačů?

A také doufám, že nepoužíváte žádný smart phone/tablet/cokoliv dalšího (ani open source android se neobejde bez proprietárních ovladačů a to je to nejsvobodnější volba ze všech smartphone; binární bloby jsou i v CyanogenModu) a většinu embedded zařízení. A samozřejmě, že máte nějaký wifi router s komplet svobodným firmware.

[Michal Kubeček]

O tom tady ale vůbec nebyla řeč. Nejde o nějaké closed source drivery nebo binární firmware, jde o to, že už nějaký ten rok většina normálního standardního GPL kódu vanilla jádra pochází od "korporací". A to se netýká zdaleka jen driverů (z nichž na konkrétním systému opravdu potřebujete jen malou část), ale i naprosto základních komponent, ať už jsou to filesystémy, storage, memory management, scheduler nebo třeba síťový stack. Takže pokud někdo, kdo používá Linux, nad "korporacemi" ohrnuje nos a tvrdí, že by se bez jejich příspěvků snadno obešel, znamená to, že má problém s vnímáním reality.

[Odin1918]

+1

[Hans1024]

Ja si myslim, ze neni treba hned korporacim co to zafinancovaly libat nohy a predpokladat, ze kdyby to neudelaly ony tak by to nikdy nikdo neudelal.

[Michal Kubeček]

V rozsahu, v jakém "korporace" přispívají do linuxového jádra, by to v současné době bylo jen velmi obtížně představitelné. Přinejmenším by to jeho vývoj velmi výrazně zbrzdilo.

A jen pro pořádek, celou dobu nemluvím o finančních příspěvcích (které jsou také nezanedbatelné), ale o kódu jako takovém.

[Hans1024]

Bylo by vtipne, kdyby se zpomalil vyvoj Linuxu kvuli prilis rychlemu vyvoji OpenSSL, pricemz "prilis rychly" znamena odstraneni 20 let zastaraleho protokolu.

Myslim, ze trpite falesnou predstavou, ze vsem korporacim musite podkurovat, jinak od nich nedostanete nikdy nic. Pokud vas opravdu trapi hypoteticke zpomaleni vyvoje, tak to je mi lito, me treba tempo vyvoje OpenBSD zas tolik netrapi, takze asi mame jine priority.

Pokud nad vami maji korporace takovou moc, ze kvuli tomu chcete zhorsovat bezpecnost ostatnich uzivatelu, pak je to smutne. Podle me je to taky dusledek toho, ze se svobodny SW neprosazuje pres uzivatele, ale pres ruzne ekonomicke vyhody a copyrightove pravnicke klicky.

[Michal Kubeček]

Pokud nad vami maji korporace takovou moc, ze kvuli tomu chcete zhorsovat bezpecnost ostatnich uzivatelu

To je ovšem jen vaše dezinterpretace.

[Hans1024]

Nechapu, co se snazite rict. Takze vam nevadi odstraneni SSLv2? Nebo vadi a zpochyvnujete bezpecnostni impakt ponechani SSLv2? Myslel jsem ze to uz jsme vyresili na zacatku diskuse.

[Michal Kubeček]

Mně konkrétně nevadí, ale chápu, že někomu jinému by úplné odstranění příslušného kódu přineslo nemalé problémy. Proto považuji způsob, jakým je to uděláno za rozumný kompromis: v defaultu podpora SSLv2 není, ale kdo ji opravdu potřebuje, může na vlastní nebezpečí SSLv2 používat dál.

[Hans1024]

Ale to neodstraneni ma prave bezpecnostni dopady, jinak by to nebyl kompromis.

[Rezza]

Jo, zrovna ted jsem lehce prochazel Bugzillou a nektere bugy si nedovedu predstavit, ze by sly resit jinak, nez ze se na to nazene kupa lidi. A ta kupa lidi se uz hur hleda mimo ty korporace. Samozrejme nerikam, ze to nejde.

[Pev]

O tom tady ale vůbec nebyla řeč. Nejde o nějaké closed source drivery nebo binární firmware, jde o to, že už nějaký ten rok většina normálního standardního GPL kódu vanilla jádra pochází od "korporací". A to se netýká zdaleka jen driverů (z nichž na konkrétním systému opravdu potřebujete jen malou část), ale i naprosto základních komponent, ať už jsou to filesystémy, storage, memory management, scheduler nebo třeba síťový stack. Takže pokud někdo, kdo používá Linux, nad "korporacemi" ohrnuje nos a tvrdí, že by se bez jejich příspěvků snadno obešel, znamená to, že má problém s vnímáním reality.

OK, ale

1) i ty binární bloby pocházejí od korporací

2) využívají frameworky standardního GPL kódu a bez něj nebudou fungovat. Takže nový HW holt vyžaduje nový kernel, to je prostě realita

[Hans1024]

No, bavili jsme se tu o korporacich, ktere prispivaji do Linuxu. Tj. o tech, na ktere muze mit vliv nejake podkurovani. Bloby jsou uplne separatni problem a korporace je budou produkovat bez ohledu na to, jestli je OpenSSL zpetne kompatibilni, nebo ne.

[Michal Kubeček]

To, čemu říkáte "podkuřování", je obyčejné braní ohledu na to, kdo software používá a jak. Některé projekty to tak dělají, jiné bohužel ne (z hlavy mne napadá třeba GIMP).

[Hans1024]

Me je jedno jak tomu chcete rikat, proste si nemyslim, ze by to melo byt na ukor bezpecnosti u projektu, jehoz cilem je bezpecnost.

[Hans1024]

Respektive to vypada, ze u tohoto projektu zas az tolik bezpecnost cilem neni, ale tvari se, ze to tak je. To je recept na prusvih.

[Michal Kubeček]

Není to na úkor bezpečnosti. To je jako kdybyste jen proto, že někdo špatně použil knihovní funkci, tvrdil, že bezpečnostním problémem je sama existence té funkce. Není. Problémem je to, že ji dotyčný špatně použil, ne to, že existuje. A tohle je úplně stejné; pokud někdo chybně umožnil použít SSLv2, přestože to bylo v rozporu s konfigurací, je problémem tato chyba, ne existence kódu implementujícího SSLv2.

[Hans1024]

Uz zde bylo nekolikrat zmineno, ze ten kod navic komplikuje zmeny a zjednoduseni kodu a pridelava praci.

[Michal Kubeček]

Vzdávám to, je to marné. Žijte si dál spokojeně ve svých vzdušných zámcích a ohrnujte povýšeně nos nad námi, kdo žijeme v reálném světě a řešíme problémy každodenního života v praxi, ne v idealizovaných snech.

[Hans1024]

Negativni vliv na bezpecnost je naprosto realny. Bezpecnost neni "problem kazdodenniho zivota v praxi"? Takze ty bugy v OpenSSL v tom "realnem svete" vlastne nejsou vubec zadny problem? Tak to preji mnoho zabavy s dalsimi kritickymi zranitelnostmi.

[Pev]

Negativni vliv na bezpecnost je naprosto realny. Bezpecnost neni "problem kazdodenniho zivota v praxi"? Takze ty bugy v OpenSSL v tom "realnem svete" vlastne nejsou vubec zadny problem? Tak to preji mnoho zabavy s dalsimi kritickymi zranitelnostmi.

Je vidět, že máte hodně času . A že se vyplatí číst původní (anglické) zdroje a diskuzemi na abclinuxu neztrácet čas .

[Hans1024]

Nechapu, proc bych mel nahrazovat neco, co nepotrebuju.

Nepouzivam zadny "smart phone/tablet/cokoliv", ale nechapu, jak to souvisi s tim, ze mam vetsinu korporaci u zadnice.

[Pev]

#69 .

[pc2005]

Takže ty chceš, aby se zachovávalo třeba i by design nebezpečné rozhraní, jen aby otevřenej software mohla používat nějaká firma, co si nedokáže/nechce updatovat svoji softwarovou výbavu?

[chrono]

Veľa open source projektov skončilo po zmene API, pretože sa nenašiel nikto, kto by ich upravil (a často aj v prípade, že mali veľa používateľov).

[Hans1024]

Kdyz nejaky projekt pouziva SSLv2, tak to znamena, ze se asi snazi delat neco, co by melo byt aspon trochu bezpecne (ostatne podle me by vsechno melo byt aspon trochu bezpecne) a jestli neni schopen prezit odstraneni podpory SSLv2, tak bud nema zadne vyvojare a nebo je totalne humusacky zbastleny, coz jsou jen duvody se tomu pouzivani vyhnout, protoze at mel delat cokoli, bezpecne to neni.

[Conscript89]

Napr. 10 let stare KVM (nevim o zadnem konkretnim modelu), ano, ono muze prece za odstraneni protokolu. Vzdyt ten hardware je nepouzitelny!!!

[Michal Kubeček]

Kdyz nejaky projekt pouziva SSLv2, tak to znamena, ze se asi snazi delat neco, co by melo byt aspon trochu bezpecne

Tak si představte scénář, kdy máte nějaké embedded zařízení, které lze vzdáleně ovládat jen přes HTTPS, ale protože je hodně staré, ovládá pouze SSLv2. U daného exempláře je to uživateli jedno, protože s ním stejně komunikuje jen přes přímo přípojený kabel, nikam jinam připojené není a celé se to odehrává v prostorách, kam kdyby se dostal někdo cizí, tak bezpečnost tohoto konkrétního zařízení bude naprosto zanedbatelný problém. Novější firmware neexistuje a nikdy existovat nebude.

Má ho podle vás uživatel vyhodit jen proto, že SSLv2 je přece nebezpečný protokol, áááno, i když je to v tomto konkrétním případě úplně jedno?

Nebo může jít třeba o klient-server aplikaci, kterou z různých důvodů nikdo přepisovat nechce a nebude, ale v daném nasazení stejně klient a server běží na jednom stroji. Nebo je ten SSL tunel stejně přenášen třeba přes IPsec. SSL (TLS) se často používá i tam, kde to vlastně vůbec není potřeba, ale autor si jen nechtěl zbytečně komplikovat život psaním dvou různých rozhraní pro bezpečná a nebezpečná spojení.

[Hans1024]

Me uprimne proprietarni shit moc nezajima, ale pokud si nekdo chce hrat s hackama na jeho sprovoznovani, tak to snad patri do nejake knihovny libhack, nebo ImaginarySSL, a nikoli do projektu, ktery zabezpecuje znacnou cast Internetu.

[Michal Kubeček]

Ty příklady, které jsem uváděl, vůbec nemusejí být proprietární. Ten firmware/software klidně může být open source, ale s ohledem na okolnosti není důvod zbytečně investovat čas a prostředky na jeho přepsání.

[Hans1024]

Takze kvuli neci kolosalni lenosti zhorsime bezpecnost uzivatelu Internetu. To jsou mi ale priority.

[pc2005]

Pokud změna API není zbrklá (například přepisy BlueZ, systemd) nebo náhlá, tak je to OK. O SSLv2 se ví roky, že je zastaralé a děravé.

[Odin1918]

O md5 se vi roky, ze je derave, ale pres to se stale bezne pouziva...

[pc2005]

Já ho pro bezpečnost šifrování nepoužívám, jedině jako o něco lepší kontrolu parity. A navíc jen proto, že md5sum se napíše rychleji než shaXXXsum, nemá podvarianty a používá ho okolní software. Takže stačí, aby byla podpora MD5 odstraněná a začnu používat něco bezpečnějšího.

Pokud napíšu šifrovací program, tak md5sum určitě nepoužiju.

[Rezza]

Njn, zkus poslat ISO do nejake firmy, ktera lisuje DVD se sha256sum a budou trvat na md5sum... Zase kluci releng md5sum odmitli vygenerovat. Jednou se je povedlo donutit, at stahnou neco z netu pro Windows, to bylo samozrejme rozbite. Tak jsme md5sum proste delali sami pres sha256sum overeni... Nektere lidi nezmenis :). Jako asi u toho ISO ta md5sum neni zas takovy problem, ale...

[Odin1918]

Ano, chci. Z ohleduplnosti k uzivatelum, kterym na tomto nebezpecnem protokolu funguji jiz existujici aplikace. Je treba si uvedomit, ze zivotni cyklus aplikace muze byt velmi dlouhy a ze dany protokol v dobe vzniku one aplikace treba nebyl povazovan za nebezpecny. Podle mne je dobre ony zranitelnosti medializovat, zminit v dokumentaci, atd. Take muze byt nebezpecny protokol defaultne vypnuty, ale je chyba jej odstranovat jen z duvodu toho, ze je povazovan za nebezpecny. V novem software jej nikdo nepouzije a stary software bude moci fungovat s aktualni verzi knihovny, kde mohou byt jine kriticke chyby opraveny.

[pc2005]

To se dá vyřešit vyjmutím té staré funkcionality do externí knihovny. Není dobrý nápad, aby datové struktury staré verze ohrožovaly datové struktury verze nové (zrovna OpenSSL kód nemá kdovíjak striktní).

[Conscript89]

To se dá vyřešit vyjmutím té staré funkcionality do externí knihovny. Není dobrý nápad, aby datové struktury staré verze ohrožovaly datové struktury verze nové (zrovna OpenSSL kód nemá kdovíjak striktní).

Konecne nejaka kloudna argumentace na kterou jsem ochoten pristoupit. Pokud tam takova provazanost existuje, tak souhlasim s tim, ze je to chyba.

[pc2005]

Tak podle objdumpu jsou třeba ssl2_ciphers i ssl3_ciphers jsou v jedné sekci (.data), takže kód pro jedno by měl být schopnej adresovat i to druhý (ale zas tak do exploit malware nevidím). V případě dvou knihoven se předpokládám obě načtou na jiné virtuální adresy (různé sekce, v ideálním OS by o sobě ani neměly vědět).

[chrono]

Problém ale nie je knižnica.

[Ruža Becelin]

Dalsi jmeno "s gulema"

BTW kolik aplikaci jeste dneska podporuje SSLv2 by default?

[Jendа]

BTW kolik aplikaci jeste dneska podporuje SSLv2 by default?

No podle popisu té chyby docela dost.

[Vfrdgjj]

Napriklad jedna z mojej byvalej firmy. Ta predavala za nieco ako 500 korun tusim do r. 97 miniaplikaciu, odvtedy to nikto nekompiloval, ale stovku ludi sa nepodarilo presvedcit o potrebe bezplatneho prechodu na novsiu verziu, takze je to skoro urcite podporovane este dnes.

[Jendа]

Další zajímavý popis.

Ach jo, a na tomhle stojí bezpečnost Internetu…