> Ezt részletezd légy oly kedves. Kezdjük az első HTTP session felépítésénél. Mit küld a böngésződ, és mit kap válaszul a szervertől?
tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem? flame-nek ez vérgyenge - közösségi kerekasztalban indítottam a topicot, mert választ keresek.
> Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?
ha azt állítod, h. [valószínűség szerint] nehezebb egy bejelentkezett felhasználóval bejutni a serverre, mint egy nem-bejelentkezettel, akkor értelmetlen a beszélgetés
> tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem?
Van egy spéci kendőm, amikor jelszót gépelek, akkor (azon kívül hogy halkan, random szüneteket tartva nyomogatom a gombokat) ez van a kezemre terítve, hogy ne lehessen lelesni a HUP-on használt jelszavamat.
- van aki kavezobol netezik
- van aki munkahelyen
- van aki a szomszed wifijen csucsul
- van aki a tarsashaz kozos vegpontjarol jar ide
mindegyik helyzet olyan, ahol nem kozvetlenul a dsl modembe vagy dugva, hanem koztes dobozon kersztul ered el a vilaghalot. nem mindig tudod, hogy ki az aki hozzafer a router/proxy/gateway gephez.
nem, nem erted. ssl feletti http kommunikaciot szeretnek. a titkositott kuldes-fogadas volna a https ertelme, azaz hogy a felhasznalok azonositasara szolgalo jelszo ne egyszeru szoveg formajaban utazzon a kliens es a szerver kozott.
a szal ugy kezdodott, hogy 'Minek?' <- ami pedig a https-re vonatkozott. te erre feltettel par kerdest, amikre megprobaltam valaszolni. te ezekbol azt szurted le, hogy bizonyara one-time jelszo azonositast szeretnek. kijavitottam a megallapitasod.
most pontositanek a fentieken: amikor azt irtam, hogy https-t szeretnek, azt ugy ertettem, hogy a korabbi hozzaszolasaimmal ezen protokol elonyeirol beszeltem, nem pedig az altalad emlitett azonositasi eljarasrol.
nem kardoskodom sem mellette, sem ellene. egyszeruen azt hittem, hogy azert tettel kerdojelet a mondatod vegere, mert valaszt varsz es nem azert mert unalmas az esti tevemusor es kedved tamadt szorszalakat hasogatni egy forumon.
Ha a kávézó, vagy a szomszéd gépén beírod a jelszavadat, akkor semmilyen ssl nem véd meg téged! Kivéve, ha fejben futtatod az ssl-t, és a kódolt értékeket gépeled be :-)
A más wifije már más tészta, az ellen tényleg védene.
Soha nem gondoltam volna b+, hogy olyan weboldalt hozok össze, hogy az emberek annyira rá vannak kattanva, hogy lopni akarnak account-ot, hogy hozzászólhassanak. Ez mekkora már :DDDDDDDD
> Logikus a nyilvános hozzászólásokat zárt borítékban beküldeni?
logikus, feltéve ha a zárt boríték előnye az, hogy nem szerzik meg a felhasználónevet/jelszót. és newsflash: a https-el ezt lehet elérni.
Szerintem te meg tudatlanul, hozzá nem értően kötekedsz, mindezt olyan stílusban, mintha legalábbis te szartad volna a spanyolviaszt. Vegyél vissza egy kicsit, és nem pofázz bele olyan dolgokba, amikhez rohadtul nem értesz.
> Természetesen úgy értettem, hogy a hozzá tartozó private kulcsot :-)
Rendes chip kártyát, privát kulcs sohasem hagy el. A kártya + PIN kód megszerzése pedig nem ugyanaz a kaliber, mint wifi lehallgatás közben nyílt név/jelszóba botlani.
Ha a számítógéped alá tud iratni bármit, akkor ha felnyomják a gépedet, akkor a felnyomást végző rosszfiúk is bármit alá tudnak iratni. Legalább addig, ameddig nem veszed észre és húzod ki a kártyát. A PIN pedig nem véd, mert azt a gépeden írod be.
Az már igaz, hogy nem ugyanaz a kaliber. De a biztonság illúziójába sohasem szabad ringatnunk magunkat.
Ami utána az esetel 99%-ában titkosítatlanul kering a világban.
Olyan ez, mintha valaki arra verné magát, hogy IRC-n SSL-l megy egy szerverre, aztán egy channelbe beírja, hogy ő mekkora secure, mert SSL. Jó, és a többiek? Vagy ha nagyobb szerver, az egyes node-k között?
Az SSL-en történő IRC-zésnek azért az az előnye megvan, hogy a NickServ jelszód nem plain txt megy. Meg ha jól emlékszem a szerver jelszó sem...
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
IRC szervereknek meg lehet adni, h adott csatornara csak ssl-lel titkositott nepeket engedjen be, innentol mar csak a vegpontok tamadasaval lehet a forgalmat lehallgatni, az ISP-hez telepitett csunya fekete dobozokkal mar nem. Etc.
hátha nem akarom, hogy valaki, aki a wifimen lóg, lássa, hogy én trollkodok gabucino néven a hupon. (Persze nem)
De egyébként pl. én nem szeretem, ha mások feltétlenül látják, hogy mit olvasok. Azt feltételezem (bár nem értek ehhez ennyire), hogy https felett csak annyit látnak, hogy a hup.hu géphez kapcsolódtam, de azt nem, hogy melyik cikket olvasom, melyik fórumba mit írok be.
Eszembe jutott egy példa (ha rossz, úgyis szóltok): munkahelyről netezek, tele van a tököm az egésszel, állást keresek a hup fórumban. De nem akarom bent közhírré tenni, hogy le akarok lépni.
Asszem stílust kéne váltanom. Némelyik hozzászólásom lényege, úgy két-három üzenetváltás után derülhetne ki, de ezekre általában nem kerül sor. Időnként még el is felejtem, hogy eredetileg merre akartam vinni a témát. Gondolom ez a kórral jár :-)
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Ez nem csak egy szavazás eredményének kérdése. Ez - ha normálisan meg van csinálva - akkor pénzkérdés is, illetve technikai kérdés is, amibe nyilván be kell vonni Attilát is, mint az oldal alatti infrastruktúra üzemeléséért felelős személyt.
Mit jelent pontosan a normálisan meg van csinálva?
Én üzemeltetek (haveroknak) webszervert, ott a https-hez kellett egy picit konfigurálni meg a startssl-nél aláíratni a tanúsítványt.
Pénzben jelentkező költsége 0 volt. Időráfordítás kb két óra. A gépet nem kellett emiatt megváltoztatni (nincs akkora terhelés, nem kellett új IP cím).
Persze nem hasonlítható össze egy napi pár tíz látogatós oldal egy huppal, de kíváncsi vagyok, mit kellene neked máshogy csinálni, mivel jár, és persze mi az, ami ezekből pénzbe kerül.
A startsssl free tanusitvanyaval az a baj, hogy attol meg nem leszel hitelesebb, csak https-en at fog menni a forgalmad. Csak egy fokkal jobb a selfsigned megoldasnal.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
nem is attol tartottunk, hogy trey nem is Micsko Gabor
arra teljesen jo lenne, hogyha wifin megnezem repterrol a hup-ot, akkor be tudjak jelentkezni vpn vagy egyeb trukkozes nelkul.
Rég néztem, de akkor a startssl (ami mögött valami izraeli moszad-fedőcég áll) ingyenes tanúsítványait ugyanúgy elhajtotta minden böngésző, mivel a kiállító CA certje egyikben sem volt meg.
Ez kb. a self signed kategória.
És tényleg, cirka másfél éve már a patchelt windowsokban is benne van. Hogy szalad az idő, lehet, hogy frissíteni kellene az ie6-ot a windows xp-n?
De nem merem feltenni a genuine advantage baszt, mert akkor mi lesz.
Attól tartunk, hogy pl. Sting egyik éjjel, miután megnézte a Mission Impossible első részét, a plafonról leereszkedik a szerverszobába, ráakaszt valami Windowsos lehallgató kütyüt a HUP-os szerver patch kábelére, kideríti az admin accountok jelszavait, és meghekkeli a Drupalt (bár ezt a részt inkább ki fogja szervezni, elég a saját CMS-ét érteni), hogy ezentúl csak prog.hu-s hírek jelenjenek meg rajta?
Vannak-e itt annyira értékes adatok, illetve keletkezhet-e az adatlopásból akkora kár, hogy megérje SSL-en keresztül (is) szolgáltatni? Szerintem nem.
Ennél sokkal érdekesebb, hogy a begyűjtött jelszavak (pl open wifi-n) mennyi más szolgáltatásnál is érvényesek. Tudom-tudom most majd beirja a sok okos, hogy ők minden egyes webes regjükhöz másik jelszót használnak, de a valóság nagyon más.
Terhelés ügyében egyszerű a dolog, külön login page kell és csak azt kell védeni, nem kell az oldal teljes forgalmát ssl-ezni.
Volt a múltkor egy műsor a TV-ben, a stáb lehallgatott egy wifi kapcsolatot, aztán becsengettek a házba, és mondták az embernek, hogy tudják, hogy most vett repülőjegyet ide és ide, stb. És ha nem teszi védettebbé a wifijét, akkor lehet, hogy legközelebb amikor nyaralni megy, a betörők fogják tudni, hogy mikor nincs otthon.
Nekem sok fontos oldalon külön-külön pwgennel generált jelszavam van, de van számos nem fontos oldal, ahol valóban egy jelszó van mindenhol. Persze ezekért nem is kár igazán, de azért nem mondanám el boldog boldogtalannak.
Ezeken az oldalakon pl. OpenID-t szívesen használnék, és akkor mehet titkosítatlanul is akár az autentikáció.
Én nem látom sok értelmét a teljes oldal titkositásának, de persze, ha a hw birja, akkor miért ne. De ha nem birja, akkor jöhet, hogy csak a login van titkositva, azt gondolom elbirja.
A repülőjegy vásárlást azért nehezen lehetne idekeverni, ez egy - a PM-eken kivül - nyilvános oldal, aki ide leir olyan infot, hogy mikor nem lesz otthon és az is kiderül, hogy hol lakik vagy egyéb érzékeny info-t annak tökmindegy, mert az ssl bevezetése után is bárki elolvashatja ugyanezt az info-t. Itt az egyetlen érzékeny adat a jelszó és talán a PM.
jo hogy leirtad, mar en is akartam.
ha valaki megnyomna a hup-ot, es megszerezne az itteni adatokat (jelszavak, privat uzenetek, ki melyik ip-rol lepett be melyik userhez), akkor lenne hirtelen kapkodas, hogy hoppa, ugyanazt a jelszot hasznalom itt, mint az itt megadott email fiokomhoz, hopp, itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.
szoval egesszen addig lehet bagatelizalni a biztonsag kerdeset, amig valaki ra nem szan nehany orat/napot, es be nem nyomja az oldalt.
en itt jottem ra, hogy a hup.hu-n olyan jelszot szabad csak hasznalni, amit sehol mashol nem hasznalok semmire.
Nem is kell semmilyen ilyen jellegű adatot megadni. Elég ha felnyomják az oldalt.. Kíváncsi lennék ki használja ugyanazt a jelszót több helyre, netán mindenhova. Legalábbis nekem nincs kedvem 10+ karakteres jelszavakat megjegyezni.. Kettőt tudok aztán ennyi, ezeket használom különböző helyeken. A váltogatás azért néha megtörténik. Nincs szabályos időköz..
Tehát elég ha felnyomják az oldalt, megszerzik a jelszavakat és nagy eséllyel bejutnak az ember e-mail fiókjába meg még kitudja hova..
Tyra3l-től indult a dolog, ő inkább céges adatokat emlegetett.. ("itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.") Amit nem éppen túl jó ötlet se se privát üzenetekben se sehol máshol megadni. Tehát olyan dolgokat, amiket nem kötelező magadni.
Tehát erre jött az, hogy ezeknek a megadása fail.. :-)
Gyerekek, most komolyan. SMTP-n szenzitív adatokat? PM-ben egy weboldalon keresztül? Ki a rák tudja garantálni, hogy ezt az oldalt senki, soha nem nyomja fel? Vagy nyomta már fel? Senki. Erre kell felkészülni. Mondjuk azon, hogy valaki plain text-ben levelez a HUP-on keresztül, nem fog segíteni az, hogy az oldal SSL-t használ vagy sem...
Jó, de a jelszómegadás, mint olyan (kötelezően) a rendszernek megy és nem mondjuk egy üzenetbe.. Senki sem írná ki a jelszavát sehova. Tehát a szövegértésemmel nincs gond.
- trey azt írta "itt", az a hup rendszer a jelen körlmények közt, teljesen egyértelműen, ráadásul aztóta igencsak megerősítette ezt szóval nem értem mit nem értesz
- a másik ami fontos egy fórumon: a logika, azaz nem kell a másikat fárasztani olyan ellentmondással hogy szerinted jó lenne plusz biztonság közben meg jó hogy nem a jelszavadat írod le hozzászólásban
"Nem is kell semmilyen ilyen jellegű adatot megadni" - Akkor én fogalmaztam rosszul. A "megadás" alatt én adatkiadást értettem, ami nem a felhasználó azonosítására szolgál és szerintem mindenki más is. Úgy látszik tévedtem.
A jelszó beírása is valamilyen formában megadás, csak az elkerülhetetlen és ha titkosítod, akkor senki nem látja.
Tehát ezt is megadod, de nem úgy, ahogy más adatokat.
A jelszót meg kell adni, de csak a rendszernek.. Ez olyan adat, amit muszáj megadni, ellenben céges adatokat pm-ben kiadni emberi butaság...
igen, arra probaltam celozni, hogy a latogatok egy (az atlaghoz kepest talan nagyobb) resze tisztaban van az IT biztonsag idevonatkozo passzusaival, ennek ellenere biztos vagyok benne, hogy lehetne nagyon mokas dolgokat talalni, es meg a nagyhangu, magukat biztonsagban erzo emberek accountja korul is.
szemely szerint en ugy gondolom, hogy bar egy kocsma ruhataratol sem varom el, hogy a svajci bankokhoz hasonloan vedje a ra bizott ertekeket, de azert ne egy nyitott ablaknal levo fogasra legyenek felakasztva a kabatok, amit az ablakon benyulva barki elvihet.
egy ssl cert beuzemelese gyakorlatilag elenyeszo penz/energiabefektetest igenyelne, es mar egy kicsit jobban aludnank ejszaka.
Hogy az oldal HTTPS-t használ, nem garancia arra, hogy nem törik meg az oldalt. Remélem ez azért tiszta. Bármelyik oldalt bármikor megtörhetnek. A HUP-nál sokkal nagyobb, sokkal nagyobb stábbal, sokkal nagyobb költségvetéssel, sokkal nagyobb és jobb szakembergárdával rendelkező oldalakat is megtörtek már. Tehát arra kell felkészülni, hogy itt az adatok nincsenek biztonságban. Ebből kifolyólag ide nem adunk meg szenzitív adatot.
igen, eppen ezert szamit manapsag az is alapnak, hogy nem taroljuk szerver oldalon plainben a jelszavakat, es sorolhatnam.
mert tudjuk, hogy nincs 100%osan biztonsagos rendszer, ezert nemcsak a behatolaselharitason dolgozunk, hanem a potencialisan okozhato kar minimalizalasan.
pl. mod_security sem veletlenul volt(van?) az oldalon.
szoval azt gondolom, hogy azert amit meg lehet tenni a biztonsag erdekeben, azt nem kellene ilyen ervekkel lesoporni az asztalrol.
Ne haragudj, de hadd kérdezzem már meg, hogy hol söpörtem le bármit is az asztalról? Egyelőre senki sem vetett el semmit. Annyit mondtam, hogy egy internetre kötött gép sosem életbiztosítás és SSL ide vagy oda, nem kell ide megadni éles e-mail címet (jó a freemail is csak éljen), nem kell ide megadni jelszónak a bankkártya PIN-t (senki se kéri, teljesen jó egy apg-vel generált random jelszó). Ha ez be van tartva, akkor semmilyen számodra értékes dologhoz nem lehet az oldalon keresztül hozzájutni. Azt hittem, hogy ezek széles körben ismert dolgok...
nem azt mondtam, hogy lesoported, hanem azt, hogy nem kellene lesoporni.
a valaszaidbol abszolut ugy latszik, hogy probalod bagatelizalni a hup-pal kapcsolatos biztonsagi problemakat.
lasd itt meg itt
az hozzaszolasod masodik felerol a velemenyem itt leirtam
Nem bagatelizálom, hanem reálisan gondolkodom. Nyilvánvalóan nem tudom garantálni 100%-ban (ki tudja?), hogy sosem férnek hozzá az adatokhoz. A legjobb szándékom ellenére sem. A legjobb amit ajánlhatok, hogy senki sem bízza szenzitív adatait az oldalra.
Egyébként, csak neked, még egyszer: Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj. Viszont itt szeretném újra megjegyezni, hogy baromi sok minden ellen NEM VÉD. Ezért (sem) nem kell ide megadni semmilyen fontos adatot.
Lehet én nem értek valamit, de akinek nem tetszik az nem használja, nem? Akinek meg kell az meg belép https -el.
---------------------------
Oszt jónapot!
http://hup.hu/node/99793#comment-1231490
"mert tudjuk, hogy nincs 100%osan biztonsagos rendszer, ezert nemcsak a behatolaselharitason dolgozunk, hanem a potencialisan okozhato kar minimalizalasan."
korkorosen ervelsz, szerintem hagyjuk abba.
Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában. A felelősség az adataidért nem csak az enyém, hanem a tiéd is. S valóban, abbahagyhatjuk.
"Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában."
igy volt eddig is, igy lesz ezutan is (remelem ez a mondatod nem azt jelenti, hogy amit irtam egyes szam elso szelyben peldat, azt te ugy ertetted, hogy tenyleg en irogatom pm-ben az oldalon, hogy melyik munkahelyemrol loptam adatot. :P )
"A felelősség az adataidért nem csak az enyém, hanem a tiéd is. "
nyilvanvaloan.
lehet hogy https nem mukodik ezen a ket oldalon, viszont az elveszett jelszavadat elkuldik mailben ha kered, mert megvan nekik plaintextben. Sting szerint ez biztonsagi szempontbol teljesen rendben van. Aranyos.
Ez nem bank. Közösségi oldal. Egy bizonyos szint felett nem lesz egyensúlyban a védelembe fektetett energia és a haszon.
A jelszavadért pedig ne aggódj, rendesen hash-olva van az adatbázisban.
Azért annyit kinézek a Drupal-ból hogy valami "globális" só van. Nem, nem néztem meg a forrást és igen, próbáltam már jelszavakat átemelni két Drupal installáció között és ment.
Szerk. Ledöbbentem. A sós kijelentésemet visszavonnám, kíváncsiságból utánanéztem a dolgoknak és úgy néz ki, plain md5-ben tárolódnak a jelszavak.
Pedig a mai jelszomegjegyzos-OpenID-s vilagban viszonylag kis problema a jelszo. Az itteni jelszavammal sokra nem menne, mert azt masutt nemigen hasznalom, es ahol lehet, OpenID-vel regelek. Ettol mondjuk lehetne felnivalom, amennyiben az OpenID szolgaltatomat feltorik, de az a sejtes, hogy egy olyan pici kis ceg, mint a Verisign, hallott mar a biztonsagrol, es talan - talan! - kepes arra, hogy megvedjen engem a nagy es csunya internettol.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
külön login page kell és csak azt kell védeni, nem kell az oldal teljes forgalmát ssl-ezni
Sajnos ennyire nem egyszerű a helyzet. Ha csak a login page van ssl-en, akkor ugyanúgy meglehet szerezni MITM a user/pass-t. Nem véletlenül állt át a Google sem a teljes https gmail-re.
facebook is elindult ebbe az iranyba.
es meg ha nem is csinal mitm-t a tamado, a session-t sima sniffelessel is ki tudja olvasni nem https-es keresekbol.
legalabbis ha jol van megirva a webapp.
ha a jelszo modositasnal ott van a regi jelszo egy password tipusu input mezoben, akkor mar meg is van a jelszo.
ha lehet email cimet modositani jelszo megadasa nelkul, es az elfelejtett jelszo kuldes feature kikuldi az email cimre a regi jelszot plainbe, akkor megint csak buko.
MITM ellen az SSL egyáltalán nem védett. Hogy egy egyszerű példát mondjak már az ősrégi ISA server is képes volt ezt megcsinálni, beékelődött a kliens és a szerver közé és szépen eljárt a kliens nevében a szerver felé, majd az egész titkositott forgalmat pont ugyanúgy elemezte, loggolta, szűrte mint a nem titkositott kapcsolatot.
hat pedig ehhez az kellett imho, hogy az ISA-nal telepitve legyenek a private+public kulcsok, anelkul nem fogja tudni szetszedni majd osszerakni a https forgalmat.
persze ha csak halozati szinten forwardol, ahhoz nem kell tudni ertelmezni az alkalmazasretegben levo titkositott forgalmat, de akkor az nem is sikeres MITM.
szerintem.
kicsit maskeppen fogalmazva: ssl-lel vedett weboldalaknal is be tudsz ekelodni a kliens es a szerver koze halozati szinten, de a public kulcs nelkul nem tudod irni/olvasni a https-ses uzenetvaltasokat.
persze a forgalmat el tudnad terelni(manipulalod a nevfeloldast, vagy a tenyleges kiszolgalast), de ha en mint kliens https://hup.hu -t kerek a bongeszombol, akkor neked https-sel kell valaszolnod, kulonben a browserem elszall hibaval, ha pedig https-sel valaszolsz, akkor a cert amit kuldesz nem lesz megbizhato/valid ahhoz a domainhez. (persze ha elloptad a hup-hoz tartozo private kulcsokat, akkor mukodhet az is, de akkor mar a hup-ra is telepithettel volna valami malware-t)
Nezd a pszichologiai oldalat. Ha jol csinalod meg a MITM appot es csak olyan szolgaltatashoz telepited ahol csak a forgalom titkositasara hasznaljak es nincs cert. auth (mint a webes szolgaltatasok nagyon donto hanyada), akkor csak egy olyan certre van szukseged a kliensek fele amelyik valamelyik nagyobb cert kiadonal lett beszerezve, h a chain-t a bongeszok hitelesnek fogadjak el es ne rinyaljanak erte. Innentol kezdve tied a forgalom, mert a kutya sem fogja ellenorizni, h az adott https kapcsolatot milyen certtel epitettek fel. A magyar parlament IT szekcioja is csak ezen a bananhejon csuszott el. :)
És ezt hogyan? Ahhoz, hogy a titkosított forgalomba bele tudjon nézni, vagy az kell, hogy ismerje a titkosításhoz használt kulcsot, vagy az, hogy a klienst rávegye, hogy ne a szerver számára titkosítson, hanem a középső ember számára.
Az elsőre, hogy neki megvan a szerver privát kulcsa, gondolom nem sok az esély.
A második akkor mehet, ha a kapcsolat felépülésekor a kliens számára ő jelentkezik be, mint távoli oldal, és a kliens megbízik a középső ember által mutatott tanúsítványban. Pl. a felhasználó elfogad egy self.signed certet, vagy mondjuk egy cégnél minden kliensen rajta van egy olyan CA kulcsa, amivel aláírt mindenre illeszkedő tanúsítványt mutat a céges proxy a kimenő kapcsolatokon.
Szóval hogy kell ennek a kivitelezését elképzelni mondjuk egy olyan helyen, ahol a rossz szándékú ember egy wifi hotspotot üzemeltet, és a beállított infrastruktúrával monitorozni akarja a felhasználók forgalmát? Mondjuk banki belépési adatokat akar lopni.
Csak egy, a user által megbiztott cert kell hozzá. Ez vállalati hálózaton alap dolog, de nem túl komoly összegért amúgy is beszerzhető. Érdemes rákeresni az ssl mitm-re, elképesztő mennyiségű tool van ilyesmire, nem véletlenül...
ha te tudsz olyan certet(es hozza tartozo private kulcsot) gyartani, amit akar csak egy major bongeszo is elfogad mondjuk a paypal.com -hoz, akkor miert nem vagy meg milliomos?
Itt egy két helyen látva, többek felbuzdulását azért halkan hozzá tenném, nem biztos hogy az SSL minden esetben jó megoldás. Gondoljunk bele abba, hogy van egy alkalmazás szintű tűzfalunk, ha titkosítjuk a csomagokat, akkor a tűzfalunknak fogalma se lesz arról hogy mi van a csomagban, hanem szimplán tovább engedi. Nyilván ez is kiküszöbölhető.
Más különben úgy gondolom, ha valaki lopni szeretne vagy betörni, akkor annak több módját is választhatja. Ugyanis önmagában a tűzfal semmit se ér. Minimális védelmet ad! Mi döntsük el hogy mi megy be és mi jön ki, csak is rajtunk múlik, és azon hogy felismerjük-e hogy valaki, megpróbál bejutni hozzánk. Ehez elég egy olyan oldalra ellátogatnunk, vagy egy régebbi verziószámú böngészőt használnunk. De megfúrhatjuk mások wifi-jét bejutva a belső hálóra, és onnantól kezdve miénk a pálya.
Összegezve ezzel csak annyit akartam mondani, ha valaki be akar törni vagy elakar lopni valamit, és az a személy ért hozzá, az meg is fogja tenni.
[Szerk.:]Ja igen, ha valaki adott felhasználó adott jelszavát akarja megszerezni, nem biztos hogy a szervert támadja meg, úgy gondolom, sokkal könnyebb egy mezei user gépére betörni, mint egy "jól" tehát jól konfigurált szerverre.
WAF nyilvanvaloan a ssl mogott van, vagy ha nem, akkor rendelkezik a kulcsokkal, hogy bele tudjon halgatni a forgalomba, ez minden WAF-nal megoldott.
a tobbivel kapcsolatban:
igen, minden rendszert fel lehet nyomni kello agykapacitas es ido, penz birtokaban, nem mindegy azonban, hogy mennyire nehezitjuk meg a tamadok dolgat.
a formalis kockazatelemzes segitsegevel ki lehet szamolni, hogy mi az a raforditas az IT biztonsagra, ami meg megterul. nyilvanvaloan itt nem fog trey egy teljes kockazatelemzest vegezni, hanem kb. zsigerbol eldonti, hogy mi az ami meg megeri neki. ez igy egy modszer
nyilvanvaloan a hup-nak nem felelossege a felhasznalok desktopjainak vedelme, tehat bar ez egy erdekes es kevesse koztudatban levo resze a temanak, de itt offtopic.
Hadd kérdezzem meg, nem kötekedés képen, csak érdeklődés szinten, a téma iránt. Te mióta foglalkozol IT biztonsággal? Esetleg milyen tapasztalataid vannak, és milyen megoldásokat tudnál felsorolni egy szerver védelme érben, főleg a szoftveres védelmi eszközök és megoldások érdekelnének, de ha tudsz olyan hardveres eszközt mondani, amit egy magamfajta user is megtud venni, mert nem méreg drága (nem a routerre gondolok), akkor légyszíves írj pár sort ezekről.
webfejlesztokent dolgozom 5. eve foallasban, regota erdekel a tema, de nem tartom magam igazi expertnek, nem ez az elsodleges szakiranyom, de azert mar lattam jo/rossz rendszert mindket oldalrol (mint fejleszto, illetve mint "tamado").
a docler akademia keretein belul volt egy eloadasom a temaban, ha gondolod nezd meg a slideokat, vagy a videot (regisztracio, belepes szukseges a video megtekintesehez). http://www.slideshare.net/Tyrael/biztonsgos-webalkalmazsok-fejlesztse http://www.doclerholding.com/hu/academy/4/
a kerdesed igy nagyon tag, igazabol az implementacio a konkret rendszerttol fugg, az elmeleti alapok szerintem benne vannak a slide-ban, bar elsosorban fejlesztoi peldakra kihegyezve.
amugy az alapok ma is ugyanazok, mint regen, tudd hogy mit vedesz, kitol, a biztonsag ne utolag hozzaadott eszkoz legyen, hanem a rendszer kialakitasanak minden dontesenel figyelembe vett szempont.
a leheto legkevesebb szukseges szolgaltatas a szamukra szukseges leheto legkevesebb prioritassal fusson, egymastol leheto legjobban elszeparalva.
folyamatosan monitorozzuk a rendszerunk mukodeset, mivel akar egy eszrevetlenul vegrehajtott betorest is lefulelhetunk azaltal, hogy mondjuk megugrik a halozati forgalom egy olyan szegmensben, ahol ez nem jellemzo, etc.
legyen megfelelo audit trail, hogy kesobb visszakovethetoek legyenek akar a sikeres/sikertelen tamadasok, akar csak az, hogy ki dobta el az eles adatbazist.
ehhez ugye szukseges, hogy ne legyenek kozos accountok a rendszerben, illetve nem art, hogyha a kritikus muveletekhez 1-nel tobb embernek a jelenlete/jovahagyasa kell, ezaltal akar megoldhatoak a "who watches the watchmen" jellegu szituaciok (ertsd, ha az egy szem rendszergazda rossz utra ter, akkor nincs senki aki kiszurna, vagy megakadalyozhatna az ugykodeseben)
ja, es persze kepezzuk a dolgozokot, nagyon fontos kialakitani egy olyan dolgozoi paranoia-t, hogy jelszot sosem ker tole senki, es ha megis, akkor jelentse a felettesenek, etc.
ps: aki szemelyeskedeshez keresi a toltenyeket, az is nezze meg a videot, aztan lehet fikazni, hogy izgulok, meg neha nem a legjobb az angol kiejtesem. :P
Nagyon szépen köszönöm az információkat, én webprogramozónak tanulok, mindenképpen érdekesnek és fontosnak tartom a témát. Ha van még hasonló hasznos dokumentációd, információd, szívesen fogadom. Köszönöm még1x
Az előttem szólóhoz csatlakoznék.. jó az anyagod, köszönet érte.
Egyébként meg óvakodni kell a magukat expert-nek nevezőktől hidd el, mert X év után is, nem árt néha újra olvasni az alapokat.
Egy dolgot hiányoltam az anyagból, de lehet a video-n rajta van (meg fogom nézni), hogy sok támadás típusnál nem volt konkrét
példa, de nyilván ez nagyon nagy munka (lett) volna.
1. "Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj."
2. "Lehet én nem értek valamit, de akinek nem tetszik az nem használja, nem? Akinek meg kell az meg belép https -el."
->
Mi az akadalya annak, hogy legyen mindketto? Miert megy azon az erolkodes hogy A vagy B, mikor nem egymast kizaro opciokrol van szo?
Gyakorlatilag semmi. De ez nem rajtunk múlik és Trey-nek is konzultálnia kell egy "feljebbvalójával"..
Én is használok olyan oldalakat, ahol be kell pipálni a "Biztonságos bejelentkezés (HTTPS)"-t és nem tartom rossz ötletnek. :-)
Szerintem egy ("belepes titkositott csatornan") pipa belefer, aki akarja hasznalja, aki akarja nem. Igy belefer akar egy self signed tanusitvany is. Ha olyan helyen ulok, hogy titkositas mentes wifi es tenyleg felek, hogy a mellettem ulo vezna srac, 3 hetes szorrel az arcan, hacker matricas laptopjaval elfogja lopni a jelszavaimat, akkor inkabb en is bepipalom es a tanusitvanyt is telepitem. Majd dolgom vegeztevel ranyomok a kilepes gombra es ennyi. Nem kotelezove teve, de elerhetokent szerintem lenne helyen, meg ha ilyen megoldasban is.
A lenyeg szerintem a lehetoseg megadasaban van, ha tenyleg szuksegesnek latom. Aki meg akarja hasznalni, telepitheti a cert-et is.
Ahogy beleolvastam mindenki a bejelentkezés miatt tartja fontosnak.
Akkor legyen csak a bejelentkezés https-en!
Egy időben a gmail is így működött. Most már ahogy nézem full https lett.
ps: megcsinalni kb. ugyanannyi melo hogy csak a login legyen https, mint hogy minden.
cpu-ban/bandwith-ben lehet elteres, de szerintem 5-20% hasznalna szerintem csak az ssl-t, az meg nagysagrendileg nem novelne meg annyival, hogy ne erne meg megcsinalni.
Felesleges. Legyen OpenID belepesi lehetoseg, es van olyan OpenID szolgaltato, aki konkretan OTP bejelentkezest intez. Ezt nem surun lehet uberelni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
+1 az OpenID-nek (amivel ráadásul az OTP is megoldódna, mert van olyan szolgáltató, aki támogatja)
Ha mégis esetleg saját https bejelentkezés lenne, akkor nehogy úgy legyen mint a freemail kapuja, ahol akkor lopom el a jelszót amikor akarom. Ha nincs keret teljes https-re, akkor a szegény ember dupla bejelentkezése a megoldás: sima http-n biztonságos bejelentkezésre kattint, átmegy https bejelentkező oldalra és ott írja be a jelszót, majd auth után vissza http-re. Tényleg elég lenne csak a jelszót levédeni, mert ez veti fel a legtöbb biztonsági problémát. Szerveren pedig egyedi salt mindenkinek + SHA.
En azt gondolom, hogy egy apache-nak baromira mindegy, hogy egy oldalt, vagy egy komplett site-t szolgal ki https-en, ebbol a szempontbol nem erzek problemat, hogy a komplett oldal menjen https-en. Az igazi koltseg maga a cert, amit azonban legfeljebb 1 domainre kell megvenni (hup.hu), tehat semmi specialis nincs benne (nem merul fel pl. a wildcard vagy nem wildcard kerdes).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
https-ses forgalom kicsit tobb eroforrast igenyel (tobb tcp uzenetvaltas megy, illetve minden tartalmat oda-vissza titkositani kell az atvitel soran), de szerintem megeri a befektetett energiat.
http://serverfault.com/questions/43692/how-much-of-a-performance-hit-fo…
persze nagyon sok fugg az adott szerver profiljatol (a dinamikus oldalak rendereleset nem dobja meg szazalekosan annyira a plusz ssl handshake, meg encryption, valamint pl. bekapcsolt KeepAlive-val lehet eleg sokat sporolni a handshake-bol fakado halozati ping-pong-on.), de ha teljes site-ot rakod ssl ala, akkor akar eleg jelentos overhead-je is lehetne.
ettol fuggetlenul szerintem megeri.
Igen, vagy nem, attol fugg, mennyire akarunk igenyesek lenni. De az ara semmikeppen sem fugg attol, hogy hany oldalt-aloldalt akarunk alarakni, ezt akartam kihozni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Ettől függetlenül nem szabad figyelmen kívül hagyni, hogy a https igazán egy területen nyújt kiemelkedő védelmet: a nyílt, titkosítatlan wifi hálózatok használata esetén. Normál otthoni DSL-t vagy kábelt sokkal nehezebb lehallgatni. Ezeken túl még számtalan módon meg lehet támadni egy oldalt, illetve annak felhasználóit. A legtöbb felhasználó esetén valószínűbb a számítógépének a fertőzöttsége, mint a lehallgatása (persze ez talán nem igaz a HUP közösségére).
Ettől függetlenül én a https bevezetésére szavaznék, még ha csak olyan high-performance konfigurációban is, mint pl. a Facebook (RC4_128, MD5, RSA_1024).
És a StartSSL tökéletesen megfelel erre a célra ingyenesen. Nem kell telepíteni a böngészőkbe semmit, alapból ismeri mindegyik. Én is használom zárt adminisztrációs és statisztikákat biztosító oldalakhoz.
Igazad van, talán olvastam is, csak nem gondoltam végig.
Arra gondoltam, hogy a fórum üzeneteket felesleges titkosítani, egy terhelt szerver esetén biztos rádob egy konstans szorzófaktort.
De valóban, ha megszerzik a session-t akkor megváltoztathatják a jelszót, és így ott vagyunk ahol a part szakad. Jobb megoldás kell. :)
Ez azt akarta jelenteni, hogy titkosítatlan, nyílt wifi hálózat esetében elég ha "odaülsz" egy notebook-kal, de próbáld meg lehallgatni pl. az én otthoni forgalmamat! A kettő nem ugyanaz. Nem lehetetlen, de sokkal nehezebb megfelelő pontot találni.
feltéve ha idézőjelben "bízik" az ember a drupalban és a kliens [felhasználó] gépe tiszta, akkor kizárólag HTTPS-t használva hogyan lehet sessiont lopni? - mármint csak érdekel, nem b*sztatásból
A keyloggernek is mindegy a jelszavad.
Figyuzzatok ide duma-bercik:
- tegyél ki egy ssh-t és nézd meg mit csinálnak vele az oroszok és a törökök...
Többet ér mint akármilyen suli, és tanulj meg ellene védekezni.
ennyi, csapó
:)))
keylogger esetében tényleg mindegy hogy a HUP bejelentkezés https-en van-e vagy sem. Mondjuk nekem is mindegy, mert nem használok wifit(pláne más wifijét), a szolgáltató meg nem jelent akkora kockázatot hogy foglalkoznom kelljen vele.
Keylogger ellen OTP segítségével lehet védekezni. Egyébként akit érdekel a téma az nézze meg szoftveres keyloggerrel mondjuk a CIB bejelentkezést és csodálkozni fog azon, amit lát. Ezen kívül hatezer mód van keylogger ellen védekezni (virtuális billentyűzet, logika vizuális jelszavak, stb..). Passzív támadást ma már nagyon könnyen ki lehet védeni. Célzott aktív támadásra pedig védekezzenek csak a bankok out of band channellel.
Megnézem mi ez az OTP, de a keylogger nem azt jelenti hogy kb megszerezték a "terminálomat", és tulajdonképpen azt csinálnak rajta amit akarnak, akár kernel modulokat is? De jó nem kötekedem, olvasok.
Szerk:
"OTPs are difficult for human beings to memorize. Therefore they require additional technology in order to work."
Jahhogy így más. :) Hát nekem nincs ilyen additional technology izém. :)
Jó de ha valaki annyira tart attól hogy meg van törve a "terminálja", hogy külön eszközt használ a bejelentkezéshez(Ez valami USB-s kütyü?). Akkor attól nem tart hogy ellopják a session-jét is? Akkor ezzel az erővel ezen a "kölön eszközön" kéne intézni a banki átutalást is, de akkor már ez egy laptop tudású gép.
Na igen. Évek óta tuningolt ssh beállításokkal üzemelünk, és ami a legfontosabb, nem a 22-es porton. Meg ugye vannak egyéb dolgok is, amit el lehet követni a védelem erősítésének érdekében. De ez nem ide tartozik.
CIB felülete billentyűleütéseket szimulál és ha csak hookolsz nem tudod megkülönböztetni a felhasználó és a gép által szimulált leütéseket (driver szinten kell dolgoznia a keyloggernek vagy hardver kell), így a jelszót sem tudod megszerezni így.
Hozzászólások
Minek?
az oldalon lehet regisztrálni.
regisztrálás után belépni -> fórumon hozzászólni.
belépve lenni.
mind eközben a hozzáférést a kliens <-> server közt ellopni -> nagyobb támadási lehetőség a hup.hu ellen
annyival növelné a terhelést a https?:O
logikus magyarázat ez ellen létezik?:O
> mind eközben a hozzáférést a kliens <-> server közt ellopni
Ellopják megjelenés előtt a hozzászólásaidat? Az komoly.
> -> nagyobb támadási lehetőség a hup.hu ellen
A "nagyobb" az mondjuk 10 helyett 11? Vagy mi?
> Ellopják megjelenés előtt a hozzászólásaidat? Az komoly.
nem a hozzászólásomat, a "hozzáférésemet". felhasználónév/jelszó páros
> A "nagyobb" az mondjuk 10 helyett 11? Vagy mi?
pontosan.
> nem a hozzászólásomat, a "hozzáférésemet". felhasználónév/jelszó páros
Ezt részletezd légy oly kedves. Kezdjük az első HTTP session felépítésénél. Mit küld a böngésződ, és mit kap válaszul a szervertől?
>> A "nagyobb" az mondjuk 10 helyett 11? Vagy mi?
> pontosan
Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?
> Ezt részletezd légy oly kedves. Kezdjük az első HTTP session felépítésénél. Mit küld a böngésződ, és mit kap válaszul a szervertől?
tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem? flame-nek ez vérgyenge - közösségi kerekasztalban indítottam a topicot, mert választ keresek.
> Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?
ha azt állítod, h. [valószínűség szerint] nehezebb egy bejelentkezett felhasználóval bejutni a serverre, mint egy nem-bejelentkezettel, akkor értelmetlen a beszélgetés
> tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem?
Van egy spéci kendőm, amikor jelszót gépelek, akkor (azon kívül hogy halkan, random szüneteket tartva nyomogatom a gombokat) ez van a kezemre terítve, hogy ne lehessen lelesni a HUP-on használt jelszavamat.
:)
off
nekem meg foggalmam sincs, h. mi a jelszóm.
on
nem en lettem megszolitva, de szivesen belekotyogok barmibe: belepeskor plaintext mennek a user/pass form mezok.
udv,
sbalazs.
Rosszul kérdeztem, kifelejtettem a tolvajt, aki lopja közben a bájtocskákat.
- van aki kavezobol netezik
- van aki munkahelyen
- van aki a szomszed wifijen csucsul
- van aki a tarsashaz kozos vegpontjarol jar ide
mindegyik helyzet olyan, ahol nem kozvetlenul a dsl modembe vagy dugva, hanem koztes dobozon kersztul ered el a vilaghalot. nem mindig tudod, hogy ki az aki hozzafer a router/proxy/gateway gephez.
sbalazs.
Értem, tehát http://en.wikipedia.org/wiki/One-time_password bejelentkezést szeretnél, hogy a lehallgatott jelszóval ne menjen senki semmire.
nem, nem erted. ssl feletti http kommunikaciot szeretnek. a titkositott kuldes-fogadas volna a https ertelme, azaz hogy a felhasznalok azonositasara szolgalo jelszo ne egyszeru szoveg formajaban utazzon a kliens es a szerver kozott.
sbalazs.
Ahogy nézem, te nem valami probléma megoldását kívánod, hanem csak a https bevezetését.
a szal ugy kezdodott, hogy 'Minek?' <- ami pedig a https-re vonatkozott. te erre feltettel par kerdest, amikre megprobaltam valaszolni. te ezekbol azt szurted le, hogy bizonyara one-time jelszo azonositast szeretnek. kijavitottam a megallapitasod.
most pontositanek a fentieken: amikor azt irtam, hogy https-t szeretnek, azt ugy ertettem, hogy a korabbi hozzaszolasaimmal ezen protokol elonyeirol beszeltem, nem pedig az altalad emlitett azonositasi eljarasrol.
nem kardoskodom sem mellette, sem ellene. egyszeruen azt hittem, hogy azert tettel kerdojelet a mondatod vegere, mert valaszt varsz es nem azert mert unalmas az esti tevemusor es kedved tamadt szorszalakat hasogatni egy forumon.
tovabbi szep estet,
sbalazs.
Igazad van, rosszul kommunikáltam. De azért ma is tanultam valami újat :-)
Attól még a sessiont el tudják lopni! Igaz, az csak addig jó, amíg be vagy jelentkezve. De az OTP nem ér sokat, ha a session nincs titkosítva.
Ahol egy primitív session védelmet nem képessek összerakni, ott már régen rossz. (Nagyon ciki lenne a drupal részéről, ha nem lenne.)
----------------
Lvl86 Troll
Ha a kávézó, vagy a szomszéd gépén beírod a jelszavadat, akkor semmilyen ssl nem véd meg téged! Kivéve, ha fejben futtatod az ssl-t, és a kódolt értékeket gépeled be :-)
A más wifije már más tészta, az ellen tényleg védene.
Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?
2 helyett 3
facebook es iwiw mellett a hup :)
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
tényleg, minek? ki akar HuP accountokat lopkodni?... szerintem teljesen felesleges a HTTPS.
Nem mindenki használ minden egyes regisztrációjához külön jelszót..
------------------
My Open-Source Android "Projects"
az egyéni probléma :D
[gabucino] "tényleg, minek? ki akar HuP accountokat lopkodni?... szerintem teljesen felesleges a HTTPS."
[gabucino] en
Rettegj! :)
Soha nem gondoltam volna b+, hogy olyan weboldalt hozok össze, hogy az emberek annyira rá vannak kattanva, hogy lopni akarnak account-ot, hogy hozzászólhassanak. Ez mekkora már :DDDDDDDD
(burkolt up, nehogy már elüljön ez a topik)
--
trey @ gépház
Lehet csak álláshirdetést akar feladni anélkül, hogy a profession-nek védelmi pénzt kelljen fizetne.
Követelem, hogy minden usernek küldj vpn kulcsot! Ezentúl a biztonságérzetem miatt jobb lenne tunelen keresztül olvasgatni a HUP-ot. :DD
támogatom +1
+1: alapból mindent https-en használok, amit lehet. A postán a leveleimet is borítékba szeretem tenni, nem levelezőlapon küldöm el
> A postán a leveleimet is borítékba szeretem tenni, nem levelezőlapon küldöm el
Logikus a nyilvános hozzászólásokat zárt borítékban beküldeni?
> Logikus a nyilvános hozzászólásokat zárt borítékban beküldeni?
logikus, feltéve ha a zárt boríték előnye az, hogy nem szerzik meg a felhasználónevet/jelszót. és newsflash: a https-el ezt lehet elérni.
> hogy nem szerzik meg a felhasználónevet/jelszót
Szerintem csak akkor nem szerezhetik meg a "felhasználónevet/jelszót", ha nincs.
Szerintem te meg tudatlanul, hozzá nem értően kötekedsz, mindezt olyan stílusban, mintha legalábbis te szartad volna a spanyolviaszt. Vegyél vissza egy kicsit, és nem pofázz bele olyan dolgokba, amikhez rohadtul nem értesz.
---
http://xkcd.com/258/
Apple MacBook Pro 13"
C2D 2.26GHz/3MB | 4GB@1067MHz | 160GB@5400rpm SATAII
Alázz meg egy szakmai hozzászólással.
Pld írhattad volna, hogy a "nincs" helyett a "csak rövid ideig van" is elegendő lehet, ami a one-time-password megoldások felé vezet.
Vagy megkérdezhetted volna, hogy mikor nincs "felhasználónév/jelszó"; én meg megírtam volna, hogy tanúsítvánnyal történő bejelentkezésnél.
Vagy valami ilyesmi. A szimpla dühöngés helyett.
Akkor meg a tanusítványt nyúlják le. Ott vagy, ahol a part szakad.
> Akkor meg a tanusítványt nyúlják le.
Nem kell lenyúlni, odaadom bárkinek, aki kéri:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authentica…
[...]
The client responds with a Certificate message, which contains the client's certificate.
[...]
Természetesen úgy értettem, hogy a hozzá tartozó private kulcsot :-)
> Természetesen úgy értettem, hogy a hozzá tartozó private kulcsot :-)
Rendes chip kártyát, privát kulcs sohasem hagy el. A kártya + PIN kód megszerzése pedig nem ugyanaz a kaliber, mint wifi lehallgatás közben nyílt név/jelszóba botlani.
Ha a számítógéped alá tud iratni bármit, akkor ha felnyomják a gépedet, akkor a felnyomást végző rosszfiúk is bármit alá tudnak iratni. Legalább addig, ameddig nem veszed észre és húzod ki a kártyát. A PIN pedig nem véd, mert azt a gépeden írod be.
Az már igaz, hogy nem ugyanaz a kaliber. De a biztonság illúziójába sohasem szabad ringatnunk magunkat.
> De a biztonság illúziójába sohasem szabad ringatnunk magunkat.
Nekem nem kell 100% biztonság, az is elég ha (sokkal) többe kerül a rossz fiúknak, mint amennyit nyerhetnek rajta.
Newsflash: nem.
----------------
Lvl86 Troll
hm, úgy rémlik, mintha lehetne PM-et küldeni.
Ami utána az esetel 99%-ában titkosítatlanul kering a világban.
Olyan ez, mintha valaki arra verné magát, hogy IRC-n SSL-l megy egy szerverre, aztán egy channelbe beírja, hogy ő mekkora secure, mert SSL. Jó, és a többiek? Vagy ha nagyobb szerver, az egyes node-k között?
----------------
Lvl86 Troll
Az SSL-en történő IRC-zésnek azért az az előnye megvan, hogy a NickServ jelszód nem plain txt megy. Meg ha jól emlékszem a szerver jelszó sem...
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
IRC szervereknek meg lehet adni, h adott csatornara csak ssl-lel titkositott nepeket engedjen be, innentol mar csak a vegpontok tamadasaval lehet a forgalmat lehallgatni, az ISP-hez telepitett csunya fekete dobozokkal mar nem. Etc.
---
pontscho / fresh!mindworkz
hátha nem akarom, hogy valaki, aki a wifimen lóg, lássa, hogy én trollkodok gabucino néven a hupon. (Persze nem)
De egyébként pl. én nem szeretem, ha mások feltétlenül látják, hogy mit olvasok. Azt feltételezem (bár nem értek ehhez ennyire), hogy https felett csak annyit látnak, hogy a hup.hu géphez kapcsolódtam, de azt nem, hogy melyik cikket olvasom, melyik fórumba mit írok be.
Eszembe jutott egy példa (ha rossz, úgyis szóltok): munkahelyről netezek, tele van a tököm az egésszel, állást keresek a hup fórumban. De nem akarom bent közhírré tenni, hogy le akarok lépni.
y http://hup.hu/node/99323#comment-1223666
én is letagadnám :D
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Azert annak meg mindig orulok, h nem mindig tudom eldonteni, h csak jatszod-e a hulyet. :) Ezen meg mindig jol szorakozom. :)
---
pontscho / fresh!mindworkz
Asszem stílust kéne váltanom. Némelyik hozzászólásom lényege, úgy két-három üzenetváltás után derülhetne ki, de ezekre általában nem kerül sor. Időnként még el is felejtem, hogy eredetileg merre akartam vinni a témát. Gondolom ez a kórral jár :-)
az Alzheimer-ko'rral? :D
Ez ugyanaz a német, aki mindig eldugja a szemüvegemet? :-)
+1
Ártani nem árt.
---------------------------
Oszt jónapot!
+1 en is hianyoltam mar tobbszor, mar a facebookot is csak https-ben vagyok hajlando hasznalni
Támogatom. Miért is ne?
(Saját szerver van? Ha nem, akkor mennyi a +1 Ip cím?)
+1
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Én meg néha reflexből keresem a like gombot itt. :)
+1 :D
Mennyi newbie. Annak idején a HUP ment https-en (is).
--
trey @ gépház
anno volt amikor meg internet sem volt.
nade hogy jon ez ide?
Tyrael
Jé, 10 éve is úgy nézett ki az oldal, mint ma! :)
http://web.archive.org/web/20020722012144/http://hup.hu/
(No offense :) )
És figyeljétek a felső menüben az "SSL kapcsolat" opciót! Trey igazat beszélt! :)
Remélem így is marad mindig a kinézet. Egyébként Trey miért hazudna? :-)
Ja, azt elfelejtettem mondani? Azért, mert ment a sipárgás, hogy minek az ide.
--
trey @ gépház
egy szavazást megér?:P
Ez nem csak egy szavazás eredményének kérdése. Ez - ha normálisan meg van csinálva - akkor pénzkérdés is, illetve technikai kérdés is, amibe nyilván be kell vonni Attilát is, mint az oldal alatti infrastruktúra üzemeléséért felelős személyt.
--
trey @ gépház
Mit jelent pontosan a normálisan meg van csinálva?
Én üzemeltetek (haveroknak) webszervert, ott a https-hez kellett egy picit konfigurálni meg a startssl-nél aláíratni a tanúsítványt.
Pénzben jelentkező költsége 0 volt. Időráfordítás kb két óra. A gépet nem kellett emiatt megváltoztatni (nincs akkora terhelés, nem kellett új IP cím).
Persze nem hasonlítható össze egy napi pár tíz látogatós oldal egy huppal, de kíváncsi vagyok, mit kellene neked máshogy csinálni, mivel jár, és persze mi az, ami ezekből pénzbe kerül.
> Mit jelent pontosan a normálisan meg van csinálva?
Gondolom, ha https, akkor http://drupal.org/project/certificatelogin is jó lenne.
Ez valami self signed megoldás? Ha nem, akkor hol adnak ingyen tanúsítványt?
--
trey @ gépház
www.startssl.com
nem self signed, hanem ők írják alá. Működik Firefox, IE, Android, Chrome meg egy csomó mással.
szerk: howto http://hup.hu/node/98658
A startsssl free tanusitvanyaval az a baj, hogy attol meg nem leszel hitelesebb, csak https-en at fog menni a forgalmad. Csak egy fokkal jobb a selfsigned megoldasnal.
--
nem is attol tartottunk, hogy trey nem is Micsko Gabor
arra teljesen jo lenne, hogyha wifin megnezem repterrol a hup-ot, akkor be tudjak jelentkezni vpn vagy egyeb trukkozes nelkul.
Tyrael
igen. Pont ez a cél, hogy https-en menjen a forgalom.
A hup hitelességét ebben a topicban eddig senki sem említette, mint hiányt.
A startssl egy evre ad ingyen cert-et, nem? Azt azert nem neveznem valojaban ingyenesnek... legalabbis en remelem a hup meg tovabb huzza ennel. ;)
evente meg kell ujitani.
mint ahogy fizetos certet sem tudsz venni az orokkevalosagra, tobbnyire 1-2 evre szoktak kiadni.
Tyrael
Rég néztem, de akkor a startssl (ami mögött valami izraeli moszad-fedőcég áll) ingyenes tanúsítványait ugyanúgy elhajtotta minden böngésző, mivel a kiállító CA certje egyikben sem volt meg.
Ez kb. a self signed kategória.
suckIT szopás minden nap! UCEPROTECT: ezek buzik
regen nezted.
a moszad fedoceg reszhez nem ertek, de gondolom hasonloan megalapozott es koruljart informacio.
Tyrael
> regen nezted.
http://www.mozilla.org/projects/security/certs/included/#StartCom
"Inclusion Date 2007-06-15"
akkor mar ezt is ideszurom, hogy egyhelyen meglegyen:
http://www.istartedsomething.com/20091010/microsoft-free-root-certifica…
Tyrael
És tényleg, cirka másfél éve már a patchelt windowsokban is benne van. Hogy szalad az idő, lehet, hogy frissíteni kellene az ie6-ot a windows xp-n?
De nem merem feltenni a genuine advantage baszt, mert akkor mi lesz.
suckIT szopás minden nap! UCEPROTECT: ezek buzik
es van arra valami publikus indok, hogy miert szunt meg ez a lehetoseg es mikor?
+1
Hogy mikor, azt a pöcsöm tudja. Évekkel ezelőtt. Hogy miért, arra feljebb a válasz.
--
trey @ gépház
Szerintem meg az egész internetet "le kéne ssl-ni" (TM).
Komolyra fordítva a szót:
http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_hijacking
http://en.wikipedia.org/wiki/Session_hijacking
----------------------------
színes ingyen domain domain
És igazából ennek milyen gyakorlati haszna lenne?
Attól tartunk, hogy pl. Sting egyik éjjel, miután megnézte a Mission Impossible első részét, a plafonról leereszkedik a szerverszobába, ráakaszt valami Windowsos lehallgató kütyüt a HUP-os szerver patch kábelére, kideríti az admin accountok jelszavait, és meghekkeli a Drupalt (bár ezt a részt inkább ki fogja szervezni, elég a saját CMS-ét érteni), hogy ezentúl csak prog.hu-s hírek jelenjenek meg rajta?
Vannak-e itt annyira értékes adatok, illetve keletkezhet-e az adatlopásból akkora kár, hogy megérje SSL-en keresztül (is) szolgáltatni? Szerintem nem.
Ha régebben ment, csak volt valami értelme, nem?
az oldal nagy látogatottságú -> sok emberhez lehet eljutni, ha bejuttatnak valami kódot, ami minden oldalon megjelenik.
Ennél sokkal érdekesebb, hogy a begyűjtött jelszavak (pl open wifi-n) mennyi más szolgáltatásnál is érvényesek. Tudom-tudom most majd beirja a sok okos, hogy ők minden egyes webes regjükhöz másik jelszót használnak, de a valóság nagyon más.
Terhelés ügyében egyszerű a dolog, külön login page kell és csak azt kell védeni, nem kell az oldal teljes forgalmát ssl-ezni.
Én az oldalakat is titkosítanám.
Volt a múltkor egy műsor a TV-ben, a stáb lehallgatott egy wifi kapcsolatot, aztán becsengettek a házba, és mondták az embernek, hogy tudják, hogy most vett repülőjegyet ide és ide, stb. És ha nem teszi védettebbé a wifijét, akkor lehet, hogy legközelebb amikor nyaralni megy, a betörők fogják tudni, hogy mikor nincs otthon.
Nekem sok fontos oldalon külön-külön pwgennel generált jelszavam van, de van számos nem fontos oldal, ahol valóban egy jelszó van mindenhol. Persze ezekért nem is kár igazán, de azért nem mondanám el boldog boldogtalannak.
Ezeken az oldalakon pl. OpenID-t szívesen használnék, és akkor mehet titkosítatlanul is akár az autentikáció.
Én nem látom sok értelmét a teljes oldal titkositásának, de persze, ha a hw birja, akkor miért ne. De ha nem birja, akkor jöhet, hogy csak a login van titkositva, azt gondolom elbirja.
A repülőjegy vásárlást azért nehezen lehetne idekeverni, ez egy - a PM-eken kivül - nyilvános oldal, aki ide leir olyan infot, hogy mikor nem lesz otthon és az is kiderül, hogy hol lakik vagy egyéb érzékeny info-t annak tökmindegy, mert az ssl bevezetése után is bárki elolvashatja ugyanezt az info-t. Itt az egyetlen érzékeny adat a jelszó és talán a PM.
Vannak feljebb példák.
jo hogy leirtad, mar en is akartam.
ha valaki megnyomna a hup-ot, es megszerezne az itteni adatokat (jelszavak, privat uzenetek, ki melyik ip-rol lepett be melyik userhez), akkor lenne hirtelen kapkodas, hogy hoppa, ugyanazt a jelszot hasznalom itt, mint az itt megadott email fiokomhoz, hopp, itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.
szoval egesszen addig lehet bagatelizalni a biztonsag kerdeset, amig valaki ra nem szan nehany orat/napot, es be nem nyomja az oldalt.
en itt jottem ra, hogy a hup.hu-n olyan jelszot szabad csak hasznalni, amit sehol mashol nem hasznalok semmire.
Tyrael
Ha te itt _bármilyen_ szenzitív adatod megadsz, az már régen fail. A részedről.
--
trey @ gépház
Nem is kell semmilyen ilyen jellegű adatot megadni. Elég ha felnyomják az oldalt.. Kíváncsi lennék ki használja ugyanazt a jelszót több helyre, netán mindenhova. Legalábbis nekem nincs kedvem 10+ karakteres jelszavakat megjegyezni.. Kettőt tudok aztán ennyi, ezeket használom különböző helyeken. A váltogatás azért néha megtörténik. Nincs szabályos időköz..
Tehát elég ha felnyomják az oldalt, megszerzik a jelszavakat és nagy eséllyel bejutnak az ember e-mail fiókjába meg még kitudja hova..
a jelszó számodra nem érzékeny adat.. ejnye vadász
lol.. Dehogynem.. De trey sem erre gondolt leginkább...
hanem?
az hogy a webre kiteszed névvel-dátummal hogy kezeled a jelszavaidat az pl micsoda? félsz hogy nem találod meg a macit és kiabálsz? :)
Tyra3l-től indult a dolog, ő inkább céges adatokat emlegetett.. ("itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.") Amit nem éppen túl jó ötlet se se privát üzenetekben se sehol máshol megadni. Tehát olyan dolgokat, amiket nem kötelező magadni.
Tehát erre jött az, hogy ezeknek a megadása fail.. :-)
Gyerekek, most komolyan. SMTP-n szenzitív adatokat? PM-ben egy weboldalon keresztül? Ki a rák tudja garantálni, hogy ezt az oldalt senki, soha nem nyomja fel? Vagy nyomta már fel? Senki. Erre kell felkészülni. Mondjuk azon, hogy valaki plain text-ben levelez a HUP-on keresztül, nem fog segíteni az, hogy az oldal SSL-t használ vagy sem...
--
trey @ gépház
a máshol használt jelszavad sem
"
- .. _bármilyen_ szenzitív adatod ..
- .. semmilyen ilyen jellegű adat ..
"
azaz a szövegértelmezésre próbáltam felhívni a figyelmed
Jó, de a jelszómegadás, mint olyan (kötelezően) a rendszernek megy és nem mondjuk egy üzenetbe.. Senki sem írná ki a jelszavát sehova. Tehát a szövegértésemmel nincs gond.
- trey azt írta "itt", az a hup rendszer a jelen körlmények közt, teljesen egyértelműen, ráadásul aztóta igencsak megerősítette ezt szóval nem értem mit nem értesz
- a másik ami fontos egy fórumon: a logika, azaz nem kell a másikat fárasztani olyan ellentmondással hogy szerinted jó lenne plusz biztonság közben meg jó hogy nem a jelszavadat írod le hozzászólásban
"Nem is kell semmilyen ilyen jellegű adatot megadni" - Akkor én fogalmaztam rosszul. A "megadás" alatt én adatkiadást értettem, ami nem a felhasználó azonosítására szolgál és szerintem mindenki más is. Úgy látszik tévedtem.
A jelszó beírása is valamilyen formában megadás, csak az elkerülhetetlen és ha titkosítod, akkor senki nem látja.
Tehát ezt is megadod, de nem úgy, ahogy más adatokat.
A jelszót meg kell adni, de csak a rendszernek.. Ez olyan adat, amit muszáj megadni, ellenben céges adatokat pm-ben kiadni emberi butaság...
igen, arra probaltam celozni, hogy a latogatok egy (az atlaghoz kepest talan nagyobb) resze tisztaban van az IT biztonsag idevonatkozo passzusaival, ennek ellenere biztos vagyok benne, hogy lehetne nagyon mokas dolgokat talalni, es meg a nagyhangu, magukat biztonsagban erzo emberek accountja korul is.
szemely szerint en ugy gondolom, hogy bar egy kocsma ruhataratol sem varom el, hogy a svajci bankokhoz hasonloan vedje a ra bizott ertekeket, de azert ne egy nyitott ablaknal levo fogasra legyenek felakasztva a kabatok, amit az ablakon benyulva barki elvihet.
egy ssl cert beuzemelese gyakorlatilag elenyeszo penz/energiabefektetest igenyelne, es mar egy kicsit jobban aludnank ejszaka.
szerintem
Tyrael
Hogy az oldal HTTPS-t használ, nem garancia arra, hogy nem törik meg az oldalt. Remélem ez azért tiszta. Bármelyik oldalt bármikor megtörhetnek. A HUP-nál sokkal nagyobb, sokkal nagyobb stábbal, sokkal nagyobb költségvetéssel, sokkal nagyobb és jobb szakembergárdával rendelkező oldalakat is megtörtek már. Tehát arra kell felkészülni, hogy itt az adatok nincsenek biztonságban. Ebből kifolyólag ide nem adunk meg szenzitív adatot.
--
trey @ gépház
igen, eppen ezert szamit manapsag az is alapnak, hogy nem taroljuk szerver oldalon plainben a jelszavakat, es sorolhatnam.
mert tudjuk, hogy nincs 100%osan biztonsagos rendszer, ezert nemcsak a behatolaselharitason dolgozunk, hanem a potencialisan okozhato kar minimalizalasan.
pl. mod_security sem veletlenul volt(van?) az oldalon.
szoval azt gondolom, hogy azert amit meg lehet tenni a biztonsag erdekeben, azt nem kellene ilyen ervekkel lesoporni az asztalrol.
Tyrael
Ne haragudj, de hadd kérdezzem már meg, hogy hol söpörtem le bármit is az asztalról? Egyelőre senki sem vetett el semmit. Annyit mondtam, hogy egy internetre kötött gép sosem életbiztosítás és SSL ide vagy oda, nem kell ide megadni éles e-mail címet (jó a freemail is csak éljen), nem kell ide megadni jelszónak a bankkártya PIN-t (senki se kéri, teljesen jó egy apg-vel generált random jelszó). Ha ez be van tartva, akkor semmilyen számodra értékes dologhoz nem lehet az oldalon keresztül hozzájutni. Azt hittem, hogy ezek széles körben ismert dolgok...
--
trey @ gépház
nem azt mondtam, hogy lesoported, hanem azt, hogy nem kellene lesoporni.
a valaszaidbol abszolut ugy latszik, hogy probalod bagatelizalni a hup-pal kapcsolatos biztonsagi problemakat.
lasd itt meg itt
az hozzaszolasod masodik felerol a velemenyem itt leirtam
Tyrael
Nem bagatelizálom, hanem reálisan gondolkodom. Nyilvánvalóan nem tudom garantálni 100%-ban (ki tudja?), hogy sosem férnek hozzá az adatokhoz. A legjobb szándékom ellenére sem. A legjobb amit ajánlhatok, hogy senki sem bízza szenzitív adatait az oldalra.
Egyébként, csak neked, még egyszer: Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj. Viszont itt szeretném újra megjegyezni, hogy baromi sok minden ellen NEM VÉD. Ezért (sem) nem kell ide megadni semmilyen fontos adatot.
--
trey @ gépház
> Nem tetszett mindenkinek. Azóta nincs.
Lehet én nem értek valamit, de akinek nem tetszik az nem használja, nem? Akinek meg kell az meg belép https -el.
---------------------------
Oszt jónapot!
http://hup.hu/node/99793#comment-1231490
"mert tudjuk, hogy nincs 100%osan biztonsagos rendszer, ezert nemcsak a behatolaselharitason dolgozunk, hanem a potencialisan okozhato kar minimalizalasan."
korkorosen ervelsz, szerintem hagyjuk abba.
Tyrael
Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában. A felelősség az adataidért nem csak az enyém, hanem a tiéd is. S valóban, abbahagyhatjuk.
--
trey @ gépház
"Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában."
igy volt eddig is, igy lesz ezutan is (remelem ez a mondatod nem azt jelenti, hogy amit irtam egyes szam elso szelyben peldat, azt te ugy ertetted, hogy tenyleg en irogatom pm-ben az oldalon, hogy melyik munkahelyemrol loptam adatot. :P )
"A felelősség az adataidért nem csak az enyém, hanem a tiéd is. "
nyilvanvaloan.
over and out
Tyrael
> probalod bagatelizalni a hup-pal kapcsolatos biztonsagi problemakat.
Nem csak a hup-ról eshet szó; próbáltad már a https://prog.hu -t, https://pcforum.hu -t ? ;-)
mostanaban nem nagyon.
de persze lehet hogy 10 eve volt ott is. :)
Tyrael
lehet hogy https nem mukodik ezen a ket oldalon, viszont az elveszett jelszavadat elkuldik mailben ha kered, mert megvan nekik plaintextben. Sting szerint ez biztonsagi szempontbol teljesen rendben van. Aranyos.
Ez nem bank. Közösségi oldal. Egy bizonyos szint felett nem lesz egyensúlyban a védelembe fektetett energia és a haszon.
A jelszavadért pedig ne aggódj, rendesen hash-olva van az adatbázisban.
"A jelszavadért pedig ne aggódj, rendesen hash-olva van az adatbázisban."
Jaj.
És az mit segít rajta, ha a hálózton meg plaintextben megy át?!
Legalább ha a szervert törik meg, nem kerül ki.
------------------
My Open-Source Android "Projects"
és az mit segít egy jelszón, ha hashelve van letárolva?:P
Kell még egy google keresés a visszafejtéséhez (ha nincs sózva).
suckIT szopás minden nap! UCEPROTECT: ezek buzik
Azért annyit kinézek a Drupal-ból hogy valami "globális" só van. Nem, nem néztem meg a forrást és igen, próbáltam már jelszavakat átemelni két Drupal installáció között és ment.
Szerk. Ledöbbentem. A sós kijelentésemet visszavonnám, kíváncsiságból utánanéztem a dolgoknak és úgy néz ki, plain md5-ben tárolódnak a jelszavak.
A mysql_real_escape_string legyen velünk! :)
A drupalt íróknak is meg kellett tanulniuk valahol a php-t...
suckIT szopás minden nap! UCEPROTECT: ezek buzik
Pedig a mai jelszomegjegyzos-OpenID-s vilagban viszonylag kis problema a jelszo. Az itteni jelszavammal sokra nem menne, mert azt masutt nemigen hasznalom, es ahol lehet, OpenID-vel regelek. Ettol mondjuk lehetne felnivalom, amennyiben az OpenID szolgaltatomat feltorik, de az a sejtes, hogy egy olyan pici kis ceg, mint a Verisign, hallott mar a biztonsagrol, es talan - talan! - kepes arra, hogy megvedjen engem a nagy es csunya internettol.
--
külön login page kell és csak azt kell védeni, nem kell az oldal teljes forgalmát ssl-ezni
Sajnos ennyire nem egyszerű a helyzet. Ha csak a login page van ssl-en, akkor ugyanúgy meglehet szerezni MITM a user/pass-t. Nem véletlenül állt át a Google sem a teljes https gmail-re.
facebook is elindult ebbe az iranyba.
es meg ha nem is csinal mitm-t a tamado, a session-t sima sniffelessel is ki tudja olvasni nem https-es keresekbol.
Tyrael
sessiont lopni valóban könnyű ebben az esetben, de a jelszót igy nem lehet megszerezni.
legalabbis ha jol van megirva a webapp.
ha a jelszo modositasnal ott van a regi jelszo egy password tipusu input mezoben, akkor mar meg is van a jelszo.
ha lehet email cimet modositani jelszo megadasa nelkul, es az elfelejtett jelszo kuldes feature kikuldi az email cimre a regi jelszot plainbe, akkor megint csak buko.
Tyrael
MITM ellen az SSL egyáltalán nem védett. Hogy egy egyszerű példát mondjak már az ősrégi ISA server is képes volt ezt megcsinálni, beékelődött a kliens és a szerver közé és szépen eljárt a kliens nevében a szerver felé, majd az egész titkositott forgalmat pont ugyanúgy elemezte, loggolta, szűrte mint a nem titkositott kapcsolatot.
hat pedig ehhez az kellett imho, hogy az ISA-nal telepitve legyenek a private+public kulcsok, anelkul nem fogja tudni szetszedni majd osszerakni a https forgalmat.
persze ha csak halozati szinten forwardol, ahhoz nem kell tudni ertelmezni az alkalmazasretegben levo titkositott forgalmat, de akkor az nem is sikeres MITM.
szerintem.
kicsit maskeppen fogalmazva: ssl-lel vedett weboldalaknal is be tudsz ekelodni a kliens es a szerver koze halozati szinten, de a public kulcs nelkul nem tudod irni/olvasni a https-ses uzenetvaltasokat.
persze a forgalmat el tudnad terelni(manipulalod a nevfeloldast, vagy a tenyleges kiszolgalast), de ha en mint kliens https://hup.hu -t kerek a bongeszombol, akkor neked https-sel kell valaszolnod, kulonben a browserem elszall hibaval, ha pedig https-sel valaszolsz, akkor a cert amit kuldesz nem lesz megbizhato/valid ahhoz a domainhez. (persze ha elloptad a hup-hoz tartozo private kulcsokat, akkor mukodhet az is, de akkor mar a hup-ra is telepithettel volna valami malware-t)
Tyrael
Nezd a pszichologiai oldalat. Ha jol csinalod meg a MITM appot es csak olyan szolgaltatashoz telepited ahol csak a forgalom titkositasara hasznaljak es nincs cert. auth (mint a webes szolgaltatasok nagyon donto hanyada), akkor csak egy olyan certre van szukseged a kliensek fele amelyik valamelyik nagyobb cert kiadonal lett beszerezve, h a chain-t a bongeszok hitelesnek fogadjak el es ne rinyaljanak erte. Innentol kezdve tied a forgalom, mert a kutya sem fogja ellenorizni, h az adott https kapcsolatot milyen certtel epitettek fel. A magyar parlament IT szekcioja is csak ezen a bananhejon csuszott el. :)
---
pontscho / fresh!mindworkz
nekem ez volt a kedvencem:
http://www.thoughtcrime.org/ie-ssl-chain.txt
Tyrael
És ezt hogyan? Ahhoz, hogy a titkosított forgalomba bele tudjon nézni, vagy az kell, hogy ismerje a titkosításhoz használt kulcsot, vagy az, hogy a klienst rávegye, hogy ne a szerver számára titkosítson, hanem a középső ember számára.
Az elsőre, hogy neki megvan a szerver privát kulcsa, gondolom nem sok az esély.
A második akkor mehet, ha a kapcsolat felépülésekor a kliens számára ő jelentkezik be, mint távoli oldal, és a kliens megbízik a középső ember által mutatott tanúsítványban. Pl. a felhasználó elfogad egy self.signed certet, vagy mondjuk egy cégnél minden kliensen rajta van egy olyan CA kulcsa, amivel aláírt mindenre illeszkedő tanúsítványt mutat a céges proxy a kimenő kapcsolatokon.
Szóval hogy kell ennek a kivitelezését elképzelni mondjuk egy olyan helyen, ahol a rossz szándékú ember egy wifi hotspotot üzemeltet, és a beállított infrastruktúrával monitorozni akarja a felhasználók forgalmát? Mondjuk banki belépési adatokat akar lopni.
Csak egy, a user által megbiztott cert kell hozzá. Ez vállalati hálózaton alap dolog, de nem túl komoly összegért amúgy is beszerzhető. Érdemes rákeresni az ssl mitm-re, elképesztő mennyiségű tool van ilyesmire, nem véletlenül...
A céges gépre előtelepített céges cert az egy dolog.
De publikus helyen, saját géppel nem értem, hogy működne.
Amiket találtam google-lel, SSL mitm proxy pl. az on the fly generál self signed tanúsítványt.
Na de egy böngésző egy self signed certre rögtön kiabálni kezd, tehát már bukott is a dolog...
Lehet, hogy van más megoldás is, de nem láttam 5 perc keresés alatt.
Szerinted meddig tart lecserelni azt a self-sign certet egy olyanra amit egy bongeszo kapasbol elfogad es nem sir be ra? :)
---
pontscho / fresh!mindworkz
ha te tudsz olyan certet(es hozza tartozo private kulcsot) gyartani, amit akar csak egy major bongeszo is elfogad mondjuk a paypal.com -hoz, akkor miert nem vagy meg milliomos?
Tyrael
Én nem tudnék ilyet gyártani, és eddig nem hallottam arról, hogy könnyen lehetne.
A fent javasolt google keresés 5 perc alatt nem hozott ilyen találatokat.
Esetleg egy URL-t küldhetnétek, hogy legalább azt lássam, hogy van ilyen, és megértsem, hogy működik.
(Az 5-ös és 6-os IE-ben levő hibát láttam, de tegyük fel, hogy friss és többféle böngészővel jönnek a felhasználók).
Itt egy két helyen látva, többek felbuzdulását azért halkan hozzá tenném, nem biztos hogy az SSL minden esetben jó megoldás. Gondoljunk bele abba, hogy van egy alkalmazás szintű tűzfalunk, ha titkosítjuk a csomagokat, akkor a tűzfalunknak fogalma se lesz arról hogy mi van a csomagban, hanem szimplán tovább engedi. Nyilván ez is kiküszöbölhető.
Más különben úgy gondolom, ha valaki lopni szeretne vagy betörni, akkor annak több módját is választhatja. Ugyanis önmagában a tűzfal semmit se ér. Minimális védelmet ad! Mi döntsük el hogy mi megy be és mi jön ki, csak is rajtunk múlik, és azon hogy felismerjük-e hogy valaki, megpróbál bejutni hozzánk. Ehez elég egy olyan oldalra ellátogatnunk, vagy egy régebbi verziószámú böngészőt használnunk. De megfúrhatjuk mások wifi-jét bejutva a belső hálóra, és onnantól kezdve miénk a pálya.
Összegezve ezzel csak annyit akartam mondani, ha valaki be akar törni vagy elakar lopni valamit, és az a személy ért hozzá, az meg is fogja tenni.
[Szerk.:]Ja igen, ha valaki adott felhasználó adott jelszavát akarja megszerezni, nem biztos hogy a szervert támadja meg, úgy gondolom, sokkal könnyebb egy mezei user gépére betörni, mint egy "jól" tehát jól konfigurált szerverre.
WAF nyilvanvaloan a ssl mogott van, vagy ha nem, akkor rendelkezik a kulcsokkal, hogy bele tudjon halgatni a forgalomba, ez minden WAF-nal megoldott.
a tobbivel kapcsolatban:
igen, minden rendszert fel lehet nyomni kello agykapacitas es ido, penz birtokaban, nem mindegy azonban, hogy mennyire nehezitjuk meg a tamadok dolgat.
a formalis kockazatelemzes segitsegevel ki lehet szamolni, hogy mi az a raforditas az IT biztonsagra, ami meg megterul. nyilvanvaloan itt nem fog trey egy teljes kockazatelemzest vegezni, hanem kb. zsigerbol eldonti, hogy mi az ami meg megeri neki. ez igy egy modszer
nyilvanvaloan a hup-nak nem felelossege a felhasznalok desktopjainak vedelme, tehat bar ez egy erdekes es kevesse koztudatban levo resze a temanak, de itt offtopic.
Tyrael
Hadd kérdezzem meg, nem kötekedés képen, csak érdeklődés szinten, a téma iránt. Te mióta foglalkozol IT biztonsággal? Esetleg milyen tapasztalataid vannak, és milyen megoldásokat tudnál felsorolni egy szerver védelme érben, főleg a szoftveres védelmi eszközök és megoldások érdekelnének, de ha tudsz olyan hardveres eszközt mondani, amit egy magamfajta user is megtud venni, mert nem méreg drága (nem a routerre gondolok), akkor légyszíves írj pár sort ezekről.
webfejlesztokent dolgozom 5. eve foallasban, regota erdekel a tema, de nem tartom magam igazi expertnek, nem ez az elsodleges szakiranyom, de azert mar lattam jo/rossz rendszert mindket oldalrol (mint fejleszto, illetve mint "tamado").
a docler akademia keretein belul volt egy eloadasom a temaban, ha gondolod nezd meg a slideokat, vagy a videot (regisztracio, belepes szukseges a video megtekintesehez).
http://www.slideshare.net/Tyrael/biztonsgos-webalkalmazsok-fejlesztse
http://www.doclerholding.com/hu/academy/4/
a kerdesed igy nagyon tag, igazabol az implementacio a konkret rendszerttol fugg, az elmeleti alapok szerintem benne vannak a slide-ban, bar elsosorban fejlesztoi peldakra kihegyezve.
amugy az alapok ma is ugyanazok, mint regen, tudd hogy mit vedesz, kitol, a biztonsag ne utolag hozzaadott eszkoz legyen, hanem a rendszer kialakitasanak minden dontesenel figyelembe vett szempont.
a leheto legkevesebb szukseges szolgaltatas a szamukra szukseges leheto legkevesebb prioritassal fusson, egymastol leheto legjobban elszeparalva.
folyamatosan monitorozzuk a rendszerunk mukodeset, mivel akar egy eszrevetlenul vegrehajtott betorest is lefulelhetunk azaltal, hogy mondjuk megugrik a halozati forgalom egy olyan szegmensben, ahol ez nem jellemzo, etc.
legyen megfelelo audit trail, hogy kesobb visszakovethetoek legyenek akar a sikeres/sikertelen tamadasok, akar csak az, hogy ki dobta el az eles adatbazist.
ehhez ugye szukseges, hogy ne legyenek kozos accountok a rendszerben, illetve nem art, hogyha a kritikus muveletekhez 1-nel tobb embernek a jelenlete/jovahagyasa kell, ezaltal akar megoldhatoak a "who watches the watchmen" jellegu szituaciok (ertsd, ha az egy szem rendszergazda rossz utra ter, akkor nincs senki aki kiszurna, vagy megakadalyozhatna az ugykodeseben)
ja, es persze kepezzuk a dolgozokot, nagyon fontos kialakitani egy olyan dolgozoi paranoia-t, hogy jelszot sosem ker tole senki, es ha megis, akkor jelentse a felettesenek, etc.
ps: aki szemelyeskedeshez keresi a toltenyeket, az is nezze meg a videot, aztan lehet fikazni, hogy izgulok, meg neha nem a legjobb az angol kiejtesem. :P
Tyrael
Nagyon szépen köszönöm az információkat, én webprogramozónak tanulok, mindenképpen érdekesnek és fontosnak tartom a témát. Ha van még hasonló hasznos dokumentációd, információd, szívesen fogadom. Köszönöm még1x
Az előttem szólóhoz csatlakoznék.. jó az anyagod, köszönet érte.
Egyébként meg óvakodni kell a magukat expert-nek nevezőktől hidd el, mert X év után is, nem árt néha újra olvasni az alapokat.
Egy dolgot hiányoltam az anyagból, de lehet a video-n rajta van (meg fogom nézni), hogy sok támadás típusnál nem volt konkrét
példa, de nyilván ez nagyon nagy munka (lett) volna.
1. "Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj."
2. "Lehet én nem értek valamit, de akinek nem tetszik az nem használja, nem? Akinek meg kell az meg belép https -el."
->
Mi az akadalya annak, hogy legyen mindketto? Miert megy azon az erolkodes hogy A vagy B, mikor nem egymast kizaro opciokrol van szo?
De valoszinu en nem ertem.
"Mi az akadalya annak, hogy legyen mindketto?"
Gyakorlatilag semmi. De ez nem rajtunk múlik és Trey-nek is konzultálnia kell egy "feljebbvalójával"..
Én is használok olyan oldalakat, ahol be kell pipálni a "Biztonságos bejelentkezés (HTTPS)"-t és nem tartom rossz ötletnek. :-)
Ruhellem magam idezni, de veled kivetelt teszek:
"Lehet SSL, nekem nem fáj."
Szerintem egy ("belepes titkositott csatornan") pipa belefer, aki akarja hasznalja, aki akarja nem. Igy belefer akar egy self signed tanusitvany is. Ha olyan helyen ulok, hogy titkositas mentes wifi es tenyleg felek, hogy a mellettem ulo vezna srac, 3 hetes szorrel az arcan, hacker matricas laptopjaval elfogja lopni a jelszavaimat, akkor inkabb en is bepipalom es a tanusitvanyt is telepitem. Majd dolgom vegeztevel ranyomok a kilepes gombra es ennyi. Nem kotelezove teve, de elerhetokent szerintem lenne helyen, meg ha ilyen megoldasban is.
A lenyeg szerintem a lehetoseg megadasaban van, ha tenyleg szuksegesnek latom. Aki meg akarja hasznalni, telepitheti a cert-et is.
De van egy csomó ingyenes cert is. Valahol már tárgyaltuk a hup-on.
Ahogy beleolvastam mindenki a bejelentkezés miatt tartja fontosnak.
Akkor legyen csak a bejelentkezés https-en!
Egy időben a gmail is így működött. Most már ahogy nézem full https lett.
maskor olvasd vegig a szalat.
hint: http://hup.hu/node/99793#comment-1231791
ps: megcsinalni kb. ugyanannyi melo hogy csak a login legyen https, mint hogy minden.
cpu-ban/bandwith-ben lehet elteres, de szerintem 5-20% hasznalna szerintem csak az ssl-t, az meg nagysagrendileg nem novelne meg annyival, hogy ne erne meg megcsinalni.
Tyrael
:(
Hát ezt benéztem.
Mielőtt beleszólsz, érdemes lenne nem csak beleolvasni, hanem átolvasni az egészet.
Miért legyen csak a bejelentkezés https-en? Mi a gond azzal, ha más is https-en megy?
G
Arra gondoltam hogy terhelést jelent, de tényleg inkább a tanúsítvánnyal járó nehézségek nagyobb súlyú érvek.
De igaz, pont nem olvastam el ezt a részt. Bocsi.
Felesleges. Legyen OpenID belepesi lehetoseg, es van olyan OpenID szolgaltato, aki konkretan OTP bejelentkezest intez. Ezt nem surun lehet uberelni.
--
+1 az OpenID-nek (amivel ráadásul az OTP is megoldódna, mert van olyan szolgáltató, aki támogatja)
Ha mégis esetleg saját https bejelentkezés lenne, akkor nehogy úgy legyen mint a freemail kapuja, ahol akkor lopom el a jelszót amikor akarom. Ha nincs keret teljes https-re, akkor a szegény ember dupla bejelentkezése a megoldás: sima http-n biztonságos bejelentkezésre kattint, átmegy https bejelentkező oldalra és ott írja be a jelszót, majd auth után vissza http-re. Tényleg elég lenne csak a jelszót levédeni, mert ez veti fel a legtöbb biztonsági problémát. Szerveren pedig egyedi salt mindenkinek + SHA.
Ja és cirkuszt és kenyeret! :)
En azt gondolom, hogy egy apache-nak baromira mindegy, hogy egy oldalt, vagy egy komplett site-t szolgal ki https-en, ebbol a szempontbol nem erzek problemat, hogy a komplett oldal menjen https-en. Az igazi koltseg maga a cert, amit azonban legfeljebb 1 domainre kell megvenni (hup.hu), tehat semmi specialis nincs benne (nem merul fel pl. a wildcard vagy nem wildcard kerdes).
--
https-ses forgalom kicsit tobb eroforrast igenyel (tobb tcp uzenetvaltas megy, illetve minden tartalmat oda-vissza titkositani kell az atvitel soran), de szerintem megeri a befektetett energiat.
Tyrael
Pontosan, es nem gondolnam, hogy a gepnek ez tulzottan nagy tobbletterhelest okozna (ertem ez alatt, hogy nem kell emiatt uj szerverre gyujtsunk).
--
http://serverfault.com/questions/43692/how-much-of-a-performance-hit-fo…
persze nagyon sok fugg az adott szerver profiljatol (a dinamikus oldalak rendereleset nem dobja meg szazalekosan annyira a plusz ssl handshake, meg encryption, valamint pl. bekapcsolt KeepAlive-val lehet eleg sokat sporolni a handshake-bol fakado halozati ping-pong-on.), de ha teljes site-ot rakod ssl ala, akkor akar eleg jelentos overhead-je is lehetne.
ettol fuggetlenul szerintem megeri.
Tyrael
és ugye ingyen megkapható
Igen, vagy nem, attol fugg, mennyire akarunk igenyesek lenni. De az ara semmikeppen sem fugg attol, hogy hany oldalt-aloldalt akarunk alarakni, ezt akartam kihozni.
--
Manapság, amikor a session-lopások gyakoribbá válnak a jelszó lopásoknál, ennek nem hiszem, hogy túl sok értelme lenne. Talán már idecitálták, de úgy tűnik nem lehet elégszer:
http://en.wikipedia.org/wiki/Session_hijacking
és a top 10 kockázatok között többször is szerepel az ilyen vagy olyan session-lopás:
http://www.owasp.org/index.php/Top_10_2010-Main
Ettől függetlenül nem szabad figyelmen kívül hagyni, hogy a https igazán egy területen nyújt kiemelkedő védelmet: a nyílt, titkosítatlan wifi hálózatok használata esetén. Normál otthoni DSL-t vagy kábelt sokkal nehezebb lehallgatni. Ezeken túl még számtalan módon meg lehet támadni egy oldalt, illetve annak felhasználóit. A legtöbb felhasználó esetén valószínűbb a számítógépének a fertőzöttsége, mint a lehallgatása (persze ez talán nem igaz a HUP közösségére).
Ettől függetlenül én a https bevezetésére szavaznék, még ha csak olyan high-performance konfigurációban is, mint pl. a Facebook (RC4_128, MD5, RSA_1024).
És a StartSSL tökéletesen megfelel erre a célra ingyenesen. Nem kell telepíteni a böngészőkbe semmit, alapból ismeri mindegyik. Én is használom zárt adminisztrációs és statisztikákat biztosító oldalakhoz.
Igazad van, talán olvastam is, csak nem gondoltam végig.
Arra gondoltam, hogy a fórum üzeneteket felesleges titkosítani, egy terhelt szerver esetén biztos rádob egy konstans szorzófaktort.
De valóban, ha megszerzik a session-t akkor megváltoztathatják a jelszót, és így ott vagyunk ahol a part szakad. Jobb megoldás kell. :)
Kicsit kifejtened, hogyan lehet sessiont lopni, ha az egesz forgalom ssl vedett?
Ha az egész akkor nem, az én hozzászólásomra reagált. Csak bejelentkezés
En is ezt vettem le, de aztan ez a mondat elbizonytalanitott: "a https igazán egy területen nyújt kiemelkedő védelmet" :)
Ez azt akarta jelenteni, hogy titkosítatlan, nyílt wifi hálózat esetében elég ha "odaülsz" egy notebook-kal, de próbáld meg lehallgatni pl. az én otthoni forgalmamat! A kettő nem ugyanaz. Nem lehetetlen, de sokkal nehezebb megfelelő pontot találni.
feltéve ha idézőjelben "bízik" az ember a drupalban és a kliens [felhasználó] gépe tiszta, akkor kizárólag HTTPS-t használva hogyan lehet sessiont lopni? - mármint csak érdekel, nem b*sztatásból
szerk.: jaok
Nekem válaszolt!
És ha a jelszó változtatáshoz kell az eredeti jelszó?
Akkor az már úgy nem is olyan egyszerű!
Mert ha ellopják a hup-os session-ömet az senkit nem érdekel.
A jelszó a lényeg.(szerintem)
A keyloggernek is mindegy a jelszavad.
Figyuzzatok ide duma-bercik:
- tegyél ki egy ssh-t és nézd meg mit csinálnak vele az oroszok és a törökök...
Többet ér mint akármilyen suli, és tanulj meg ellene védekezni.
ennyi, csapó
:)))
keylogger esetében tényleg mindegy hogy a HUP bejelentkezés https-en van-e vagy sem. Mondjuk nekem is mindegy, mert nem használok wifit(pláne más wifijét), a szolgáltató meg nem jelent akkora kockázatot hogy foglalkoznom kelljen vele.
És ha megtörik a tükörservert, te meg letöltöd.
/update/
Tehát https párti vagy.
Akkor hogy jött ide a keylogger?
Nem kifogásnak szántad?
Csak arra próbáltam rávilágítani, hogy a protokoll teljesen mindegy. A hátsó kapu a lényeg.
Szerk:
jelen esetben
Keylogger ellen OTP segítségével lehet védekezni. Egyébként akit érdekel a téma az nézze meg szoftveres keyloggerrel mondjuk a CIB bejelentkezést és csodálkozni fog azon, amit lát. Ezen kívül hatezer mód van keylogger ellen védekezni (virtuális billentyűzet, logika vizuális jelszavak, stb..). Passzív támadást ma már nagyon könnyen ki lehet védeni. Célzott aktív támadásra pedig védekezzenek csak a bankok out of band channellel.
Megnézem mi ez az OTP, de a keylogger nem azt jelenti hogy kb megszerezték a "terminálomat", és tulajdonképpen azt csinálnak rajta amit akarnak, akár kernel modulokat is? De jó nem kötekedem, olvasok.
Szerk:
"OTPs are difficult for human beings to memorize. Therefore they require additional technology in order to work."
Jahhogy így más. :) Hát nekem nincs ilyen additional technology izém. :)
Kifogás2:
Jó de ha valaki annyira tart attól hogy meg van törve a "terminálja", hogy külön eszközt használ a bejelentkezéshez(Ez valami USB-s kütyü?). Akkor attól nem tart hogy ellopják a session-jét is? Akkor ezzel az erővel ezen a "kölön eszközön" kéne intézni a banki átutalást is, de akkor már ez egy laptop tudású gép.
Na igen. Évek óta tuningolt ssh beállításokkal üzemelünk, és ami a legfontosabb, nem a 22-es porton. Meg ugye vannak egyéb dolgok is, amit el lehet követni a védelem erősítésének érdekében. De ez nem ide tartozik.
OTP-hez elég egy Java ME képes mobil is.
CIB felülete billentyűleütéseket szimulál és ha csak hookolsz nem tudod megkülönböztetni a felhasználó és a gép által szimulált leütéseket (driver szinten kell dolgoznia a keyloggernek vagy hardver kell), így a jelszót sem tudod megszerezni így.