Vlákno názorů k článku Jak na OpenSSL 3 od Michal Kara - Prijde mi, ze Petr je tak trochu v...
-
Michal Kara (neregistrovaný)
Prijde mi, ze Petr je tak trochu v zajeti sve odbornosti. Kdyz budu chtit, aby si Pepa nemohl stahnout sniffer a odposlechnout Frantovo heslo do posty, tak mi OpenSSL bohate staci. (Tedy za predpokladu, ze Pepa neni kryptolog :-) Kdyz budu chtit zabezpecovat vojenska tajemstvi, asi sahnu jinam. Proste pouzivat prostredky odpovidajici ucelu.
Stejne tak me zarazi, ze popira zakladni pravidlo kryptologie - tajny je klic, nikoli algoritmus. -
Honza (neregistrovaný)
Dobry den! Nechci mluvit za petra, ale mne po precteni jeho prispevku vubec nevyznelo, ze by mluvil o uzavrenosti algoritmu. Naopak v te dalsi casti psal o El Gamal, ktere je zcela otevreny (pokud se nepletu) oproti RSA. On psal jen o uzavrenosti implementace, s cimz se da z docela rozumnych duvodu souhlasit.
A stejne i naznacil hned v tom prvnim prispevku, ze OpenSSL jen jen na nejaky chat, kde nejsou kriticka data, cimz parafrazoval to, co jste vy napsal jinak, tedy pouziti takove implementace :-) Takze vazeny pane Kara, me osobne prijde, ze ani Vy jste se prilis netrefil :-) Kazdopadne dekuji za clanek. -
Michal Kara (neregistrovaný)
Ja bych si s nutnosti uzavrenosti implementace nebyl tak jisty, IMHO duvody proc by mel byt otevreny algoritmus plati i v pripade implementace.
Osobne mi prijde zabezpeceni posty dulezitejsi nez zabezpeceni chatu, proto jsem to napsal :-) (BTW, za jeden z nejvetsich bezpecnostnich problemu povazuji fakt, ze neexistuje zadny obecne rozsireny standard pro sifrovani posty, takze Internetem stejne chodi nesifrovana :-((( ). -
Honza (neregistrovaný)
Ja chapu Vas pohled, ale podle mne jiz neni spravny. U algoritmu je to pomerne jasne, je to koncept, popisujici, jak ma zamek fungovat aby se otevrely dvere. Ale podle mne implementace jsou jiz konkretni dvere a neni nutne znat implementaci, pokud ta se ridi podle design patterns, ktere jsou urceny pro jejich vyvoj. V podstate Vy chcete, aby se tou otevrenosti kodu resilo to, co by se melo resit popisem patternu, jak se ma ta dana metoda implementovat (coz je opet ten koncept). Neboli Vy spojujete otazku teoreticke specifikace (napr. matematicke a inzenyrske) se samotnou "delnickou praci". Kazdopadne kdyz date utocnikovi do ruky kod, tak on muze objevit vice slabosti a ty zneuzit. V podstate na zaklade OSS reseni predpokladate, ze ten clovek, co prijde na tu chybu bude poctivy a nezneuzije ji. Ale co znam bezpecnostni techniky, tak ty berou opak, tedy ze lide jsou neduveryhodni, a proto se snazim jim dat co nejmene voditek, aby bylo mozne se probourat. Me to prijde pana Kara opravdu logicke ;-)
-
Michal Kara (neregistrovaný)
No, myslim, ze se nedohodneme. Vase argumenty se daji stejne tak pouzit pro zduvodneni nutnosti uzavrenosti algoritmu. Take mohu tvrdit, ze je nutne algoritmus uzavrit, protoze kdyz nekdo najde chybu, tak si ji muze nechat pro sebe a zneuzit ji.
Ja tvrdim, ze nevidim duvod, proc by se kvalita delnicke prace (implementace) nemohla proverovat stejnym zpusobem (otevrenim) jako kvalita navrhu.
Ve specifickych implementacich (napr. vojenstvi) je uzavrenost mozna a prinosna, ale v siroce rozsirenych aplikacich uz bych rekl, ze je spise na skodu. K vytvoreni exploitu neni potreba kod. Potvrzuje to mnozstvi exploitu na aplikace s uzavrenym kodem.
Mozna je tomu v sifrovani jinak, ale v obecne bezpecnosti nemohu rici, ze by aplikace s uzavrenym kodem byly bezpecnejsi. Spise naopak kdyz mam otevreny kod, mam bezpecnost vice ve svych rukou a nemusim se spolehat na libovuli vyrobce SW, ze chybu odstrani. A koneckoncu pripad se zadnimy dvirky do Interbase hovori vice nez jednoznacne pro vyhody otevreneho kodu.
-
Honza (neregistrovaný)
Na ten nesouhlas mate pochopitelne pravo. Ale Vase jednoznacne zavery jsou podle mne ukvapene.
Pochopitelne ta analogie, co se tyka algoritmu, muze byt pravdiva, ale jen v te obecne rovine, ne v praxi a to ze zcela prosteho duvodu.
Abyste rozumel samotnemu algoritmu a mohl jste ho dokonce i nabourat, tak musite napr. spickove ovladat teorii cisel, musite presne umet rozebrat Fermatuv teorem atd. A to bych nerekl, ze umi mnoho lidi. U nas na MFF UK tohle zvladno jen par studentu a matematicke katedry a to jeste to byl pripad tech nejnadanejsich. Nejsem si jist, ze by toto zvladl jen tak nekdo :-) V pripade implementace snizujete tu narocnost o uroven nize. Zde jiz nemusi rozumet tolik matematickemu pozadi, muze znat sifrovani, ale nemusi to byt matematik a muze hledat chyby v implementaci (klasicke buffer overflow utoky nejsou vubec nutne znalosti matematiky, jen programovani a to je veeeeelmi snadne).
V pripade ochrany kodu se tomu rika obfuskace a tohle je podobny pristup. Vy pouze snizujete pravdepodobnost pruniku, ptz snizite velikost cilove skupiny, na kterou se to vaze, tedy spickovych matematiku bude vzdy radove mene, nez spickovych programatoru (aniz bych nekoho chtel urazit, ale to je statisticky fakt, spickovy programator muze byt stredoskolsky student, ale matimatik s vysokou pravdepodobnosti ne). -
Michal Kara (neregistrovaný)
S tim bych souhlasil. Ale na hledani buffer overrunu nemusim znat zdrojovy kod. Viz _mnohe_ priklady uspesne vyuzitich BO bez znalosti kodu (napr. IIS).
IMHO tim ze zverejnim zdrojovy kod zvysim sanci, ze ho bude studovat i "White Hat". Aplikace bez zdrojoveho kodu se vetsinou pokousi nabourat spise "Black Hat", protoze ostatnim to nestoji za tu mravenci praci. -
petr (neregistrovaný)
Zdravim. No jak se mi zda, preci jen mate neprofesionalni pohled (bez urazky).
Jen par komentaru:
1) OSS systemy trpi vyrazne vice exploity, coz lze snadno prokazat a nase firma to ma v umyslu, ptz jsme pripravili spolecne s CERN prehled bezpecnostnich exploitu a ten hodlame publikovat. A OSS systemy maji radove vyssi vyskyt uspesnych pruniku, nez uzavrene. Napr. v pripade nasich implementaci, nezaznamenal doposud jediny klient uspesny utok, pouze se jednalo o DoS a podobne typy utoku na zablokovani systemu, ale ani jeden skutecny prunik.
2) Pan Honza to popsal presne. Ani nahodou nelze srovnavat matematickou algoritmizaci s implementaci. To je uplne o necem jinem. Matematicka algoritmizace je stavena tak, aby mela "neomezenou" zivotnost, kdezto implementace trpi v KAZDE verzi potencionalnimi chybami bez ohledu na opravy. A proto je zcela nesmyslne srovnavat zverejneni algoritmu s implementaci, jsou to hrusky a jablka.
Vy se na to nedivate jako profesional na bezpecnost, ale jako obhajce nejake ideologie, co se snazite prosazovat a to je spatne. Nedovedu si predstavit, ze by napr. armada zverejnila sve zdrojove kody systemu, co pouzivat, to je naopak predmetem silne spionazni aktivity a kdy se to podari ziskat,je to obrovsky uspech. A vite proc? Protoze je pak nesmirne snazsi proniknout do systemu. A tim mate odpoved.
Nevidim PRINCIPIELNI duvod, proc bych mel pristupovat jinak k armade a nebo napr. k e-shopu, kde jsou jakakoliv data. Stejne tak i k mailu apod. Chci je drzet zabezpecena. Budu se tedy snazit jednat jako armada, a to proto, ze tento model predstavuje nejvyssi moznou uroven zabezpeceni a pochopitelne nebudu kupovat tak drahe systemy, ale budu kopirovat, jak napsal Honza "design patterny"! A jednim z techto vzoru chovani je i utajeni kodu!
Muzete i videt, ze prave Vami zminovane OpenSSL trpi nesmirne pruniky a napr. pan Klima jasne zminil, ze jejich prunik do systemu na zaklade OpenSSL byl mozny diky tomu, ze meli zdrojove kody. U ostatnich systemu s uzarenym kodem to nedokazali, a jak napsal pan Klima bylo to proto, ze tohle by bylo pomerne obtizne zjistovat.
Nechapu, jak muzete postavit ideologii (tedy OSS) nad bezpecnost. Pokud chcete psat o bezpecnosti, zbavte se ideologie. Jinak je to jen propaganda. -
Michal Kara (neregistrovaný)
Nerekl bych ze prosazuji ideologii. Spise prosazuji svuj odborny nazor, tak jako Vy prosazujete svuj ("hodlame prokazat ze..."). Na tom ale nevidim nic neprofesionalniho. Muj nazor vychazi z mych zkusenosti a Vas zase z Vasich. Ja vidim, ze "security through obscurity" funguje u jednotlivych instalaci (armada) ale uz nikoli u siroce rozsirenych SW. U toho armadniho je totiz problem nejenom ziskat zdrojove kody, ale take vubec ziskat pristup k tomu SW.
Abyste mne chapal - ted se nebavim jenom o SSL implementacich. V tom mozna mate pravdu. Ja ted mam na mysli vsechny komponenty systemu, ktere je mozno exploitovat.
Jiny pristup: Jednim z pravidel bezpecnosti je, ze je nesmysl chranit data vetsimi naklady, nez je jejich cena. Data armady maji zajiste vetsi cenu, nez data e-shopu. Takze e-shop sice muzete mit super zabezpeceny, ale ve vysledku na tom tratite, protoze by bylo levnejsi udelat zabezpeceni mene kvalitni, zato vsak levnejsi a smirit se se zbytkovym rizikem.
Ad poznamka pana Klimy: Predpokladejme, ze podobna chyba existuje v XYZ SSL, ktere ale kvuli nedostupnosti zdrojovych kodu nezkoumal. Ted je ale otazka - co je bezpecnejsi? OpenSSL, ve kterem je chyba opravena, nebo XYZ SSL, kde stale je ale nikdo o ni (verejne) nevi? Z toho co pisete bych usuzoval, ze podle vas XYZ SSL, ja mam vsak opacny nazor. -
petr (neregistrovaný)
Ja s Vami v podstate souhlasim, a kdyz si vsimnete, je mezi nami paralela. Pouze jeste k poslednimu bodu. Mohu rici, jak toto resi velke firmy, se kterymi my spolupracujeme (jako RSA, Microsoft, IBM) a take i nase firma.
Co se tyka Bleichenbachera, tak tato chyba se nasich produktu tyka, ale to je koncepcni problem PKCS1ver1.5. Proto se pripravuje urcite "generacni posun", ktery je naplanovan na release asi za rok (u vsech techto firem).
Co se tyka toho exploitu, tak si prosim precte ten dokument. Ani nahodou se netyka nasich produktu, nebo MS SSL nebo produktu RSA. A to proto, ze tyto firmy se striktne ridi doporucenymi "patterny" s ohledem na implementaci PKCS1. A sem patri i kontrola verze oracle, coz prave OpenSSL nedela (nechova se podle doporuceni RSA, az nyni, co je prunik pana Klimy k tomu prinutil). To jen na vysvetleno, ze se to neda kamuflovat, ze kdyz je to otevrene, ze je to fixovane. Naopak, ten tym to spatne neimplementoval a opravila se tato velmi hruba chyba OpenSSL. Jine firmy, co investuji do svych testovacich laboratori kontroluji s RSA prave dodrzovani doporuceni RSA. Proto tam ten problem neni. Ale je pravda, ze UPLNE vsechny implementace budou korektni az po opusteni PKCS1ver1.5, coz ale neni tak trialni a je nutne po "posvetit" RSA, ktere na to ma licenci a musi to odsouhlasit. -
Je absurdní se domnívat, že vaše aplikace je bezpečnější, když "ji ještě" nikdo neprolomil. Znamená to jen to, že se o to ještě nikdo nepokusil (anžto zřejmě nebude tak rozšířená nebo dosud není průnik odhalen).
Navíc u uzavřených implementací zapomínáte na fakt, že ukrást zdrojové kódy není až takový problém. Může to být otázka úplatku, hrubé síly (sprosté vykradení kanceláří), lidské chyby (ukradení notebooku s důvěrnými daty) nebo primitivní využití trojského koně (uvnitř firmy). Asi ještě jednodušší bude jít na to přes vládní úroveň (tj. firma bude povinna spolupracovat v zájmu národní bezpečnosti a následně to někdo pustí dál).
Tím se dostáváme k problému, že průnik lze realizovat snadno a bez možnosti obrany (nikdo z "White Hat" to neopraví, protože prostě zdrojáky nemá).
Navíc se dá předpokládat, že do auditu kódu OpenSSL (resp. přepsání) budou investovat firmy, které o to mají zájem a je to předmět jejich core bussiness (Red Hat, Novell, IBM). Tedy přesněji - už to dávno dělají.
Navíc mi vaše poznámky nutkají představu, že jste umaštěný prosťáček, který si "něco přečetl", protože opomínáte logické věci, neumíte psát, vystupujete anonymně a mlžíte. Také tenhle článek není o "nejlepší implementaci", ale o principu manipulace s certifikáty (tato praktická stránka věci bude podobná u všech podobných nástrojů).
