Anonymer Datenaustausch
-
camper schrieb:
du weisst nicht, ob der, der sich als server ausgibt, auch der server ist, den du willst;
1. ist das kein nachteil, sondern genau das was du möchtest
2. du willst keinen server kennen, du möchtest nur ein datenpacket (das man mit md5 signiert bzw könnte man gleich nach einem packet mit einer gewissen md5 signatur pingen)kingruedi schrieb:
Wichtig ist, dass die Partner von einander nichts erfahren. Man weiß nicht wer was anbietet oder was runterlädt und man vertraut keine Aussage eines Peers.
rapso schrieb:
verbindungsaufbau:
-damit es ohne server läuft (wäre ja sonst ein angreifbarer punkt) könnte man sich durch die gegend pingen bis jemand mit der selben software gefunden wurde. .
.
.
so würde ich also erstmal das netz aufbauen, das ohne server auskommt. wenn es 1Mil user gäbe, würde man im schnitt mit ~<2k pings auskommen bis eine connection vorhanden ist.also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)kingruedi schrieb:
Weiterreichen von Verbindungen in der Hierachie und "Vertrauens"-Beziehungen, kann man zum verkürzen der Wege benutzen.
braucht man eigentlich nicht, sobald die MD5 summe eines packetes nicht stimmt, verwirft die node die das validiert hat gleich das packet und versucht es von woanders zu bekommen. natürlich kann sie dann für die fehlerhafte node das rating senken, nur für sich und nur für diese eine session.
Glisglis schrieb:
möglickeit 1.
C weiss das B die anfrage gestellt hat und schickt sie an B.
B wiess wiederum das A die anfrage gestartet hat und reicht sie weiter
==>> jeder braucht enorm viel bandbreite da z.B. 500 MB bei 4 B's bereits 2GB traffik produziert.tja, ist zwar ein wenig 'schade', man könnte aber davon ausgehen, das viele mitsniffen würden, sodas der 'verschleiss' vielleicht relativ klein wäre.
Glisglis schrieb:
möglichkeit 2.
da hast du schon genug kirtische dinge aufgezählt die diese deine idee verwerfen.
Glisglis schrieb:
Weiteres problem wie soll in einen anonymen system die flowkontroll gehändelt werden. wer schickt welches paket. wer hat welches packet. ist die datei überhaupt vollständig vorhanden.
die vollständigkeit einer datei bekommt man über die beschreibung der datei.
du sagst also, du suchst "debian" und bekommst eine liste mit möglichen packeten die in deiner näheren umgebung bekannt sind mit der dateigröße und MD5 summen einzelner tokens und des ganzen packetes. dann kannst du ne meldung abschicken, dass du eine bestimmte md5 suchst und wenn du dann den token hast, prüfst du das.
den flowkontroll kann jede node über ein rating der nachbarnodes bestimmen, natürlich könnte man das dann auch distributen.
rapso->greets();
-
rapso schrieb:
also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)Willst Du einfach nur die IP's durcheinander würfeln? Dann hast Du im Prinzip keine Anonymität und falls der/die Server log-files anlegt, kannst Du alles genau zurück verfolgen. Was passiert wenn der/die Server down sind?
Wenn man nur die IP's vermischt dann bieten evt. andere Leute mit Deiner IP Sachen an, wofür Du evt. rechtlichen Ärger bekommen könntest. Deswegen wäre eine komplett unabhängige Adressierung interessant.
-
Hi
noch mal ein grundsätzliches problem.
im anonymität zu erreichen darf keine absender IP mit verschickt werden. heist also die IP pakete müssen geändert werden um eine falsche absender adresse einzutragen. was machen eigentlich grosse Internetprovider mit IP packeten aus ihrem eigenen backbone, die absende adressen besitzen, die nicht zu ihrem backbone gehören? weiterleiten oder verwerfen. und was macht der admin wenn er feststellt, das sehr viele datenpakte ohne richtige absenderadresse von einem bistimmten port aus seinem backbone kommen? weggucken oder wegen verdacht auf DOS den port einfach dichtmachen und warten bis sich jemand beschwert.
und noch eine kleine rechtliche überlegung. macht sich ein betreiber eines Rechners der P2P packete weiterleitet nicht genauso strafbar wie derjenige der die strafbaren ihalte zum download anbietet?
und zu meinen beiden vorheringen beispielen
1 kommunikation über bekante nachbarn funktioniert nur mit einschränkungen ( und mit eingeschränkter anonymität und wachsendem traffick)
2 kommunikation über unbekante nachbarn funktionert dann erst recht nicht
3 bleibt nur noch eine direckte kommunikation. von a nach b.selbst dann ist es mit der anonymität noch nicht so weit her. sagen wir mal ein server hat eine datei der er mittels 2 verschicken soll. wer sagt euch das jemand nicht einen server schreibt, der jedem seiner bekanten gegenstellen einen anderen teil der datei beschädigt/ oder nicht zukommen lässt. durch ausnutzen der flowkontroll wird ihm ja irgendwann mitgeteilt, das er doch dein teil noch einmal schicken solle / oder einen anderen. Je nach verfügbarkeit der Datei, kennt man dann zumindestens die gegegenstelle, einreisen.
gruss
-
Magoon schrieb:
rapso schrieb:
also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)Willst Du einfach nur die IP's durcheinander würfeln? Dann hast Du im Prinzip keine Anonymität und falls der/die Server log-files anlegt, kannst Du alles genau zurück verfolgen. Was passiert wenn der/die Server down sind?
Wenn man nur die IP's vermischt dann bieten evt. andere Leute mit Deiner IP Sachen an, wofür Du evt. rechtlichen Ärger bekommen könntest. Deswegen wäre eine komplett unabhängige Adressierung interessant.
und wie willst du, bloss weil du IPs von vielen leuten kennst die das programm haben, die packete die transportiert werden in irgendein zusammenhang mit den IPs der empfänger und absender zusammenbringen???
du kannst übers internet keine daten verschicken, ohne bei "send" bzw "recv" eine IP zu haben.
rapso->greets();
-
Glisglis schrieb:
Hi
im anonymität zu erreichen darf keine absender IP mit verschickt werden. heist also die IP pakete müssen geändert werden um eine falsche absender adresse einzutragen.
das ist falsch, man darf nur nicht wissen, von wem die daten kommen, die einem weitergeleitet werden, aber da man ja nicht weißt, ob der 'vormann' der wirkliche absender ist, oder nur eine zwischennode, weiß man nicht wer der absender ist (und andersrum geht das genau so).
die IP des absenders zu manipuliren wäre (sorry, aber) absoluter schwachfug, wie sollte man dann jemals eine antwort bekommen wenn man etwas anfordert? one-way funktioniert sowas nicht, man braucht ein bidirektionales protokoll und dafür muss man absender und empfänger miteinander verbinden. die einzige kunst dabei ist es, allen zwischenstationen nicht zu verraten, ob man schon ein endstück der kommunikation ist oder auch nur eine von vielen nodes.
und große provider würden dir deinen anschluss kündigen, wenn du falsche IPs in deinen packeten angibst, weil du damit auch deren router durcheinander bringst und sie auch nicht wollen, dass leute aus anderen netzen mit falschen absender IPs eine DOS attacke gegen sie starten. deswegen wird aus reinem selbstschutz so ein packet eigentlich nicht weitergeleitet.
sogar mein kleiner billig D-link router leitet keine packete weiter die eine unautorisierte IP für das netz haben.
an sich muss man nichts anderes tun, als der router einer firma, wenn der daten weiterleitet, weiß von außen auch niemand an wievielen stationen die packete noch weiterführen bis sie einen empfänger treffen oder ob nicht sogar der router selbst schon der empfänger ist.
diese art der kommunikation wäre sogar nicht verbietbar, weil man nichts anderes machen würde, als das internet auch schon seit ewigkeiten macht, blos etwas 'erweitert', weil man nicht selbst die route berechnen müßte wohin man ein packet schickt, sondern eine verbindung 'durchschleifen' würde.
rapso->greets();
-
rapso schrieb:
und wie willst du, bloss weil du IPs von vielen leuten kennst die das programm haben, die packete die transportiert werden in irgendein zusammenhang mit den IPs der empfänger und absender zusammenbringen???
Das ich genau jedes Paket zuordnen kann, hab ich nicht behauptet.
Es gibt aber das Problem, dass die IP's so verteilt werden müssen, dass keine Rückschlüsse auf die "echten" IP's möglich sind.Ein anderes Szenario wäre, jemand hat Deine IP und macht damit irgendeinen scheiß. Wie dann dazu die rechtliche Lage bei uns oder in anderen Ländern aussieht, weiß ich nicht.
rapso schrieb:
du kannst übers internet keine daten verschicken, ohne bei "send" bzw "recv" eine IP zu haben.
Genau deswegen meinte ich vorhin eine Art Netz im "Netz". Die echten IP's finden in dem "Subnet" keine Verwendung.
Gruß
-
rapso schrieb:
camper schrieb:
du weisst nicht, ob der, der sich als server ausgibt, auch der server ist, den du willst;
1. ist das kein nachteil, sondern genau das was du möchtest
2. du willst keinen server kennen, du möchtest nur ein datenpacket (das man mit md5 signiert bzw könnte man gleich nach einem packet mit einer gewissen md5 signatur pingen)mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst. das erzeugt schon mal ne menge overhead, denn du must ja auch erst mal an die prüfsumme kommen, z.b. über thex-trees. ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehen (und das ist leider keine graue theorie), und du hast ja keine möglichkeit diesen zu identifizieren und von der transportroute auszuschliessen, weil diese ja anonym ist. kombiniere das mit dem prinzipbedingten geringen datendurchsatz und du erreichst nur eine geringe verfügbarkeit von daten, je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie oder nur fehlerhaft bekommst. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
-
Magoon schrieb:
Das ich genau jedes Paket zuordnen kann, hab ich nicht behauptet.
Es gibt aber das Problem, dass die IP's so verteilt werden müssen, dass keine Rückschlüsse auf die "echten" IP's möglich sind.solange du ein packet zu keiner IP zuordnen kannst, kannst du jeden temporären IP inhaber so verklagen wie du auch t-online verklagen kannst, weil alle nur packete weiterschieben und niemand weiß wer es nun schlussendlich für sich behält.
Magoon schrieb:
Ein anderes Szenario wäre, jemand hat Deine IP und macht damit irgendeinen scheiß. Wie dann dazu die rechtliche Lage bei uns oder in anderen Ländern aussieht, weiß ich nicht.
wie gesagt, außerhalb deines privaten netzes kannst du keine falschen IPs durch die gegend schicken (jedenfalls sperren das die INet-provider). somit kannst du nichts anstellen.
Magoon schrieb:
Genau deswegen meinte ich vorhin eine Art Netz im "Netz". Die echten IP's finden in dem "Subnet" keine Verwendung.
es geht nicht um das netz an sich, sondern um das verschleiern der endpunkte. ein netz im netz ist vielleicht ne nette bezeichnung einer ISO ebene, aber es ist ja nur logisch das ein neues protokoll auf eine bestehende protokollschicht aufbauen würde.
rapso->greets();
-
camper schrieb:
mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst.
soweit ich weiß, läuft das bisher immer so bei bestehenden shared networks, es gibt nunmal immer eine atomare packetgröße z.b. 512kb?
camper schrieb:
denn du must ja auch erst mal an die prüfsumme kommen
ja, dafür sind eben die von mir beschriebenen suchfunktionen da.
camper schrieb:
ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehen
ja, deswegen, wie ich schonmal schrieb, prüft jede node vor dem weiterleiten die validität eines packetes und bei fehlern wird es nicht weitergeschickt und die node die es schickte wird in dem lokalen rating des clients runtergesetzt und er ping woanders nach dem packet mit der bestimmten md5 summe.
camper schrieb:
und du hast ja keine möglichkeit diesen zu identifizieren
doch, nach dem ersten kaputten md5 packet. er wird ja wohl kaum ein packet generieren können das die gleiche MD5 prüfsumme hat aber nen anderen inhalt.
camper schrieb:
kombiniere das mit dem prinzipbedingten geringen datendurchsatz
gerade bei oft verlangten dingen wie z.b. einem neu erschienenem demo würden sehr viele das mitsniffen und so wäre die effektivität relativ hoch
camper schrieb:
je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie
ja, das ist eines der grundlegenden "gesetze" in allen p2p, wäre also nichts besonderes
camper schrieb:
oder nur fehlerhaft
das wird extrem selten passieren, da kaum jemand ein fehlerhaftes packet weiterleiten wird und falls man doch eines bekommt, weiß man dass der unmittelbare nachbar es kaputt gemacht hat und schliesst ihn aus dem netz aus von der eigenen seite aus und wenn das jeder macht, dann kann er jedem nur 1 kaputes packet schicken und hat dann funkstille
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
rapso->greets();
-
rapso schrieb:
camper schrieb:
mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst.
soweit ich weiß, läuft das bisher immer so bei bestehenden shared networks, es gibt nunmal immer eine atomare packetgröße z.b. 512kb?
diese grösse variiert von netzwerk zu netzwerk und datei zu datei, z.b.:
kazaa, winmx, opennap - datensicherheit ? vergiss es :p
BT - je nach torrent 32KB - 4MB
edonkey2000 - 9.5mb, ggf. 190KB mit emule
Gnutella1/2 - je nach tiefe des thex-baumes(normal 9, dann 1/256 der datei aufgerunded auf nächste 2er potenz) min 1024Bytees gibt dabei aber einen wesentlichen unterschied, der sender ist nähmlich immer bekannt; wenn wir zufällige übertragungsfehler (und sabotierte netzwerkprozessoren) ausschliessen, kann der schuldige immer identifiziert werden. anders bei anonymisierten daten - wenn die grösse des prüfpackets grösser als die kleinste auftretende MTU ist, dann zerfällt das packet, und es gibt keine garantie, das alle teile aus derselben quelle stammen. und das bedeuted eben, das das elementare datenpaket, das selbständig überprüft werden kann sehr klein ist ( evtl. < 576 bytes ), was wieder enormen overhead für die prüfsignatur bedeutet.
camper schrieb:
denn du must ja auch erst mal an die prüfsumme kommen
ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehenja, deswegen, wie ich schonmal schrieb, prüft jede node vor dem weiterleiten die validität eines packetes und bei fehlern wird es nicht weitergeschickt und die node die es schickte wird in dem lokalen rating des clients runtergesetzt und er ping woanders nach dem packet mit der bestimmten md5 summe.
und woher weiss der überprüfenmde node, dass das packet invalid ist? ich meine ja gar nicht von veränderungen, die dazu führen, dass die angehängte prüfsumme nicht zum packet passt, sondern falsche daten, bei denen auch die signatur verändert wurde, so dass die integrität des packets gewährleistet ist. woher weiss dann der node, dass dieses packet unerwünscht ist, schliesslich kann nur der empfänger die signatur der gewünschten packete kennen (andernfalls wäre einerseits die anonymität verloren, andererseits kannst du die übertragungsroute nicht wechseln, denn logischerweise wäre die korrekten signaturen nur nodes bekannt, die die gesamte kommunikation mitgehört haben, bei fehlern fängst du also von vorne an)
camper schrieb:
kombiniere das mit dem prinzipbedingten geringen datendurchsatz
gerade bei oft verlangten dingen wie z.b. einem neu erschienenem demo würden sehr viele das mitsniffen und so wäre die effektivität relativ hoch
nimm doch BT
camper schrieb:
je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie
ja, das ist eines der grundlegenden "gesetze" in allen p2p, wäre also nichts besonderes
gilt so allgemein eigentlich nur bei bestimmten netzwerken.
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
erklär das bitte nochmal, vielleicht hast du es tatsächlich schon, aber ich begreife es nicht. es gibt ja noch andere anfälligkeiten.
-
camper schrieb:
diese grösse variiert von netzwerk zu netzwerk und datei zu datei, z.b.:
kazaa, winmx, opennap - datensicherheit ? vergiss es :p
BT - je nach torrent 32KB - 4MB
edonkey2000 - 9.5mb, ggf. 190KB mit emule
Gnutella1/2 - je nach tiefe des thex-baumes(normal 9, dann 1/256 der datei aufgerunded auf nächste 2er potenz) min 1024Bytewas willst du mir damit sagen? oder bestätigst du mir dass wir packete mit fester größe haben die wir validieren können?
camper schrieb:
es gibt dabei aber einen wesentlichen unterschied, der sender ist nähmlich immer bekannt; wenn wir zufällige übertragungsfehler (und sabotierte netzwerkprozessoren) ausschliessen, kann der schuldige immer identifiziert werden. anders bei anonymisierten daten - wenn die grösse des prüfpackets grösser als die kleinste auftretende MTU ist, dann zerfällt das packet, und es gibt keine garantie, das alle teile aus derselben quelle stammen.
doch, gibt es, schliesslich hollt man sich ein ganzes packet von einer quelle udn nicht nur eine MTU. jede node besorgt sich dann erst ein packet und schickt es dann erst weiter (deswegen sollten die packete nicht zu gross sein, sonst könnte die latenz zu groß werden)
camper schrieb:
und das bedeuted eben, das das elementare datenpaket, das selbständig überprüft werden kann sehr klein ist ( evtl. < 576 bytes ), was wieder enormen overhead für die prüfsignatur bedeutet.
die größe eines packetes kann ein protokoll selbst bestimmen, dafür muss man sich nicht auf die layer darunter beschränken müssen, das machen nur weniger protokolle.
camper schrieb:
und woher weiss der überprüfenmde node, dass das packet invalid ist?
es möchte das packet mit der MD5 von ZA545azerw... und beim erhalt macht es für das packet den MD5 check.
wo ist das problem?
ich meine ja gar nicht von veränderungen, die dazu führen, dass die angehängte prüfsumme nicht zum packet passt, sondern falsche daten, bei denen auch die signatur verändert wurde, so dass die integrität des packets gewährleistet ist. woher weiss dann der node, dass dieses packet unerwünscht ist, schliesslich kann nur der empfänger die signatur der gewünschten packete kennen (andernfalls wäre einerseits die anonymität verloren,
wieso sollte nicht jeder die md5 prüfen von dem packet, das er mittels der MD5 angefordert hat?
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
erklär das bitte nochmal, vielleicht hast du es tatsächlich schon, aber ich begreife es nicht. es gibt ja noch andere anfälligkeiten.
ok, noch einaml
1.du suchst "debian", dazu schickst du das suchpacket an alle dir unmittelbar bekannten nodes und stellst im packet ein "mindestens 5 nodes soll das packet passieren"
2.die nachbarnodes schicken das packet weiter mit "mindestens 4 nodes soll das packet passieren" und schicken dir eine SessionID.
3.die nachbarnodes der nachbarnodes schicken das packet weiter mit "mindestens 3 nodes soll das packet passieren" und schicken deiner nachbarnode eine SessionID für diese kommunikation (NUR FÜR DIE KOMMUNIKATION ZWISCHEN DEN BEIDEN), die packete selbst müssen von jeder node zwischen den einzelnen sessionIDs geroutet werden.
das ganze soweiter bis "mindestens 0nodes soll das packet passieren" im request steht.
4. die letzten nodes leiten das requestpacket noch weiter oder beantwortet nun mit ihr bekannten files (die deiner suchanfrage entsprechen) zu der vorherigen node zurück. dabei steht neben jeder datei eine MD5 summe.
5. diese routet das antwortpacket weiter zurück
das so weiter bis es bei dir ankommt.
wie du sehen kannst, weiß niemand beim request, wer der letzte und wer der erste der kette war.6. du bekommst nun ne auflistung mit möglichen files.
7. du möchtest eines der files nun downloaden, dafür requestest du nun erstmal mittels der beistehenden MD5 summe das packet, das dir alle MD5 summen der einzelnen packete des files liefert, dabei geht das ganze so vorsich wie beim ersten request (also siehe 1.)
8. wenn du nun das packet mit allen md5 summen erhalten hast, kannst du nach den einzelnen md5 summen requesten und zwar genau so wie in den vorherigen beiden fällen.
bei der übertragung wird dabei natürlich jedes packet erst von einer node weitergeschickt, nachdem es vollkommen angekommen ist und die md5 summe des requesteten md5 packetes stimmte.
beachte bitte, dass du das packet mit der MD5 summe xy requestest und dass es das richtige ist kannst du ebenfalls mit der MD5 summe prüfen.
zudem weißt du, wenn ein fehlerhaftes packet von einer nachbarnode ankommt, dass nur sie es hätte falsch schicken können, denn wäre das packet schon bei ihr fehlerhaft angekommen, dann hätte sie das packet erst garnicht weiter geschickt, weil die MD5 summe nicht gestimmt hätte.
rapso->greets();
-
ok, ich hatte angenommen, dass die kommunikation zwischen client und server irgendwie gegen mitlesen gesichert wäre. in deinem falle könnte man möglicherweise dem client nicht so leicht falsche daten liefern, aber was ist mit dem server? die session id ist ja offen, ein bösartiger node könnte den server problemlos mit queries überfluten (nat. mit gefälschtem absender, nähmlich dem original client und dessen sessionid); worauf der server nur mit einem abort ö.ä. reagieren könnte, womöglich setzt er den client auf eine blacklist. ausserdem könnte ein node nat. jederzeit die verbindung einfach unterbrechen. und bei p2p netzwerken ist das ja normal und nicht einfach böse absicht. für eine alternative route musst du die gesamte verbindung neu aufbauen, alle daten, die gerade noch auf dem übertragungswege waren, wären verloren.
ein weiteres problem ist der suchalgorithmus. was hindert irgendeinen node daran, permanent queries im namen anderer zu senden? für den fall dass er sehr viele direkte nachbarn hat, könnte er einen signifikanten teil des netzes aufgrund des potentiell expontentiellen wachstums überfluten. ausserdem skaliert er nicht gut, wegen der ähnlichkeiten könnte das hier interessante lektüre sein:
http://www.tch.org/gnutella.html
-
camper schrieb:
ok, ich hatte angenommen, dass die kommunikation zwischen client und server irgendwie gegen mitlesen gesichert wäre. in deinem falle könnte man möglicherweise dem client nicht so leicht falsche daten liefern, aber was ist mit dem server? die session id ist ja offen, ein bösartiger node könnte den server problemlos mit queries überfluten (nat. mit gefälschtem absender, nähmlich dem original client und dessen sessionid); worauf der server nur mit einem abort ö.ä. reagieren könnte, womöglich setzt er den client auf eine blacklist. ausserdem könnte ein node nat. jederzeit die verbindung einfach unterbrechen. und bei p2p netzwerken ist das ja normal und nicht einfach böse absicht. für eine alternative route musst du die gesamte verbindung neu aufbauen, alle daten, die gerade noch auf dem übertragungswege waren, wären verloren.
ließ nochmal in der vorherigen post das dickgedruckte (irgendwie wuste ich, dass das nicht klar wird)
1. es gibt keinen server zwischen den nodes, jede node ist ihr eigener server und client
2. eine sessionID ist nicht öffentlich, eine sessionID ist nur für 2 kommunikationspartner bekannt.rapso->greets();
-
und wie verhinderst du, dass jemand mitliest? die sessionid muss schliesslich beim verbindungsaufbau mitübertragen werden. mit server und client bezog ich mich auf die jeweiligen endpunkte der verbindung.
edit: naja, vielleicht hast du auch recht, iss schon spät ... ich möchte ja auch nur behilflich sein schwachstellen aufzuzeigen
-
camper schrieb:
und wie verhinderst du, dass jemand mitliest? die sessionid muss schliesslich beim verbindungsaufbau mitübertragen werden. mit server und client bezog ich mich auf die jeweiligen endpunkte der verbindung.
edit: naja, vielleicht hast du auch recht, iss schon spät ... ich möchte ja auch nur behilflich sein schwachstellen aufzuzeigen
also nochmals
" und schicken deiner nachbarnode eine SessionID für diese kommunikation (NUR FÜR DIE KOMMUNIKATION ZWISCHEN DEN BEIDEN), die packete selbst müssen von jeder node zwischen den einzelnen sessionIDs geroutet werden."
vielleicht mal graphisch
clientA <--SID1--> clientB <--SID2--> clientC <--SID3--> clientD <--...rapso->greets();
-
Ach so, jetzt verstehe ich was Du meinst.
Soweit ich mich an die Funktionsweise von Freenet erinnern kann, entdecke ich bisher keinen Unterschied zu Deinen Ideen.
Gruß
-
emm... ich kannte freenet bisher nur als einen provider mit ziemlich schlechtem ruf *kopfkratz*
und ich hab es mir bis jetzt noch nicht angesehen wie die das ganze machen, aber wenn's das gibt, kann es der threadstarter ja gerne nutzen.
rapso->greets();
-
Ich habs auch noch nicht ausprobiert, aber falls Du es Dir mal anschauen möchtest: