Novice » Varnost » Izvedba popolnega MITM napada
BlueRunner ::
Joj, ne!
Ti predlagaš, da se plača neka "Članarina", nekdo potem meri "zaupanje" (ali kaj podobnega - npr. število klikov, zadovoljnih kupcev, whatever...) in potem glede na to deli denar.
Ne, ne, ne.
Ker če bo to delovalo, bodo založbe uvedle plačevanje za oglede vsebin. Malo pobrskaj po zgodovino - točno na tak način so hoteli uvesti DRM plačevanje.
Joj, joj... ne na ta način. Recimo, da bi to res bila "članarina", ampak ta denar ostane podjetju, ki meri "zaupanje". To pa zato, ker so za "preverjanje verodostojnosti" pač potrebne finance. Nekaj pa mora itak ostati tudi še kot dobiček.
Ideja je, da se še vedno zbere vse podatke o podjetju, ki se ga verificira: iz bonitetnih hiš, iz uradnih registrov, iz vseh dosegljivih virov. Nato pa se na podlagi tega poda oceno "kvalitete" podjetja. Stroške pa krijejo tisti, ki se na to oceno zanašajo, nikoli pa ne tisti, ki so predmet te ocene.
Denar vsekakor ne sme iti k tistim, ki se jih ocenjuje, hkarti pa od njeih tudi ne sme priti. Njihova edina možnost je, da na verifikacijo pristanejo, ali pa ne. Če pristanejo se jih pregleda in oceni, če ne pristanejo, potem imajo pač oceno 0 in temu primerno zaupanje.
poweroff ::
Bom rekel drugače. Simobilova spletna stran je ranljiva na XSS napad. Znam sestaviti XSS zahtevek, ki bo pokazal, da Siobil prodaja neke telefone preko spleta, številke kreditnih kartic pa se bodo pošiljale meni.
Kako rešujete ta problem?
Kako rešujete ta problem?
sudo poweroff
BlueRunner ::
Bom rekel drugače. Simobilova spletna stran je ranljiva na XSS napad. Znam sestaviti XSS zahtevek, ki bo pokazal, da Siobil prodaja neke telefone preko spleta, številke kreditnih kartic pa se bodo pošiljale meni.
Uf. Za ta del bi moral poskrbeti sam spletni brkljalnik tako, da ne bi prikazoval vsebine, ki nima istega varnostnega konteksta kot ga ima glavni dokument. Potem XSS odpade, oziroma ostane samo še nevarnost napada neposredno na strežnik.
Na žalost pa je so prodajniki obsedeni z reklamami do te mere, da jih nezavarovane tlačijo tudi na prodajne strani, ki bi morale biti zavarovane. Posledično to pomeni, da imajo danes že skoraj vsi uporabniki omogočen prikaz spletnih strani, ki vsebujejo tudi kodo iz drugih (ne)varnostnih kontekstov. Posledično to pomeni, da so tudi razvijalci vedno bolj površni saj tudi lastno vsebino vključujejo iz nevarovanih naslovov (npr. spkupna glava, skupni grafični elementi, ...), kar težave še bolj poslabša.
Tako, da je ta problem že rešljiv in tudi bil rešen na nižjem nivoju, kasneje pa se ga je uničilo z neodgovornim delom in pristajanjem na napačne rešitve. Tudi tukaj je videti, kako je pohlep predstavljal negativno silo iz vidika varnosti.
Brane2 ::
Katera od opcij praktično zagotovo pomeni, da tvoje podjetje ne obstaja:
- če ga ni v GZSjevih evidencah in je v sodnem registru
- obratno
Ah, ampak zakaj se bi vezal samo na GZS? Saj to ni edini in izključni vir podatkov. Kaj mi brani, da ne pridobim sočasno podatke iz GZS, AJPES in sodnega registra pri sodišču, kjer je bilo podjetje registrirano? Razlika je samo v temu, da moraš z GZS podpisati pogodbo, da ti bo sploh kakšen pdatek dal, državne evidence pa uporabljaš kadar jih hočeš, pač s plačilom stroškov za posredovanje.
Ne, razlika je še v tem, da je potrdilo o obstoju tvojega podjetja sodna odločba. Ostali "value added" sourci se lahko na glavo postavijo, pa ne morejo zanikati obstoj podjetja, za katerga držiš v roki veljavno odločbo sodišča. kar je bistvena zadeva pri sistemu avtentifikacije. Mogoče so ostali podatki priročnejši, če te zanima kaj drugega, ampak za obstoj in definicijo pravne osebe je edini merodajen ta vir.
Kar je seveda normalno, saj se registriraš na sodišču in ne pri GZS/AJPES/wherever.
Sicer pa bistveno vprašanje ni sam obstoj podjetja. Bistveno vprašanje je kvaliteta poslovanja podjetja.
Zakaj se mi zdi, da je to vprašanje postalo tako bistveno šele sedaj, po toliko rundah ping-ponga ? ;o)
On the journey of life, I chose the psycho path.
Lipicnik ::
Verificiramo obstoj podjetja, njihove podatke in vse njihove komercialne domene, ki jih uporabljajo (.si, .com, .karkoli ...), kar preprosto pomeni, da obiskovalec ve kdo je odgovoren za spletno stran, ki so jo obiskali. V primeru zlatih in platinastih certifikatov zagotavljamo še finančne in bonitetne podatke o podjetju. Sami pečati na komercialnih spletnih straneh so varovani z serijo varnostnih mehanizmov, popolno varnost pa pomeni klik na pečat in link, ki vodi iz certifikata nazaj na komercialno spletno stran. Lahko pogledaš http://www.saop.si . Link naprej pa vodi na verificirano spletno stran podjetja na njihovi "verificirani domeni", ki jim jo dodelimo na način podjetje.končnica-on.net oz. v konkretnih primeru npr. https://SAOP.DOO-on.net ali https://SMELT.DD-on.net . Prav zaradi verificiranih domen se servis imenuje Company On Net.
Da odgovorim še na vprašanje spodaj od Matthaia. Zahtevki za plačilo se bodo izvajali na naših strežnikih na verificiranih straneh podjetja npr: https://SAOP.DOO-on.net , kar olajša delo bankam povezava je samo z nami, kupec je lahko prepričan komu plačuje, na drugi strani pa integracija s strani uporabnika (omenjaš Simobil) poteka samo na ravni z nami.
Da odgovorim še na vprašanje spodaj od Matthaia. Zahtevki za plačilo se bodo izvajali na naših strežnikih na verificiranih straneh podjetja npr: https://SAOP.DOO-on.net , kar olajša delo bankam povezava je samo z nami, kupec je lahko prepričan komu plačuje, na drugi strani pa integracija s strani uporabnika (omenjaš Simobil) poteka samo na ravni z nami.
Lipicnik ::
CITAT: Sicer pa bistveno vprašanje ni sam obstoj podjetja. Bistveno vprašanje je kvaliteta poslovanja podjetja.
Je v nekaterih primerih je to pomembno, predvsem B2B long distance. Takrat z bonitetnim poročilom na verificirani strani povemo praktično vse o podjetju, poslovanju, zamujanju s plačili, bonitetna ocena, ... V večini primerov, pa za potrebe zaupanja na bazičnem nivoju (stran ni phishing ali copycat) zadoščajo običajni certifikati. Poštenosti in dobrih namenov podjetja pa ne zagotavlja prav noben certifikat.
Je v nekaterih primerih je to pomembno, predvsem B2B long distance. Takrat z bonitetnim poročilom na verificirani strani povemo praktično vse o podjetju, poslovanju, zamujanju s plačili, bonitetna ocena, ... V večini primerov, pa za potrebe zaupanja na bazičnem nivoju (stran ni phishing ali copycat) zadoščajo običajni certifikati. Poštenosti in dobrih namenov podjetja pa ne zagotavlja prav noben certifikat.
poweroff ::
Hehe, se pravi če se bodo zahtevki za plačilo izvajali na vaših strežnikih na verificiranih straneh podjetja je zadeva varna? Ne bi rekel.
No, kolega je ravno na CCC v Berlinu in se preko Skypa veselo hahlja na predavanju o varnosti spletnega bančništva.
Bo kakšna novica o tem...
No, kolega je ravno na CCC v Berlinu in se preko Skypa veselo hahlja na predavanju o varnosti spletnega bančništva.
Bo kakšna novica o tem...
sudo poweroff
mmerljak ::
Kot zanimivost, ker je bilo omenjeno long distance poslovanje in možnost objave bonitetnih in finančnih poročil za dodatno višanje zaupanja bi omenil, da ta opcija certifikata ponuja tudi 24 urni monitoring podjetja, kar pomeni, da je iz certifikata v 24urah razvidno v kolikor je podjetje šlo v stečaj ali kaj podobnega.
BlueRunner ::
Zakaj se mi zdi, da je to vprašanje postalo tako bistveno šele sedaj, po toliko rundah ping-ponga ? ;o)
Ker smo vse zakomplicirali do onemoglosti :D
V bistvu pa imamo dva problema, oziroma vsaj jaz vidim dva: eno je zaščita pred MITM napadi, drugo pa je verodostojnost podjetja. Eno me zaščiti pred tretjo osebo, drugo me pa ščiti pred očitno slabim podjetjem. Za mirno spanje pri spletnih poslovanju želiš imeti oboje. Obstoj podjetje je IMHO samo polovica poti do druge točke.
BlueRunner - kaj pa praviš na oni URL zgoraj (PDF)?
Da ga bi lahko odložil na kakšen drug strežnik. Včeraj sem ga šel pogledati, pa ni nič domene prišlo. No, danes je že malo bolje.
Kar se pa vsebine tiče: ja, na konferencah najdeš tudi takšne stvari. Če pa želiš resnično "zabavne" podatke, pa si poglej fast flux omrežja in pasiven DNS. Morda bi celo lahko prepričal koga na SI-CERT (Gorazda...), da bi šel v testiranje pasivne DNS rešitve, ki ti bi razkrila enega izmed danes najbolj uporabnih orodij za odkrivanje teh stvari.
poweroff ::
BlueRunner - poznam fast flux. In BTW: avtor tistega PDFja sem jaz.
Torej - glede MITM napadov smo ugotovili kje je problem. In ta problem trenutno ni zadovoljivo rešen.
Glede verodostojnosti podjetja je pa takole. Vprašanje je, kaj sploh je to "verodostojnost podjetja"?
Možni odgovori:
- da podjetje res obstaja: OK, mora biti vpisano v sodni register, se da preveriti, čeprav podatki niso vedno povsem ažurni. Neažurni so dostikrat tudi podatki o direktorju, lastništvu, itd. in to celo kljub temu, da je za neažurnost predpisana neka (simbolična) kazen;
- da podjetje (pozitivno) posluje (da ne gre za papirnato podjetje): to je že težje preveriti, konec koncev lahko jaz ustanovim dve podjetji, ki si bosta med seboj prodajali "oglase" in si fiktivno ustvarjali promet;
- da je neka spletna stran v lasti nekega podjetja: to skuša rešiti vaša storitev, pa mislim, da ne povsem zadovoljivo. Recimo, pred kratkim je bil v Sloveniji problem domen, ker so jih lahko registrirale samo pravne osebe. In zato smo nekateri dobili pač neko podjetje, da smo preko njega registrirali domeno. Še več - ker registrarji ne preverjajo podatkov o latnikih, je bilo povsem mogoče vpisati kot lastnika domene neko podjetje, dati svoj e-mail in fax ter plačati domeno preko Klika. Kot lastnik pa je napisana neka pravna oseba, ki celo res obstaja in posluje...
BTW, a veš kako urediš prenos DNS strežnikov (oz. spremembo DNS zapisa) pri nekaterih slovenskih registrarjih? Mail pošlješ - iz kateregakoli e-naslova - avtenticiraš pa se tako, da napišeš ime pravne osebe, naslov in matično številko. To je vse. Varno?
- da podjetje upravlja s s spletno stranjo: upravlja z neko spletno stranjo podjetje, nek njihov zaposleni ali morda heker?
- konec koncev pa: kako naj vem, da podjetje morda ni tik pred stečajem, ker pa še ni objavilo četrtletnih sporočil bo boniteta izgeledala OK?
Torej - glede MITM napadov smo ugotovili kje je problem. In ta problem trenutno ni zadovoljivo rešen.
Glede verodostojnosti podjetja je pa takole. Vprašanje je, kaj sploh je to "verodostojnost podjetja"?
Možni odgovori:
- da podjetje res obstaja: OK, mora biti vpisano v sodni register, se da preveriti, čeprav podatki niso vedno povsem ažurni. Neažurni so dostikrat tudi podatki o direktorju, lastništvu, itd. in to celo kljub temu, da je za neažurnost predpisana neka (simbolična) kazen;
- da podjetje (pozitivno) posluje (da ne gre za papirnato podjetje): to je že težje preveriti, konec koncev lahko jaz ustanovim dve podjetji, ki si bosta med seboj prodajali "oglase" in si fiktivno ustvarjali promet;
- da je neka spletna stran v lasti nekega podjetja: to skuša rešiti vaša storitev, pa mislim, da ne povsem zadovoljivo. Recimo, pred kratkim je bil v Sloveniji problem domen, ker so jih lahko registrirale samo pravne osebe. In zato smo nekateri dobili pač neko podjetje, da smo preko njega registrirali domeno. Še več - ker registrarji ne preverjajo podatkov o latnikih, je bilo povsem mogoče vpisati kot lastnika domene neko podjetje, dati svoj e-mail in fax ter plačati domeno preko Klika. Kot lastnik pa je napisana neka pravna oseba, ki celo res obstaja in posluje...
BTW, a veš kako urediš prenos DNS strežnikov (oz. spremembo DNS zapisa) pri nekaterih slovenskih registrarjih? Mail pošlješ - iz kateregakoli e-naslova - avtenticiraš pa se tako, da napišeš ime pravne osebe, naslov in matično številko. To je vse. Varno?
- da podjetje upravlja s s spletno stranjo: upravlja z neko spletno stranjo podjetje, nek njihov zaposleni ali morda heker?
- konec koncev pa: kako naj vem, da podjetje morda ni tik pred stečajem, ker pa še ni objavilo četrtletnih sporočil bo boniteta izgeledala OK?
sudo poweroff
BlueRunner ::
OK, sedaj se bom pa lotil udrihanja po CONNET sistemu Kje vidim največje težave & vprašanja.
- Kaj ta sistem ločuje od drugih podobnih? Kje je njegova dodana vrednost, če imamo samo v EU že cel kup ustanov, ki že nudijo storitev "žiga" na spletnem mestu? Ki se ravno tako ukvarjajo s predstavljanjem verificiranih podatkov?
- Kako se sistem sam brani pred MITM napadi? Kakšne se omejuje posledice uspešnega MITM napada, ki ima za tarčo strežnike company-on.net? Ali sistem morda predvideva, da je možnost MITM napada odpravljena že na drugih nivojih, oziroma, da (idealno) ne obstaja?
- Kaj je tisto, kar ta pečat varuje pred kopiranjem in njegovo zlorabo? Ali imate na voljo tehnična sredstva, ki avtomatično in na varen način preverjajo avtentičnost spletnega mesta? Dodatek za spletni brkljalnik morda? Ali je edini način verifikacije upanje, da bo uporabnik sam preverjal podatke? Ali se od uporabnika pričakuje kakršno koli tehnično znanje?
- Po katerih parametrih se vaš produkt loči od do sedaj znanih "žigov" na spletnih straneh? Ti so namreč v tem trenutku predvsem sredstvo za pospeševanje prodaje, njihov vpliv na varnost pa je v primeru napada praktično enak ničli.
- Kakšni so vaši poslovni standardi, predvsem kje je njihova transparentnost, in kako se upirate "slabim" verifikacijam, glede na to, da vam stroške krijejo tisti, ki jih verificirate? Kako zagotavljate, da plačilo ne more znižati standardov verifikacije?
poweroff ::
S stališča te firme je to idealen poslovni model, saj predvideva, da bodo firme poslovale preko dedicated strežnika copany-on-net.
Za podjetja je to lock-in, za stranke pa tudi. Ko namreč ta del svojih storitev prenesejo na to podjetje in vse skupaj zapakirajo z "zaupanjem", ne morejo več stran. Če gredo namreč nazaj na svoj strežnik, izgubijo "zaupanje".
Skratka, če zadeva uspe, bo tisti, ki bo največji, imel totalen monopol in zelo zelo stabilne prihodke. Kot pri domenah in certifikatih - ko jo kupiš enkrat, jo boš imel in podaljševal vedno.
To je povsem OK, vprašanje pa je, ali je dodana vrednost za ostale tudi tako velika kot za podjetje, ki bo tak posrednik.
Za podjetja je to lock-in, za stranke pa tudi. Ko namreč ta del svojih storitev prenesejo na to podjetje in vse skupaj zapakirajo z "zaupanjem", ne morejo več stran. Če gredo namreč nazaj na svoj strežnik, izgubijo "zaupanje".
Skratka, če zadeva uspe, bo tisti, ki bo največji, imel totalen monopol in zelo zelo stabilne prihodke. Kot pri domenah in certifikatih - ko jo kupiš enkrat, jo boš imel in podaljševal vedno.
To je povsem OK, vprašanje pa je, ali je dodana vrednost za ostale tudi tako velika kot za podjetje, ki bo tak posrednik.
sudo poweroff
BlueRunner ::
BlueRunner - poznam fast flux. In BTW: avtor tistega PDFja sem jaz.
Kudos.
Glede verodostojnosti podjetja je pa takole. Vprašanje je, kaj sploh je to "verodostojnost podjetja"?
Uf. Možni odgovori so vsi, ki si jih naštel, pa še cel kup drugih. Na koncu pa ne samo to, ampak tudi dejstvo, da jaz želim takšna potrdila o poslovanju, ti drugačna, neko podjetje v B2B scenariju pa čisto tretja. Ampak... tudi o tem sem in smo že razmišljali.
BTW, a veš kako urediš prenos DNS strežnikov (oz. spremembo DNS zapisa) pri nekaterih slovenskih registrarjih? Mail pošlješ - iz kateregakoli e-naslova - avtenticiraš pa se tako, da napišeš ime pravne osebe, naslov in matično številko. To je vse. Varno?
Vem, ampak nisem v položaju, da bi lahko kometiral te rešitve.
da podjetje upravlja s s spletno stranjo: upravlja z neko spletno stranjo podjetje, nek njihov zaposleni ali morda heker?
Recimo, da so notranje zlorabe poglavje zase. Vedno so možne in proti njim se borimo z drugimi serdstvi in na druge načine. Bi pa to štel kot vprašanje definicije "verodostojnosti". Nekje imajo boljši interen nadzor, nekje pa slabšega. Nekje shranjujejo podatke, v omejeni količini, nekje shranjujejo kar vse povprek, ... Vse to vpliva ne eno izmed možnih ocen "verodostojnosti".
BlueRunner ::
Sedaj pa še en "strel v zrak". MITM, identiteta in verodostojnost so med seboj povezani. Kot me je Brane2 preganjal naokoli (tokrat v dobrem smislu) imam lahko tehnično varno povezavo, ne vem pa s kom. Če pa vem s kom, pa ne vem kakšnega "karakterja" je ta nekdo.
TLS + HTTP protokole bi bilo potrebno nadgraditi z novim protokolom.
Sicer pa je potrebno do uporabnika spraviti 2,5 podatka:
- identiteto, ki je samo ena in nedeljiva
- verifikacije, ki jih je lahko 0 ali več
- 0,5 podatka pa je še podatek potreben za vzpostavitev varne povezave.
S tem se bi navedbo o identiteti ločilo od navedbe o verodostojnosti. Zakaj bi želel to "zakomplicirati"? Iz čisto preprostega razloga: zato, ker je trenuten položaj iz vidika uporabnika katastrofalen. Pri njemu je vedno v igri enakost "tehnično zavarovano" == "verodostojno", čeprav vsebinsko ta povezava ne obstaja. Tega ne moremo spremeniti z "vodnim tiskom" ali "žigom", ki sta del glavnega toka komunikacije (in-band communication). To se mora rešiti izven glavnega toka (out of band - OOB), saj lahko edino tako zagotovimo neodvisnost vsebine od zagotovil o vsebini.
Z ločitvijo dejansko zagotovimo dva različna podatka, ki jih tudi prikažemo OOB - ne kot del vsebine, temveč kot ločen vizualni element vmesnika. To nista dva nova tehnična podatka, temveč dva podatka, ki dejansko služita uporabnikovi kvalificirani odločitvi: na čigavo spletno mesto sem prišel (identiteta, ki je neodvisna od URL naslova) in kdo mu zagotavlja verodostojnost druge strani (zagotovila s strani ZPS, TÜV, ...). Če mu kateri koli izmed teh podatkov ni všeč (napačno podjetje, ali pa odsotnost zagotovil), se pač odloči "preskočiti" to stran in oditi drugam.
Bistveno in najpomembnejše pri tej rešitvi pa je to, da mora vse novo delo v ozadju tehnika opraviti sama in na varen način. To pomeni, da mora biti identiteta zagotovljena s strani verodostojnega overitelja (država ali pa doo - ne zdi se mi bistveno, če je verodostojnost zagotovljena), hkrati mora biti zagotovljena tudi identiteta izdajateljev dodatnih verifikacij, ki jim zaupamo. Tukaj je na voljo tudi nekaj manevrskega prostora, saj lahko privzamemo, da si bo izdajatelje verifikacij vsakdo izbiral sam, ali pa se bo tudi pri njih vzpostavilo gozdiček, ki se ga bo dodatno distribuiralo skupaj s spletnimi brkljalniki/aplikacijami.
TLS + HTTP protokole bi bilo potrebno nadgraditi z novim protokolom.
Sicer pa je potrebno do uporabnika spraviti 2,5 podatka:
- identiteto, ki je samo ena in nedeljiva
- verifikacije, ki jih je lahko 0 ali več
- 0,5 podatka pa je še podatek potreben za vzpostavitev varne povezave.
S tem se bi navedbo o identiteti ločilo od navedbe o verodostojnosti. Zakaj bi želel to "zakomplicirati"? Iz čisto preprostega razloga: zato, ker je trenuten položaj iz vidika uporabnika katastrofalen. Pri njemu je vedno v igri enakost "tehnično zavarovano" == "verodostojno", čeprav vsebinsko ta povezava ne obstaja. Tega ne moremo spremeniti z "vodnim tiskom" ali "žigom", ki sta del glavnega toka komunikacije (in-band communication). To se mora rešiti izven glavnega toka (out of band - OOB), saj lahko edino tako zagotovimo neodvisnost vsebine od zagotovil o vsebini.
Z ločitvijo dejansko zagotovimo dva različna podatka, ki jih tudi prikažemo OOB - ne kot del vsebine, temveč kot ločen vizualni element vmesnika. To nista dva nova tehnična podatka, temveč dva podatka, ki dejansko služita uporabnikovi kvalificirani odločitvi: na čigavo spletno mesto sem prišel (identiteta, ki je neodvisna od URL naslova) in kdo mu zagotavlja verodostojnost druge strani (zagotovila s strani ZPS, TÜV, ...). Če mu kateri koli izmed teh podatkov ni všeč (napačno podjetje, ali pa odsotnost zagotovil), se pač odloči "preskočiti" to stran in oditi drugam.
Bistveno in najpomembnejše pri tej rešitvi pa je to, da mora vse novo delo v ozadju tehnika opraviti sama in na varen način. To pomeni, da mora biti identiteta zagotovljena s strani verodostojnega overitelja (država ali pa doo - ne zdi se mi bistveno, če je verodostojnost zagotovljena), hkrati mora biti zagotovljena tudi identiteta izdajateljev dodatnih verifikacij, ki jim zaupamo. Tukaj je na voljo tudi nekaj manevrskega prostora, saj lahko privzamemo, da si bo izdajatelje verifikacij vsakdo izbiral sam, ali pa se bo tudi pri njih vzpostavilo gozdiček, ki se ga bo dodatno distribuiralo skupaj s spletnimi brkljalniki/aplikacijami.
Brane2 ::
Kako pa dejanjsko veš, s _KOM_ imaš povezavo ?
Kako veš, da sem jaz recimo Boris Bobanov ?
Recimo celo, da boš za to zahteval, da se dobiva osebno in izmenjava ključe. Dobiva se, in jaz ti zaradi pomislekov ob ključu pustim še:
-vzorec vseh telesnih tekočin ( kri, urin, sperma, če jo rabiš)
- X-ray zob
- prstne odtise
-fotokopijo posebne 9-kotne osebne izkaznice, ki mi jo je izdala država, katere državljan sem
-brisačo, ki sem jo doslej imel s seboj na vseh popotovanjih
Kako ti torej, samo s tehniko, brez pomoči mojega cesarja, vzpostaviš nek podatkovni objekt, ki opisuje mojo identiteto, kot je ta relevantna za kogarkoli, ki bi želel _poslovati_ z menoj?
My point: brez pomoči cesarja ne moreš- ta torej ni opcijska v smislu "važno da mi imamo tehniko oziroma protokol, pa če je cesar zraven ali če ga ni"...
Kako veš, da sem jaz recimo Boris Bobanov ?
Recimo celo, da boš za to zahteval, da se dobiva osebno in izmenjava ključe. Dobiva se, in jaz ti zaradi pomislekov ob ključu pustim še:
-vzorec vseh telesnih tekočin ( kri, urin, sperma, če jo rabiš)
- X-ray zob
- prstne odtise
-fotokopijo posebne 9-kotne osebne izkaznice, ki mi jo je izdala država, katere državljan sem
-brisačo, ki sem jo doslej imel s seboj na vseh popotovanjih
Kako ti torej, samo s tehniko, brez pomoči mojega cesarja, vzpostaviš nek podatkovni objekt, ki opisuje mojo identiteto, kot je ta relevantna za kogarkoli, ki bi želel _poslovati_ z menoj?
My point: brez pomoči cesarja ne moreš- ta torej ni opcijska v smislu "važno da mi imamo tehniko oziroma protokol, pa če je cesar zraven ali če ga ni"...
On the journey of life, I chose the psycho path.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Država: Kakšna zasebnost in varnost na internetih, samo plačajte že davke!!! (strani: 1 2 3 4 5 )Oddelek: Novice / NWO | 85792 (59987) | MrStein |
» | Nizozemski CA DigiNotar izdal lažen SSL-certifikatOddelek: Novice / Varnost | 4325 (3517) | Iatromantis |
» | Napad z ničelno predpono na SSL/TLS certifikate že "v divjini"Oddelek: Novice / Varnost | 6415 (4793) | McMallar |
» | Izvedba popolnega MITM napada (strani: 1 2 3 )Oddelek: Novice / Varnost | 20322 (16708) | Brane2 |
» | Kateri SSL certifikatOddelek: Izdelava spletišč | 4143 (3903) | Poldi112 |