Napad s posrednikom, znan tudi pod imenom MITM (man-in-the-middle) napad, je posebna oblika napada, kjer napadalec skuša "prisluškovati" šifriranemu prometu med žrtvijo in spletnim (ali drugim) strežnikom. Deluje tako, da napadalec preko sebe preusmeri ves promet do nekega https strežnika, žrtvi podtakne lažen SSL certifikat, promet pa nato dešifrira in pošilja dalje do pravega strežnika.
Vendar pa se je do sedaj napade s posrednikom dalo zaznati na relativno enostaven način. Ker naj bi izdajatelji SSL certifikatov preverili identiteto oseb, ki se predstavljajo za upravitelje varnih spletnih strani, napadalec ne more dobiti s strani zaupanja vredne strani (tim. Certificate Authority) podpisanega certifikata. Zato je prisiljen izdati samopodpisan certifikat, kar pa sodobni spletni brskalniki zaznajo in o tem izpišejo ustrezno opozorilo.
A kot je ugotovil Eddy Nigg, je mogoče zaobiti tudi to prepreko. Nekateri ponudniki SSL certifikatov, npr. podjetje Comodo, namreč v želji po pridobivanju novih strank izdajajo začasne, 90-dnevne brezplačne certifikate, pri tem pa ne preverjajo identitete prosilca certifikata.
Ker Comodo ne preverja identitete prosilca certifikata, je postopek za pridobitev lažnega certifikata otročje preprost. Najprej je potrebno zgenerirati lažno CRS (Certificate Request) datoteko, vsebino datoteke pa nato preko spletne strani pošljemo izdajatelju certifikatov Comodo in v naslednjem koraku že brezplačno dobimo lažni certifikat.
Pri tem seveda lahko napadalec vpiše celo lažen oziroma neobstoječ (preverjeno!) e-naslov, paziti mora le, da s pomočjo posrednika (proxya) ali anonimizacijskega omrežja Tor zakrije svoj pravi IP naslov.
V primeru, da bo sedaj napadalec pri napadu s posrednikom uporabil takšen certifikat, spletni brskalnik žrtvi ne bo izpisal nikakršnega opozorila glede (ne)veljavnosti SSL certifikata.
Ker sistem podpisovanja certifikatov predvideva zaupanje v tim. zaupanja vredno tretjo stranko (Certificate Authority - CA), enostavne obrambe pred zlonamerno ali malomarno zaupanja vredno tretjo stranko ni. Ena možnost je, da razvijalci spletnih brskalnikov ob naslednjem paketu varnostnih popravkov takšno organizacijo odstranijo iz seznama zaupanja vrednih CA-jev, druga možnost pa je, da uporabimo dodatek za Firefox Petname Tool, ki uporabnikom omogoča, da za vsako SSL šifrirano spletno stran sami določijo ali ji zaupajo ali ne.
Pa sej, a ni smiselno dat (v primeru bancnega poslovanja) pod zaupno vredno stran direkten link, ostalo se pa ne uposteva? Katerikoli ostali request pa takoj iz tega izpade (oziroma je ocitno sumljiv), po moji laicni logiki, ali pa pac ne?
Huelz, kaj je zate direkten link? Certifikat pripada domeni, ki jo s ciljnim IP naslovom poveže DNS strežnik, ki ga je prav tako možno napasti in prepričati, da daje napačne odgovore ... (Ne pravim, da je to lahko, ampak če se splača, se pač splača ...)
Sranje. Takega providerja bi morali takoj dati s seznama na neko sivo listo in opozoriti vsakega userja, ki bi hotel imeti karkoli s kom, ki ima njihov certifikat !
V imenu osebja Partis se opravičujem avtorju prispevka za nevšečnost. Novica je bila nemudoma ob opozorilu izbrisana, reporter pa opozorjen in ustrezno sankcioniran.
To za varnostne kroge sploh ni novica, temveč žalostno dejstvo, ki se ga zavedamo že desetletje in več. Večina trenutno najbolj znanih overiteljev digitalnih podpisov sploh ne jamči istovetnosti lastnika, razen v primeru t.i. EV overitev. EV overitve pa so nesramno drage, ker gre pri njih za vse značilnosti kartelnega dogovora.
Morda je potrebno pri drugih za pridobitev overitve preskočiti več obročev, vključno s plačilom za to storitev, vendar pa je končen rezultat vedno znova enak: kriminalci lahko vedno pridobijo podpise, ki jih velika večina brskalnikov prizna kot veljavne. Podjetja, ki pa v svoje produkte (Opera, Microsoft, Apple, Sun, ...) vpišejo začetni seznam korenskih overiteljev, pa za ta vpis pobirajo mastne denarce.
Tudi pri Verisign-u se je še do nedavnega dalo pridobiti overitev v kateri je bilo za lastnika navedeno "Microsoft Nekaj", ali pa "Bank of Americas nekaj".... Izvorno zlo pa je, da velika večina današnjih uporabnikov misli, da takšne overitve zagotavljajo ne samo, da smo prišli na pravi strežnik z naslovom "www.podjetje.com", temveč da je ta strežnik tudi dejansko v lasti Podjetja d.o.o. Vsa ti overitelji pa pridno prodajajo podpise v katerih niti pod razno ne jamčijo česa takšnega. Prvo zagotovilo propade zato, ker lahko kdorkoli pridobi digitalni podpis za isto domeno, vendar pa od drugega overitelja. Drugo zagotovilo propade zato, ker je možno za ime lastnika digitalnega podpisa vpisati skoraj karkoli.
Hipotetičen primer: NLB se odloči registrirati domeno www.pocenikrediti.si. Za domeno pridobi digitalno potrdilo, ki to ime domene poveže z imenom "Nova ljubljanska ...". Nekdo tretji registrira domeno www.pocenikrediti.com. Za domeno pridobi digitalno potrdilo, ki to ime domene poveže z imenom "Nova ljubljanska ...". Kako naj sedaj uporabnik ve, da prva domena je v lasti NLB, druga domena pa ne? Iz DNS imena ni videti ničesar. Gledati logotipe in besedilo na spletnih straneh je b.v. V obeh digitalnih podpisih piše "Nova ljubljanska ...". Razen tako, da kontaktiraš NLB, verjetno sploh ne obstaja način, da ugotoviš dejansko lastništvo, ali pa obstoj MITM napada.
To pač razgali vso neučinkovitost današnjega gozda X.509 PKI dreves. Tehnično so zadeve sicer čisto razumljive, vendar pa sistem ni dorasel čisto realnim, vsakodnevnim pričakovanjem tistih, ki bi radi enostavno in varno uporabo medmrežnih storitev. Na žalost ima preveč lukenj, implicitna mreža zaupanja v takšnem gozdu pa ne zagotavlja tistega, kar bi uporabniki dejansko potrebovali.
Za tiste, ki se jim da še več brati: zanimiv povzetek je tukaj, v njemu pa je tudi povezava na javno debato.
Posledice trenutnega stanja pa so...
Takega providerja bi morali takoj dati s seznama na neko sivo listo in opozoriti vsakega userja, ki bi hotel imeti karkoli s kom, ki ima njihov certifikat
To bi morala narediti podjeta, ki razvijajo programsko opremo (Microsoft, Apple, Sun, ...). Ta pa za vpis takšnega ponudnika večinoma zahtevajo kar lepo plačilo. Torej nimajo nikakršnega interesa, da bi ga umaknili iz seznama.
Se je kar za zamislit, kako se dodeljuje pravica izdajateljem certifikatov
To ni neka pravica, ki se bi dodeljevala. Podjetje plača in pride na t.i. seznam "zaupanja vrednih". Glede na to, da se ta "pravica" plačuje, je to navaden poslovni dogovor, ki koristi obema stranema, stranke pa pri temu vedno potegnejo krajšo.
Kaj pa če bi Comodo takoj preklical vse svoje 90-dnevne certifikate in ne izdajal več novih
In zakaj bi imel Comodo interes storiti kaj takšnega? Kdo ali kaj ga bi lahko v to prisililo?
No, sej sem rekel že ko sem prvič slišal za digitalne certifikate...brez veze, da jih imamo. Obstajat bi morali samo državni certifikati, kot je od sigen-ca, vse drugo nima nobenga smisla.
Ja, potem bo res preostalo samo še to, da userji izfiltriramo svoje CAje na tiste, ki jim dejanjsko verjamemo ( v drćavni lasti spodobnih držav itd )...
BTW, a ni tak način dela CA protizakonit ? MIslim, CA gasrantira za identiteto nosilca pri njih podpisanega ključa. Če te ta nategne, a ni potem CA vsaj deloma odgovoren, če ne soodgovoren ?
Ah ja... lepo bi bilo, če bi bilo. CA ti ni ničesar obljubil, zato ti tudi ni ničesar prekršil. Verisign ima na naslov https://www.verisign.com/CPS svojo politiko, ki med drugim našteva tudi garancije in odgovornosti. Potem, ko prebaviš 100+ strani pa ugotoviš, da še vedno nimaš odgovora kaj ti Verisign sploh jamči, oziroma kaj ti trdi o lastniku digitalnega podpisa katerega ravnokar gledaš.
Ja, potem bo res preostalo samo še to, da userji izfiltriramo svoje CAje na tiste, ki jim dejanjsko verjamemo
DA! Prav imaš. Prenekatero podjetje to na delovnih postajah svojih zaposlenih dejansko naredi ravno zato, da se zavaruje pred neznanimi/nevarnimi overitelji. Ne predstavljam pa si, kako bi lahko to počeli laiki sami. Takšne odločitve o zaupanju namreč terjajo izjemno široko znanje.
Matthai - misliš, da je tole za v javnost? Drugače pa odlično napisana novica.
Sem malo okleval. Ampak prevladala je full disclosure fi,ozofija. Poleg tega je to že razbobnal Slashdot, zadevo pa sem dobil na interni Tor mailing listi.
BTW, a obstaja kakšen pameten plugin za FF, ki si zapomne IDje (oz hashe) vseh certifikatov strani, ki smo jih že uporabljali? Petname tool nekako ni čisto to...
Hehe... FF 3 ima že vse vgrajeno brez posebnih dodatkov. Iz seznama "Authorities" pobrišeš(*) nepotrebne/neznane overitelje, potem pa po potrebi dodajaš "Security Exception" za vsako posamezno spletno mesto. Ko/če se bo digitalen podpis spletnega mesta nenadoma spremenil, te bo FF tudi takoj opozoril na neujemanje. Seznam tako "odobrenih" digitalnih podpisov pa lahko potem urejaš na zavihku "Servers".
FF3 je tukaj dejansko pokazal nekaj možnosti za nadaljevanje zgodbe, saj omogoča enostavno definiranje tistih strežnikov, katerih digitalnim podpisom zaupamo. In to ne glede na obstoj ali neobstoj CA-jev. Se je pa s tem odprlo vprašanje, kako pri prvem obisku vedeti, če obiskujemo pravo spletno mesto, ali pa smo že "napadeni".
(*) Builtin object token se sicer ne da izbrisati, vendar pa postopek "brisanja" izbriše njegove zastavice za zaupanje. To pa je enostavneje, kot pa "Edit" + 3 x klik na zastavice + OK.
Najprej bi pozdravil odprtje zelo zanimive teme, ki v današnjem hitro naraščajočem spletnem poslovanju postaja vedno večji problem.
Se je pa s tem odprlo vprašanje, kako pri prvem obisku vedeti, če obiskujemo pravo spletno mesto, ali pa smo že "napadeni".
Mislim, da je MITM napad glede na zgoraj omenjeno problematiko sekundarnega pomena, saj je po mojem mnenju bazičen problem današnejga spletnega poslovanja in pojavljanja na spletu v načinu najemanja spletnih domen. Na precej enostaven način se da zlorabit lastništvo nad domeno oz. prikrit lastno identiteto ali z njo kazat na tretjo osebo in ji na tak način povzročit hujše poslovne posledice.
Glede na postopke registracije domen se mi že zakon o varovanju osebnih podatkov (http://www.ip-rs.si/zakonodaja/zakon-o-... zdi popolnoma nesmiselen, saj lahko kdorkoli najame katerokoli domeno in z njo upravlja po lastni volji, obenem pa je njegova idetiteta poljubno predstavljena (upravitelj lahko ostane celo anonimen). Glede na povedano lahko sami presodite smiselnost prve alineje 19. člena tega zakona in predpisane kazni (91.člen) za neupoštevanje 19. člena, ki sega do 12.510€!
Mislim, da se je že sama politika registracije domen orientirala v napačno smer tako, da je v še večjo podporo spletnim kriminalcem. Za odpravo tega problema mislim, da bi morali postopke registracije domen bistveno poostriti, na raven kot je pridobivanje osebnih dokumentov, kjer so podatki o imetniku le-teh nevprašljivi. Na tak način bi rešili vprašanje o identiteti upravitelja domene in odgovornosti za vsebine na njej. Tako bi tudi CA imeli manj problemov pri dodelejvanju certifikatov pravim upraviteljem domen, zmanjšal bi se tudi pojav MITM napadov, Phishinga, Pharminga, Copy-Cat,...in ostalih napadov, ki so v neverjetnem porastu.
Zanimiva rešitev temu problemu se mi zdi uvedba postopka pridobivanja t.i. verificiranih domen, kar pa spet odpira nova vprašanja o izvedbi in zapreke pri uvajanju tega...
Lep pozdrav vsem. Danes sem prvič na tem forumu. V oktobru smo bili na Evropski Informacijski varnostni konferenci v Madridu, kjer smo slišali nešteto kritik na račun SSL izdajateljev prav na temo identitete in ostalih nesmislov, ki se na tem področju dogajajo. Zgodba je malo daljša, ne bom pisal romana v treh delih, dejstvo pa je, da so se izdajatelji SSL certifikatov z izdajanjem "low cost" certifikatov brez preverjanja identitete tako rekoč sami sebe pojedli. Mimogrede: večina resnejših phishing napadov in spletnega copycat-a se dogaja ob prisotnosti SSL certifikatov. Da pa je bila zgodba v Madridu še bolj zabavna smo jim razložili, da je tudi sicer koncept SSL certifikatov neumnost brez primere. Morda ste že slišali šalo, ko gresta dva na jezero lovit ribe in po določenem času, na pravem mestu ujameta ogromno rib. Ko se vračata nazaj vpraša prvi drugega "Hej, a si označil tisto mesto, kjer sva danes nalovila toliko rib?". Drugi odgovori: "Seveda sem, tak velik križ sem narisal na rob čolna!". Prvi se razjezi in reče: "A si ti čist gladek? Kako pa veš, da bova naslednjič odbila isti čoln v sposojevalnici?" No, identičen primer imamo z domenami. Domena opremljena z SSL certifikatom, ki je lahko veljaven celo TRI LETA, je lahko pet minut po izdaji certifikata prodana s spletno stranjo vred, lahko je rentana, ... Mislim, da je z načinom dela kot je bil doslej z SSL certifikati, kot smo jih poznali doslej konec. Gre zgolj za TEHNOLOGIJO prenosa podatkov med serverjem in klientom, natančneje za protokol, ki deklarativno onemogoča prisluškovanje komunikacijskemu kanalu. Podatka kdo je na drugi strani komunikacijskega kanala nam SSL certifikati ne zagotavljajo. Odločitev ali osebne podatke pošiljati goljufom po varovanem ali nevarovanem kanalu pa ni tako težka.
Rešitev tega problema je že pripravljena, tehnologija in metoda. Letos je bila na evropski varnostni konferenci nagrajena z drugo nagrado. Pripenjam samo tale link: http://www.pressebox.de/index.php?&boxi...
Še ena pripomba (citat):"COMODO kot CA je pri meni od zdaj naprej enostavno blokiran :)" - po moje ni potrebe, saj je varovan prenos podatkov pri spletnih formah, anketah, ... še vedno boljši kot nič. Seveda pa bi bilo dobro vedeti komu pošiljamo podatke, kar zahteva tudi obstoječa veljavna zakonodaja v EU.
Osnovni namen DNS je IP naslovu prirediti ime - mnemonik, ki si ga človek enostavno zapomne. Kar se tiče (ne)anonimnosti registracije domen, je to za samo varnost nepomembno.
Kot primer: Reklamna agencija je lastnik domene, ki jo uporablja in trži filmsko podjetje, deluje pa na strežnikih, ki so v lasti podjetja Akamai, nahajajo pa se v omrežju tvojega lokalnega ISP-ja. Kdo je tukaj odgovorna oseba? Ali je sploh pomembno kdo je dejanski lastnik domene, če pomisliš, kaj MITM napad sploh je?
Bistvena lastnost MITM napada je, da nobena starn v pogovoru ne ve, da jima komunikacijo nekdo prestreza. Lahko ti npr. podtaknem napačen IP naslov za strežnik. Še vedno veš čigava je domena, vendar pa nisi prišel na strežnik, ki bi bil v lasti ali pod nadzorom lastnika domene. Game Over. Vse komplikacije okoli registracije DNS imen se v primeru MITM napada izkažejo za varnostno irelevantne.
Edini praktičen način zaščite pred MITM napadi je že od nekdaj uporaba metod s katerimi zagotovimo nespremenljivost in po potrebi tudi neberljivost podatkov, ki se prenašajo. V modernih komunikacijskih omrežjih se to doseže z uporabo različnih šifrirnih metod. Za uporabe teh pa moramo med obema stranema izmenjati nek podatek, ki služi vzpostavitvi varne povezave. Tukaj pa pridemo do zaprtega kroga: za varno komunikacijo moram varno prenesti določen podatek, kar pomeni, da moram najprej vzpostaviti varno komunikacijo, za kar moram prenesti določen podatek, za kar moram... Loop.
Da se bi tej zanki izognili, smo začeli uporabljati X.509 standard, kjer si na varen način (prepuščeno domišljiji uporabnika) izberemo korenske overitelje, ki jim bomo zaupali, da nam bodo potrdili, da bistevn podatek, ki je potreben za vzpostavitev varne povezave, pri prenosu ni bil spremenjen ali nadomeščen. Do tukaj vse OK, ampak na žalost pa se je to precej hitro izrodilo, saj je bil ta pristop primeren za tehnično "elito", ne pa za množično uporabo.
Tipičen uporabnik iam več zaupanja v imena kot so Visa, Mastercard, NLB, RBS, ... Vprašajte svoje ne-računalniške prijatelje koliko zaupaj imenom, kot so Verisign, Thawte, Go-Daddy, ... če jih sploh poznajo. Zato so ta podjetja zelo hitro sklenila pakte s tistimi, ki si jih potrebovala: Microsoft, Apple, IBM, Sun, ... V zameno za denar, so njihove digitalne podpise vključili v svoje sisteme in programe. Od tam naprej pa je bilo vse odprto za vse. Uporabnika ni zanimalo kdo mu jamči in kaj mu jamči saj mu tega ni nihče niti poskusil razložiti. Uporabnika danes zanima samo to, da vidi ključavnico. Tisti, ki mu jo nariše, pa mu jo nariše na podlagi tehničnih meril in ne na podlagi pravnih ali podobnih jamstev.
Morda se bi to lahko urejalo tudi s kakšno zakonodajo ali pa preko organizacije podobne ICANN. Težava pa je že v temu, da tudi znotraj EU, kjer imamo direktivo, ki naj bi harmonizirala to področje, pa vendar ima vseh 27 članic z direktivo skladnih 27 nekompatibilnih kompletov zakonodaje. Nekaj, kar Italiji morda zadošča, nam ne zadošča. Nekaj kar nam zadošča, Fraciji morda ne zadošča... Microsoft, ki bi moral vsa ta mnenja upoštevati pa sploh ni EU korporacija. Dejansko si ne znam predstavljati, da se bi tukaj kadarkoli in karkoli zares uskladilo. Glavni igralci pa imajo v tem trenutku od tega kaosa tudi dobre zaslužke, kar pomeni, da jim zagotovo ni v interesu, da se bi karkoli zares spremenilo.
Izvoren greh je bil storjen v uporabi tehnologije, ki ni dorasla izzivu, zato pa danes to "rešitev" IMHO samo flikamo levo in desno, namesto, da se bi vsa ta energija in denar porabila za iskanje nove rešitve in novega pristopa.
Zato imamo danes v svojih sistemih, spletnih brkljalnikih in aplikacijah (Sun Java VM) različne sezname overiteljev različnih kvalitet, ki jih v večini primerov nihče ne preverja... Potem so pa ljudje, ki se s tem poklicno ne ukvarjajo (99,9999% populacije) presenečeni, ko jim je potrebno pojasniti, da so zaupali metodam in podjetjem, ki takšnega zaupanja niso nikoli ne zahtevali, ne upravičevali.
Podatka kdo je na drugi strani komunikacijskega kanala nam SSL certifikati ne zagotavljajo.
X.509 PKI drevesa nam tega ne zagotavljajo. Sami certifikati pa, vkolikor smo uspeli nedvomno prenesti pravi javni ključ. Tako lahko npr. točno vem, da mi je nek mejl res poslal ta in ta človek, če sva se enkrat fizično srečala in mi je predal svoj javni ključ.
X.509 PKI drevesa nam tega ne zagotavljajo. Sami certifikati pa, vkolikor smo uspeli nedvomno prenesti pravi javni ključ. Tako lahko npr. točno vem, da mi je nek mejl res poslal ta in ta človek, če sva se enkrat fizično srečala in mi je predal svoj javni ključ.
Če se z osebo srečaš, potem ne potrebuješ X.509 strukture. Daš javni ključ, vzameš njegovega in to je to. Celotna zgodba X.509 je zgodba ene vrste PKI in nič drugega. "Certifikat" je samo ustrezno kodirana struktura, ki vsebuje tvoj javni ključ, podatke overitelja, podatke o zagotovilih in overitev samo.
PGP je recimo uporabljal drugačen PKI: ključi in njihove overitve so se nahajali na centralnih strežnikih. O njihovi verodostojnosti pa si odločal sam na podlagi svojih lastnih odločitev. Distribucija je tako bila olajšana, ni pa prišlo do prenosa funkcije zaupanja na 3. osebo.
Osnovna ideja X.509 pa je bila ravno prenos zaupanja na 3. osebo, zato, da se mi ne bo potrebno srečati z vsemi s katerimi bi potencialno želel komunicirati. Na žalost pa: - X.509 uporablja X.500 hirearhično poimenovanje - X.500 se na internetu ni nikoli pravilno uporabljal - brkljalniki ti kot OK predstavijo ujemanje DNS imena s CN komponento X.500 imena.
Za pravilno pa bi bilo potrebno: - X.500 imena so unikatna, nahajajo se v globalnem imeniku - X.509 je vezan na unikatno ime, zato ga ni možno ponovno zahtevati brez privoljenja lastnika - spletni brkljalnik bi moral prikazati samo LASTNIŠVO IZRAŽENO V X.509 STRUKTURI, odločitev o zaupanju pa bi moral prepustit uporabniku.
S tem bi se zagotovilo naslednje: - obstoj globalnega imenka bi onemogočal centralno evidenco vseh kvalificiranih X.509 potrdil - če X.509 potrdila v globalnem imeniku ne bi bilo, potem ne bi bilo kvalificirano. - uporabnik se bi vedno odločal na podlagi kvalificiranosti potrdila ter imena in države (lokacije) podjetja/osebe, sam spletni brkljalnik ne bi sprejemal ali vsiljeval nikakršnih odločitev.
Seveda nisem nikjer omenil DNS-a, ker ta v tej zgodbi zaupanja in varnosti ne igra nobene vloge. Kajti, če sistem zaupanja postavimo pravilno, potem ranljivosti v DNS-u ne vplivajo na varnost. Če pa sistema ne postavimo pravilno, pa ima skoraj vsaka napaka na nižjih nivojih za posledico popolno izgubo varnosti.
Seveda pa so ITU-jevi X.nekaj standardi tragično pogoreli. SMTP in LDAP sta zmagala. X.509 se je zlorabil do skrajnih meja. Ideja globalnega imenika je propadla še preden je zares zaživela. Internet je zmagal, zato pa sedaj potrebujemo nove rešitve, ne pa več obližev za napačne pristope. Veliko je bil za to kriv ITU sam, saj je določene zadeve zaprl in zavrl do neuporabnosti, vendar pa to še ne pomeni, da se iz teh stvari ne moremo ničesar naučiti. Določene stvari so pravilno pogruntali že v '80, pa so jih nekateri velepametni faliranci v '90 "pozabili". Sedaj pa moramo 10 let po izvornem grehu znova odkrivati toplo vodo.
Še ena pripomba (citat):"COMODO kot CA je pri meni od zdaj naprej enostavno blokiran :)" - po moje ni potrebe, saj je varovan prenos podatkov pri spletnih formah, anketah, ... še vedno boljši kot nič.
Če blokiram CA, to še ne pomeni, da ne uporabljam varovanega prenosa podatkov. Samo dobival bom opozorila o neoverovljenem certifikatu. A ni tako?
Če govorimo o spletni komunikaciji potem lahko tiste redke primere fizičnega srečanja in osebne izmenjave ključev preštejemo na "prste tišlarske roke". Od takrat naprej identifikacija res ni problem. Na žalost pa na tak način spletnega problema identifikacije ne moremo rešiti. Ker je problem ostalih 99,999%.
Man in the middle attack je problem, je pa po obsegu nasploh precej manjši kot phishing oz. širše spletni copycat. Ja seveda lahko se podtakne napačne DNS zapise klientu. Ki potem gleda C in misli, da gleda A. Lahko je narejeno sistemsko na skupine klientov lokalno ali znotraj ISP-jev in govorimo o pharmingu. Ampak kadarkoli govorimo o "klientski strani" so prevare v manjšem obsegu, kot če govorimo o prevarah na "serverski strani". Prevare, ki izhajajo iz napake na klientu, in zaradi pomankljive zaščite in previdnosti klienta, so tudi s stališča odgovornosti na strani klienta. Problem so prevare, ki so na strežnikovi strani, brez virusov, brez podtaknjenih IP-jev, brez ene same hackerske finte, ... Najbolj učinkovite so "čiste ne-hackerske prevare", ki jim obstoječa organizacija (kaos) na široko odpira vrata.
Za Evropsko nogometno prvenstvo so na eni phishing strani opremljeni s Thawte low cost SSL certifikatom samo Slovencem prodali za več kot 60.000€ kart, ki jih seveda nikoli niso dobili. Seveda imam podatke samo za tiste, ki so se preko COFACE Slovenija obrnili na nas. Prav nič jim nismo mogli pomagati. In tudi denarja niso nikoli dobili nazaj. Prevara ni vsebovala niti ene hackerske metode.
In prav zaradi slednjih je izredno pomembno čigava je domena, kdo je dejanski lastnik domene. Problem prestrezanja podatkov oziroma MITM je tehnološko gledano bolj "zanimiv", vsekakor pa se z njim tudi pribljižno ne da narediti škode in prevar reda velikosti phishinga in copycat-a, kar kažejo tudi statistike, kjer phishing (v razširjenem pomenu besede) v zadnjih štirih letih v ZDA, Angliji in Nemčiji vsako leto dobesedno "podeseteri obseg poslovanja". Metod in izpeljank teh zgodb je že cela vrsta. In temu problemu SSL certifikati in njihovi izdajatelji niso kos. Ker temeljnega problema identifikacije ne rešujejo, ker so konceptualno zgrešili cilj, ker so se nivoji preverjanja povsod močno znižali oziroma izničili, ...
Še ena pripomba (citat):"COMODO kot CA je pri meni od zdaj naprej enostavno blokiran :)" - po moje ni potrebe, saj je varovan prenos podatkov pri spletnih formah, anketah, ... še vedno boljši kot nič.
Če blokiram CA, to še ne pomeni, da ne uporabljam varovanega prenosa podatkov. Samo dobival bom opozorila o neoverovljenem certifikatu. A ni tako?
Ja seveda, samo dobival boš milijon opozoril, kjer se boš moral vedno znova strinjati, če boš naletel na take strani. Pa tudi sicer med izdajatelji SSL ni več razlik. Comodo uporablja QUick SSL, Thawte Instant SSL, GeoTrust (ne vem gotovo je kakšen EasySSL ipd.), tudi z GoDaddy je isto. Skratka vsi imajo skupino certifikatov za pest dolarjev (20-40$), ki jih izdajo takoj in ne preverijo ničesar. Kar pomeni, da je po tej analogiji vseeno če vse izdajatelje črtaš s seznama tistih, ki jim zaupaš. Samo klikanje in sprehajanje po spletu bo bolj nerodno.
Take CA Mozilla da v svoj "trusted" spisek, slovenske drzavne pa ne ...
Em, podjetja oziroma institucije morajo same sproziti postopek za vkljucitev certifikata v bazo. Ce poznas odgovorne za podrocje izdajanje certifikatov v drzavni upravi, jim lahko posredujes moj mail (glej profil) in jim pomagam/svetujem glede vkljucitve certifikata v Mozillino bazo certifikatov.
Delovala bi edino, če bi to izvajala od države overjena notarska ustanova, ki bi dejansko tudi preverila vse podatke. Kako bodo pa tile gospodje verificirali neko azijsko podjetje?
Danes mi je prišlo na misel kako bi bilo mogoče izvajati neopazno prestrezanje e-pošte uporabnikov BlackBerry naprav.
BlackBerry naprave za branje e-pošte uporabljajo tehnologijo "push". To pomeni, da uporabnik podatke za dostop do svojega poštnega predala vnese na njihov strežnik, ki potem bere pošto in jo nato razpošilja preko (GSM) omrežja do BlackBerry naprave. Povezava med "fetch" strežniki podjetja Research In Motion (RIM) ter BlackBerry napravami povezava je sicer šifrirana z 256-bitnim AES ključem, a ključno je, da so tako strežniki podjetja Research In Motion posredniki med uporabnikovim poštnim strežnikom in njegovo BlackBerry napravo.
Če bi se torej nekdo uspel vriniti na internetno povezavo RIM strežnikov, bi lahko prestrezal vso pošto, ki jo RIM strežniki prenesejo nase in potem posredujejo BlackBerry napravam.
Kako to izvesti?
1. Najbolj enostavno bi seveda to lahko storil RIM-ov ponudnik dostopa do interneta. Vendar pa obstaja še druga možnost: napad na Border Gateway Protocol (BGP).
Zadevo sta konec avgusta predstavila dva raziskovalca na konferenci DefCon pokazala, in sicer sta pokazala, kako je mogoče spreminjati pot podatkovnih paketov ter tako neopazno prestrezati internetni promet iz kjerkoli na svetu.
Da zadeva deluje vemo od 24. februarja letos, ko je pakistansko sodišče zaradi objave spornega posnetka prepovedalo dostop do YouTubea, pakistanski ponudniki dostopa do interneta pa so prepoved implementirali s pomočjo BGP usmerjanja. Posledica je bila, da se je večina celotnega svetovnega internetnega prometa preusmerila na pakistanski strežnik, ki je obiskovalce obveščal, da je dostop do YouTubea prepovedan.
2. Pri uporabnikih, ki uporabljajo "plaintext" protokole za e-pošto je s tem prestrezanje že končano. Kaj pa pri uporabnikih, ki uporabljajo varne (SSL) povezave?
No, tukaj se lahko uporabi "začasni" certifikat nesposobnih/zlonamernih CA-jev kot npr. Comodo, ali pa tajna služba ustanovi kar lastno internetno podjetje in postane CA izdajatelj certifikatov. Se še kdo spomni SOVI-nega internetnega podjetja Webs?
In to je to. Napadalec potem neopazno prestreza internetni promet in neopazno izvaja napad s posrednikom ter veselo bere vso pošto in zbira vsak gesla uporabnikov.
Ni treba podtikati nobenih fake DNSov, IP ciljnega strežnika bo vedno pravi, certifikat bo pa "veljaven".
Delovala bi edino, če bi to izvajala od države overjena notarska ustanova, ki bi dejansko tudi preverila vse podatke. Kako bodo pa tile gospodje verificirali neko azijsko podjetje?
Če se vsaj malo posvetimo tej storitvi vidimo, da točno na tak način deluje. Company On Net sam, ne verificira nobenih podjetij, pač pa za to poskrbijo lokalne avtoritete (verifikatorji), kar pomeni, da podatki so overovljeni. Na primer v Sloveniji za točnost podatkov na verificirani domeni jamči Gospodarska zbornica Slovenije. Podjetje Company On Net je le tehnološki ponudnik, ki omogoči tehnološko gledano sistem overovljenja podatkov in sidranje podjetij na verificirane domene. Na enak način se verificira podjetje v drugi državi tako, da se pridobi lokalnega verifikatorja za določeno državo, ki potrjuje točnost podatkov in na podlagi tega omogoči izdajo verificirane domene.
Kaj pa pri uporabnikih, ki uporabljajo varne (SSL) povezave?
No, tukaj se lahko uporabi "začasni" certifikat nesposobnih/zlonamernih CA-jev kot npr. Comodo, ali pa tajna služba ustanovi kar lastno internetno podjetje in postane CA izdajatelj certifikatov. Se še kdo spomni SOVI-nega internetnega podjetja Webs?
Večina privatnih mail serverjev, ki uporablja SSL, ima self-signed certifikate, tako da je precej velika verjetnost, da se certifikati sami sploh ne preverjajo.
mmerljak - da, ampak pozabljaš, da mednarodnega sistema verifikacije in preverjanja bonitet - govorim o poenotenem in usklajenem sistemu - nimamo.
To je cilj Company On Net sistema, da vzpostavi poenoten sistem verifikacije. Kar se bonitet tiče ima ekskluzivno pogodbo z globalno bonitetno hišo Coface, ki je prisotna v 94 državah na svetu, kar pomeni, da iz poslovnega vidika lahko sam sistem zagotovi enak standard bonitetnih poročil v katerikoli državi je oz. bo prisoten. Omenit je potrebno, da podjetij v državah, kjer Company On Net še nima predstavništev tudi ne verificira podjetij.
Prav imaš glede zaupanja. Ravno zato CONNET prepušča vlogo verifikatorja za to usposobljenim organom, ki imajo določeno težo, prepoznavnost in zaupanje na nacionalni ravni, sam CONNET pa ostaja le tehnološki ponudnik.
Če sem prav razumel, gre za nekakšno bazo podatkov o lastništvu posameznih domen in obenem tudi podatkov o podjetjih samih, te podatke pa priskrbijo lokalne bonitetne/revizorske/verifikatorske hiše iz posameznih držav? Sliši se precej zanimivo. Sicer verjetno ni čisto 100% zaščita proti phishingu, ker če si sam nepazljiv, te še zmeraj lahko nategne kdorkoli, ampak vseeno je vsaka dodatna informacija o tem, kdo stoji za neko spletno stranjo, še kako dobrodošla.
Problem je, ker si lahko danes že vsak nadebudni mulo v petih minutah naklika spletno trgovino, našminkira vse skupaj z lepim skinom, dobi še en poceni SSL z lažnimi podatki in že začne "prodajati" artikle. Potem pa ugibaj, komu boš zaupal in komu ne...
100% varnih varnostnih sistemov ni, vsaj jaz jih ne poznam. Lahko bi rekli, da je to "luknja" v sistemu, vendar za točnost postopka registracije podjetja so odgovorni drugi organi kateri so pristojni zato, da registracijo podjetja opravijo vestno in preprečijo tovrstne zlorabe. Verjamem pa, da s takim postopkom izdajanja verificiranih domen Company On Net prepreči večino potencialnih zlorab identitete podjetij in s tem tudi dvigne zaupanje obiskovalcev v spletne strani verificiranih podjetij na spletu.
V Aziji trenutno še ni mogoče opraviti verifikacije podjetja, saj Company On Net še nima zastopnika za nobeno Azijsko državo, jih pa aktivno išče. Običajno je postopek tak, da po pridobitvi zastopnika (ekskluziva) za določeno državo se začne urejati relacije z bodočimi verifikatorji.
Ni mi jasna ključnost Conneta v celi zadevi. Oni fizično preverjanje pristnosti outsourceajo pač na pristojne institucije, ki bi naj na danem fizičnem področju bile sposobne izvajati nadzor.
So ene tolk varni kot je Paypal banka.
Kar je IMHO potrebno, je nek globalni sporazum in piramida odgovornosti kdo-bo-komu-jeal-mater, če pride do s*anja.
En doo je premajhen in premalo stabilen za kaj takega.
Sicer pa ne vem zakaj so nekateri tako obremenjeni s svojo lastno majhnostjo. Koliko točno ljudi pa je ustvarilo Google? Kje je bil prvi sedež? Hmmm.... samo zato, ker ti nimaš ideje in poguma, ali to pomeni, da je nihče drug ne more imeti?
Če je ideja dobra bo verjetno dobila denar in zrasla (ali pa jo bo kdo kopiral, če bo to ceneje). Če ideja ni dobra, bo pač počasi zamrla. Vneprejšnje razlaganje o majhnosti in stabilnosti je b.v. in samo kaže na enega izmed razlogov zakaj je Slovenija še vedno majhna.
Mene pa bolj zanima kako lahko takšna rešitev dejansko pomaga pri MITM napadih. Kako bo lahko uporabnik ugotovil, da je prišel na "kukavičji" strežnik, namesto na pravega? Po katerih parametrih se preverja vzpostavljeno komunikacijo? Kako se pri MITM napadih ugotovi, da so v teku?
En doo je premajhen in premalo stabilen za kaj takega.
Na grobo gledano analogijo delovanja CONNET d.o.o. lahko vidimo v podjetju, ki izdeluje osebne izkaznice, ki je prav tako le d.o.o.. Tako podjetje zagotavlja le tehnologijo za izvedbo oz. izdelavo osebne izkaznice, za tocnost podatkov pa so zadoženi drugi, za to usposobljeni organi v državi - "outsourcanje". Pred izdelavo osebnih izkaznic pa more tako podjetje doseci visoko in zadostno mero zaupanja v oceh teh organov - verifikatorjev. Sistem verifikacije v primeru CONNET d.o.o. je drugacen le v tem, da je pridobil zaupanje verifikatorjev še v drugih državah, kjer je sedaj prisoten.
Poslovni model podjetja je razclenjen oz. omejen po državah (verifikator, ekskluzivni zastopnik s prodajno mrežo in tehnološki ponudnik - CONNET d.o.o.), kar je pregleden poslovni model, saj v tem primeru se tocno ve kdo je za kaj odgovoren.
Mene pa bolj zanima kako lahko takšna rešitev dejansko pomaga pri MITM napadih. Kako bo lahko uporabnik ugotovil, da je prišel na "kukavicji" strežnik, namesto na pravega? Po katerih parametrih se preverja vzpostavljeno komunikacijo? Kako se pri MITM napadih ugotovi, da so v teku?
Ob predpostavki, da SSL oz. TLS protokolu zaupamo kot tehnologiji za varen prenos podatkov od tocek A do tocke B, je stvar dokaj jasna. Ker sam protkol skrbi le za varen prenos podatkov, se uporabnikom sistema priporoca, da obiskovalcem njihovih strani priporocajo uporabo komunikacijskega obrazca, ki je na verificirani strani njihovega podjetja. Obrazci so pod SSL protokolom ter na straneh z verificiranimi podatki podjetja tako, da obiskovalec ve komu informacije pošilja. Verificirane strani tako kot vsi ostali Company On Net produkti pa so na Company On Net strežnikih.
Sicer pa ne vem zakaj so nekateri tako obremenjeni s svojo lastno majhnostjo. Koliko točno ljudi pa je ustvarilo Google? Kje je bil prvi sedež? Hmmm.... samo zato, ker ti nimaš ideje in poguma, ali to pomeni, da je nihče drug ne more imeti?
Ko se bo Google ukvarjal z esencialnimi emehanizmi za varnost vseh nase, me bo njegova narava zanimala. Pravzaprav me bo to zanimalo že, če/ko se bo začelo pojavljati v Androidu. In pravzaprav upravičeno čedalje bolj zanima mnoge že kar se njegove vsakodnevne obdelave podatkov tiče. IMHO _zelo_ upravičeno.
Če je ideja dobra bo verjetno dobila denar in zrasla (ali pa jo bo kdo kopiral, če bo to ceneje). Če ideja ni dobra, bo pač počasi zamrla. Vneprejšnje razlaganje o majhnosti in stabilnosti je b.v. in samo kaže na enega izmed razlogov zakaj je Slovenija še vedno majhna.
Ne flancaj neumnosti. Ko/če bo imel nad tiskom slovenskega kontigenta EUR nadzor tam nek doo ali sp kjer se dišo lahko zmeni, da bo pač recimo na brzino natiskal X-krat več denarja, kot bi ga smel in bo za to odgovarjal izključno kazensko, bo pa njegova rit lahko daleč proč, preden kazen "prime", bi me to tudi zelo zanimalo. Pa tudi, če bi bila narava deala taka, da bi bila država nanj nekako monopolno vezana, bi me to seveda zanimalo.
Mene pa bolj zanima kako lahko takšna rešitev dejansko pomaga pri MITM napadih. Kako bo lahko uporabnik ugotovil, da je prišel na "kukavičji" strežnik, namesto na pravega? Po katerih parametrih se preverja vzpostavljeno komunikacijo? Kako se pri MITM napadih ugotovi, da so v teku?
O.K. I'm all ears. Razloži nam, kaj garantira pristnost teh podatkov pri tej "rešitvi".
Na grobo gledano analogijo delovanja CONNET d.o.o. lahko vidimo v podjetju, ki izdeluje osebne izkaznice, ki je prav tako le d.o.o..
KAr v bistvu ni res. Veliko bolj je njegova vloga primerljiva vlogi sedanjih CAjev. Podjetja, ki dejanjsko delajo take dokumente so pod strogim državnim nadzorom. COnnet je, kot sem razumel, krovni del sistema, katerega varnostni in informacijski organi posameznih držav so samo izvajalci del na določenem področju. Oni lahko Connetu zaupajo ali pa jih recimo zanj boli ku*ac, ampak on niso kritični del verige.
Vprašanje je, ali mu lahko zaupa stranka, ki bi rada izvedla transakcijo.
Če bi jaz rad kupil nekaj od recimo indijskega ponudnika, ki je recimo v tem sistemu, potem je od integritete indijske države odvisno, da ne bodo njihove tajne in kriminalne irganizacije vanj injecira podatkov "slabih" firm. O.K. Mimo tega ne morem, čeprav se da tudi tu marsikaj reči.
Ampak kaj mi garantira, da tega ne bo storil krovni d.o.o. ?
@Brane2: Kaj ti garantira, da ti tega ne bo naredila krovna multinacionalka, ki ima ekipo 5000 odvetnikov s katerimi se lahko desetletja preigrava z vso nacionalno zakonodajo vseh držav na svetu? Zakaj misliš, da ima velikost ali organiziranost podjetja karkoli za opraviti z verodostojnostjo, učikovitostjo in uporabnostjo produkta?
@mmerljak:
Obrazci so pod SSL protokolom ter na straneh z verificiranimi podatki podjetja tako, da obiskovalec ve komu informacije pošilja. Verificirane strani tako kot vsi ostali Company On Net produkti pa so na Company On Net strežnikih.
Ali je predviden tudi kakšen avtomatičen mehanizem za dostop do teh overovljenih podatkov? Glede na to, da se "stari igralci" na področju overovljanja X.509 potrdil vsi drenjajo k EV potrdilom, ki že opravljajo to funkcijo (IMHO na dolgoročno slab način), kakšna je konkurenčna prednost vašega pristopa? Seveda gledano samo iz vidika SSL/TLS komunikacije. Razumem, da vaša rešitev obsega več kot samo to, vendar pa me zanima kako ste si zamislili implementacijo dodatnega preverjanja potrdil izmenjanih v TLS seji.
