|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
The analyzer can display around 100 Nodes. The limit is my memory. Since I've got only 512 MB RAM, I'm running with more than 100 nodes into an out of memory exception.
Wieviel TB RAM soll ein DDNS Server in Zukunft denn haben?
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 12:37 MEW (#2)
|
|
|
|
|
Der Analyzer simuliert 100 Knoten auf einem Rechner. Mittlerweile habe ich den memory verbrauch ein wenig gesenkt. Wenn 1 Knoten 10MB braucht, dann brauchen 100 Knote 1000MB.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Ist das nicht genau das den Spammer noch gefehlt hat?
Bis jetzt haben die immer "feste" Nameserver benötigt um ihre Webseiten zu betreiben.
Vor einiger Zeit gab es einen Bericht das Cracker einen RoundRobin-DNS auf würmerinfizierten Kisten aufgesetzt hätten. Alle 15-Minuten wurden die jeweiligen Rechner ausgetauscht und durch neue ersetzt. So kamm es das eine Pillenwebseite 3 Nameserver bei Comcast hatte und 15 Minuten später waren die Nameserver bei Wanadoo...
Man kannte am Betreiber/Hoster des DNS sehen welche Hutfarbe dieser hatte aber mit einen DDNS ist das nicht mehr möglich...
Ich stehe dem DDNS eher skeptisch gegenüber.
--
eat my .sig!
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 13:56 MEW (#4)
|
|
|
|
|
In der Tat ist das DDNS weniger kontrollierbar mit all den Vor- und Nachteilen.
Beim Spam muss ebenfalls eine Lösung her, aber das sollte meiner Meinung nach unabhängig vom DNS oder DDNS geschehen.
Einen guten Ansatz finde ich hashcash.org. Für jede Mail muss etwas gerechnet werden. Einen ähnlichen Mechanismus verwendet DDNS, wobei das Projekt darauf abzielt nicht nur "sinnlose" hashes zu berechnen, sondern die Rechenzeit allen zur Verfügung stellt. Wenn das auch mit dem Mail funktionieren würde, dann könnte man den Spammern das Leben schwer machen.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Sorry, aber Spammer sind Diebe, denen ist es egal wieviel die Zombieboxen rechnen müssen.
Es werden einfach noch 10, 20, 50 oder 100 zusätzliche Rechner dazugenommen für den Spamrun.
Spammern macht man das Leben schwer wenn man:
1) gegen Sie vorgeht,
2) gegen die Aufteraggeber der Spammer vorgeht,
3) ihnen die Infrastuktur entzieht.
--
eat my .sig!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 15:26 MEW (#7)
|
|
|
|
|
Ja, aber sie haben nicht beliebig viele Zombieboxen.
Wie wäre es mit einem Mail-System, welches die Rechenzeit so wählt dass ein durchschnittlicher Rechner pro Tag z.B. 100 Mails verschicken kann. Mit 10 Kisten könnte man 1'000 Mails verschicken und mit 100 Kisten 10'000 Mails.
Ich will damit sagen dass man das Spammen nicht verhindern kann, aber durchaus vermindern.
Ich sehe die Liste wie man gegen Spammer vorgeht langfristig ein bisschen anders:
1) Mails mit einer knappen Ressource verbinden (z.B. Rechenzeit)
2) Kisten sicherer machen (Infrastuktur entziehen)
-> Damit würde bei deiner Liste 1) und 2) wegfallen. Da Spammer die Kisten selber zahlen müssen und Kosten/Nutzen nicht mehr stimmt, wenn die Bestellungen anhand von Spam Mails nicht gross ist.
Da das aber nicht von heute auf morgen geht, ist heute vermutlich deine Liste die bessere Wahl.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
CERT Advisories empfangen ca. 23000 Personen, dann bräuchte man 230 Mailserver um die Mails zu versenden?
Warum einen oder mehrere Megamailserver anschaffen, wenn man es mit herkömmlichen Rechnern auch machen kann?
--
eat my .sig!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 16:38 MEW (#11)
|
|
|
|
|
Das Bezahlen mit Rechnen funktioniert nur mit einer Whiteliste. Ist eine Adresse in der Whiteliste drin, muss er nichts rechnen. Dann klappt das auch mit dem Maillisten.
Jeder der die Adresse der Mailingliste nicht in seiner Whitelist hat wird, bekommt gar keine Mails, denn der CERT Mailserver ist kein MegaComputer.
Somit bestimmt der User welche Mails er von welcher Mailingliste empfangen will. Ein austragen aus der Mailingliste erfolgt über seine Whiteliste.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
ich glaube kaum das man so einen mechanismus sicher machen kann. die werden innert kürzester zeit herausgefunden haben wie man das hash berechnen umgeht.
was ich viel effizienter fände wäre wenn jede person eine auf sich eindeutig und weltweit einzigartig zugewiesene id bekäme mit der nur sie mailen kann. mit dem ganzen tcpa(oder wie es jetzt heisst) welches ja von linus unterstützen will könnte man das sehr sicher machen denke ich mal.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Bezahlen mit Rechnen funktioniert nur mit einer Whiteliste. Ist eine Adresse in der Whiteliste drin, muss er nichts rechnen. Dann klappt das auch mit dem Maillisten.
Naja, das mit den Whitelists kannste vergessen. Die Leute schaffen es schon heute nicht, Listenmails, die in ihrer Spambox landen, zu lesen, und dafür zu sorgen, dass dies nicht merh vorkommt.
Wie willst du die Leute also dazu kriegen, dich in die Whitelist aufzunehmen?
Und sollen die Provider dann für jeden einzelnen user ne Whitelist führen? Nene, das klappt leider so nicht ;-( Schön wärs schon, aber leider nicht praktikabel.
Achja: Die Spammer haben genügend Boxen! Sasser hat millionen von Kisten erwischt! Mit der richtigen Software werden die zu Relays. Also, 1Mio Ksiten mal 100 Mails gibt wieder nen vollen Spamrun auf 100Mio Adressen.
|
|
|
|
|
|
|
|
|
|
|
|
|
> Wie willst du die Leute also dazu kriegen, dich in die Whitelist aufzunehmen?
Da muss man hart bleiben: Wird die Mail nicht in die Whitelist eingetragen werden sie aus der Liste wieder ausgetragen. Der Benutzer entscheidet mit seiner Whiteliste aus welchen Maillisten er Mails empfangen will.
Ich sehe aber auch das Problem. Das ganze ist nicht sehr DAU freundlich. Ich kann mir Vorstellen dass Herr DAU sich schon 16 Mal bei einer Liste eingetragen hat und immer noch keine Mails bekommt.
Mit dem Pay-by-computing Prinzip kann man Spam nicht verhindern aber zumindest vermindern. Angenommen die 1Mio Kisten haben keine Begrenzung und können soviel Mails verschicken bis die Leitung glüht. Das gibt wesentlich mehr als 100Mio Adressen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 05. May 2004, 07:58 MEW (#23)
|
|
|
|
|
Wie wäre es mit einem Mail-System, welches die Rechenzeit so wählt dass ein durchschnittlicher Rechner pro Tag z.B. 100 Mails verschicken kann.
M.a.W. wird das Versenden einer Nachricht meine Kiste 14 Minuten auslasten. Ich sag' dann also meinen anrufenden Kunden "nein, sorry, ich werde mich in einer Stunde um Dein Problem kümmern, ich habe gerade ein paar Mails abgeschickt" oder "ich schick' Dir einen Link, in etwa 2 Stunden ist der da, es sind noch 8 Mails in der Queue ...".
Wieso gibt es so viele Leute, die beim Lösen eines Problems eine ganze Batterie neuer Probleme produzieren wollen?
Da sind mir Lösungsansätze wie z.B. SPF deutlich sympathischer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Es geht darum eine Zeit zu finden die den normalen Benutzer nicht stört, den Spammer schon. Ich glaube mal gelesen zu haben, dass es reichen würde nur einige Sekunden etwas zu rechnen. Ich kenne mich in diesem Gebiet zu wenig aus. Das Zahlenbeispiel ist willkürlich gewählt es können genauso gut auch 1'000 oder 10'000 Mails pro Tag sein.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wen interessiert wo die Spammer ihre DNS haben? Ausserdem koenntest du auch im DDNS eine Blacklist machen.
Eine Techonlogie nicht einfuehren, nur weil auch Spammer davon profitieren koennen? Dann sollte man wohl das Internet wieder abschaffen ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
Wie sicher ist das in Bezug auf Manipulation?
Wenn ich einen Mitbewerber nicht mag, dann kann ich den DNS-Eintrag so umbiegen das er auf meinen Webserver zeigt? Ich bekomme all seinen Traffic/Kunden er nichts!?
Wer ist die oberste Instanz für die Blacklist? (Ich, der Entwickler, oder Steve Linford oder ICANN? Wird die Blacklist auch per P2P verteilt?
--
eat my .sig!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 16:30 MEW (#10)
|
|
|
|
|
Im DDNS gibt es die Regel: "Die Mehrheit bestimmt". Wenn man nur einen Eintag umbiegt, dann mach das nichts, denn es gibt mindestens (in der momentanen Implementation) 19 weitere Knoten die den Eintrag haben.
Es wird mindestens 3 Ergebnisse der Suche abgewartet, und dann das Resultat geliefert.
Um überhaupt den Eintrag umbiegen zu können muss die NodeID des Knotens nahe an der ID des Namens liegen, und da die NodeID abhängig ist von der Internet Adresse, müsste man die Internet Adresse (IP) frei wählen können um einen Angriff zu starten.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
> Es wird mindestens 3 Ergebnisse der Suche abgewartet, und dann das Resultat geliefert.
Beispeil: Alice will Bob taeuschen: Alice betreibt bei dem Provider von Bob sehr viele DDNS-Nodes. Die Nodes von Alice haben eine gefaelschte Domain, wenn Bob diese Domain verlangt, dann erhaelt er moeglicherweise zwei oder mehr Antworten sehr schnell, alle von Alice, und wird ihr glauben. Die korrekte Antwort von Charles wird Bob aber aber nur dazu bringen, Charles auf die Blacklist zu setzen, umso besser fuer Alice.
Um das auszuschliessen, muesste zu jeder Domain noch ein Zertifizierungscookie des Registrars mitgeliefert werden -> sehr aufwaendig in der Administration.
DNS ist gebaut mit moeglichst kurze Latenzzeit und Overhead als Ziel, P2P hat leider immer mehr Overhead und Latenzzeit als zentralisierte Loesungen. Warum sollte jemand drei Antworten fuer eine so simple Anfrage benoetigen?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 18:59 MEW (#18)
|
|
|
|
|
Mit "nahe" meine ich dass die NodeID und die ID des Namens nahe sind, im Fall von DDNS heisst nahe: je kleiner xor(NodeID,ID des Namens) desto näher sind sie beisammen. Die Antwortzeit spielt nur eine kleine Rolle. Die Wahrscheinlichkeit dass Alice einen Node betreibt, der nahe an einem Namen, der von Bob gesucht wird, ist klein (Falls die NodeIDs alle gleichmässig verteilt sind).
Solange Bob andere Knoten ausser Alice kennt, ist die falsche Aussage von Alice nicht so schlimm, da eine Weitergabe von falschen weiteren Adressen von Alice nichts bei Bob bewirkt. Das Problem ist wenn Bob von Anfang an Alice fragt und Alice nur Informationen über seine gefälschten Knoten weitergibt, dann lässt sich Bob täuschen. Das lässt sich nicht verhindern. (Aber das Problem existiert auch beim DNS. Wer garantiert mir dass der DNS von meinem Provider, den ich per DHCP bezogen habe, richtig funktioniert? Im DDNS wäre die Frage: Wer garantiert mir dass die Bootstrap Node richtig funktioniert?)
Es ist aber auch möglich wenn Bob zwar andere Knoten kennt, aber mit Alice anfängt, da per Zufall die NodeID am nächsten ist. Dann kann es passieren dass wenn Alice sehr schnell 2 weitere Knoten zurückgibt die ebenfalls das falsche Resultat liefern.
An das hab ich noch nicht gedacht, und muss das noch in mein Programm aufnehmen. Die Lösung könnte so aussehen, dass am Anfang x Knoten gleichzeitig befragt werden und erste wenn y Knoten eine Antwort liefern, dann wird eine Auswertung gemacht. Das ist aber nur bei der allerersten Frage nötig. Damit lässt sich die Wahrscheinlichkeit senken, dass ein falsches Resultat geliefert wird.
In Sachen Geschwindigkeit ist DNS ungeschlagen DDNS kann nicht mithalten da eine Suche im DDNS immer einen Aufwand von O(log n) benötigt. (n ist die Anzahl Knoten im System). Ebenfalls wird DDNS nie mit 100%-iger Sicherheit ein Ergebnis zurückliefern. Aber das Ziel ist es so nahe an 100% zu sein wie möglich.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
> Wie sicher ist das in Bezug auf Manipulation?
Das frage ich mich auch...
Die Projektseite ist sehr sparsam mit Details. Besonders beschaeftigt mich die Frage, wie denn die Registrierung von Namen funktionieren soll. Kann da jeder beliebige Namen reservieren, oder bleiben die bekannten domain registries fuer second-level Domains in Betrieb? Wenn ja, haben wir immer noch zentrale Stellen. Dann waere DDNS einfach erweitertes Caching, ist den Aufwand kaum wert.
Die Blacklist, die ich vorhin erwaehnte, waere fuer Domainnamen. So dass deine Node Anfragen fuer Domains in der Blacklist nicht beantwortet. Die kannst du selbst verwalten oder sonstwoher beziehen, wie bei bisherigen RBLs auch.
Auf der Projektseite kommt der Begriff Blacklist auch vor, dort bezieht er sich aber auf andere Nodes. Nodes die falsche Resultate liefern, werden geblockt.
Interessant find ich den "Pay by computing"-Ansatz. Dass wer Namen einfuegen will, zuerst zeigen muss dass es ihm was wert ist indem er was aufwaendiges rechnet. Find ich allerdings nicht gerade passend, weil viele Nameserver lahme Kisten sind.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 17:01 MEW (#13)
|
|
|
|
|
Jeder UTF Name kann gespeichert werden. Es wird aber nur die Hash vom Namen gespeichert (160 Bit SHA).
Für eine Subdomain Abfrage gibt es noch eine Punktregelung, dass ein Name maximal 0 oder einen Punkt haben darf. Damit können auch weitere Subdomains abgefragt werden, die nicht nach dem "Pay by computing" funktionieren.
Weitere Zeichen die nicht verwendet werden sollen sind @ und :
Erlaubt sind gemäss der Punktregelung folgende Namen
Symlink
Symlink.ch
Symlink.schweiz
-=symlink=-
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann gaebe es also keine Registrars mehr?
Wer bestimmt dann, wer welche Namen erhaelt, und wie fallen unbenutzte Namen aus dem DDNS raus?
Ich geh wohl mal "google" im DDNS registrieren :)
Kann mir keiner mehr wegnehmen, oder?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 17:57 MEW (#16)
|
|
|
|
|
Im DDNS gibt es keine Registrars.
Es gilt das Prinzip "first come, first served" ohne wenn und aber. Den Namen muss man immer wieder refreshen, momentan ist es alle 2 Stunden, das wird sich aber auf Wochen oder Monate ändern. Erfolgt kein Refresh, dann verschwindet der Name.
;) Momentan ist es noch so dass im Prinzip jeder deinen Namen wieder wegnehmen kann wenn man weiss wie, denn es ist noch nicht alles implementiert was das System einsetzbar macht.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Hehe, jetzt hab ich endlich begriffen dass DDNS nix mit unserem implementierten DNS zu tun hat. Ich erspar mir mal Kommentare wie realistisch das ist, es geht ja um den Beweis der Machbarkeit, nicht um die weltweiten Implementation ;-))
Wenn ich meine Namen alle zwei Stunden updaten muss, dann ist das System verwundbarer als das momentane DNS. Dann genuegt naemlich ein Ausfall meiner Nameserver, und mein Name ist nicht mehr bekannt auf dem Netz nach zwei Stunden. Schlimmer noch, irgend ein Penner koennte sich den Namen registrieren. Also muesste Alice nur einen kurzen DDOS gegen die Nameserver von Bob fahren, und schon koennte sie den Namen "bob" uebernehmen.
Da gibt es eine einfache Massnahme: Ein Public Key zertifiziert den Domainnamen, innerhalb einer gewissen Zeit (z.B. eine Woche) darf nur der Besitzer des Schluesselpaars den Namen updaten. Das ist wohl schon implementiert? (Bin zu faul den Source Code zu lesen)
Problematisch wird es, wenn jemand das Schluesselpaar klaut, wer darf dann den Namen updaten? In einem P2P-Netz wuerde der mit der groesseren Rechenkapazitaet auch den Namen kontrollieren koennen. Um dieses Problem zu loesen, braeuchte es, zack, wieder eine zentrale Reglierungsstelle.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 19:40 MEW (#19)
|
|
|
|
|
2h sind nur zum Testen, wenn es dann mal richtig gemacht werden soll (weltweiten Implementation ;-))), dann muss die Zeit auf Wochen oder Monate gesetzt werden.
PK ist im Prinzip drin, aber noch nicht aktiviert, ein Name kann nur von einem Packet, dass korrekt signierten ist, upgedated werden.
Der der mehr Rechenleistung hat, kann mehr Namen speichern. Es gilt immer das Prinzip "first come, first served".
DDOS: Es gibt noch gecachte Namen im System, die ebenfalls geDDoSt (*neudeutch*) werden müssen. Gleichzeitig muss Alice verhindern dass Bob seinen Namen auf anderem Knoten speichert. Angenommen Alice würde auch das tun, dann gibt es das Problem, dass wenn der DDOS aufhört und die Knoten wieder auftauchen, dann sind die Knoten von Alice weiter weg als die von Bob und Bob wird wieder gefunden. Es müsste also ein permanenter DDOS, oder zumindest solange bis neue Knoten auftauchen die näher sind als Bobs Knoten.
Der DDOS müsste ziemlich effizient sein. nehmen wir an Bob hat seinen Namen auf 50 Knoten gespeichert, wenn 5 Knoten überleben, die auch gefunden werden, dann kann Alice den Namen nicht übernehmen.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok, wenn die Domainnamen per PK signiert werden, dann funktioniert das System.
Das mit der Distanz der Nodes untereinander versteh ich nicht ganz. Ist diese Naehe zufaellig (die ID einer Node wird zufaellig gewaehlt) oder absichtlich (die Nodes einer Organisation sind wegen ihrer aehnlichen IDs nahe beieinander)?
Bleibt das Problem der verlorenen/gestohlenen Schluesseln. Ich mach wieder ein schoenes Beispiel: mit Andy der eine (natuerlich erfolgreiche) Webseite unter dem Namen "dandy.andy" betreibt und BBonnie die seinen Private Key klauen[1] konnte. Nun hat BBonnie ein Update gemacht, der Name "dandy.andy" zeigt jetzt auf "goatsex". Die treue Leserin Cindy wird einen misshandelten Arsch sehen - anstelle Andys Dating-Seite. Dumm nur, dass Andy _technisch_ ueberhaupt nix machen kann! Die Eintraege von BBonnie sind genauso gueltig wie die von Andy. Deshalb gruendet Andy die "Unabhaengige Organisation DittyWatch" die zwei Listen fuehrt: eine Blacklist geklauter Schluessel sowie eine Whitelist fuer neue Schluessel zu bestehenden Namen. Alle Nodebetreiber sollen doch bitte seine DittyWatch Listen verwenden... natuerlich kann man seine Namen schon vorher bei DittyWatch registrieren, damit bei Schluesselklau sofort reagiert werden kann. Voila un registrar, es geht nicht ohne.
[1] Wie war das moeglich? - BBonnie arbeitet fuer das FBI und weiss wie PGP geknackt wird - aber psst!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 04. May 2004, 23:04 MEW (#21)
|
|
|
|
|
Das beste wäre wenn die ID zufällig gewählt wird, da man das aber nicht garantieren kann und Alice die ID so wählen kann dass die ID nahe an der ID von Bob liegt, muss man die IP heranziehen. Die IP lässt sich nicht frei wählen, da wacht die ICANN darüber (es geht tatsächlich nicht ohne eine zentrale Instanz). Somit ist die NodeID die sich unter anderem aus der IP zusammensetzt nicht Verfälschbar und es lässt sich überprüfen ob ein IP mit einer ID übereinstimmt.
Schlüsselklau: Ist der Private Key weg, ist auch der Name weg. Das ist aber auch nicht anders als bei der digitalen Signatur/Verschlüsselung.
Das ständige gegenseitige Updaten sollte jedoch nicht passieren, da muss noch ein Mechanismus her um einen neuen Public Key zu speichern falls dieser mit dem gültigen alten Key unterschrieben wurde. Danach wird sehr wahrscheinlich BBonnie den Namen übernehmen. Aber das ewige hin und her hört auf. Da bleibt Andy nur noch ein: Den Namen "therealdandy.andy" zu registrieren und besser auf seinen Schlüssel aufpassen.
Oder eine andere Möglichkeit (vermutlich bessere) wäre es einen Revocation Request zu starten. Jeder mit einem gültigen Privaten Schlüssel kann diesen Request schicken, danach wird der Name nicht mehr aufgelöst, so kann Andy oder auch BBonnie die Seite abschalten. Das ewige hin und her würde auch aufhören und Andy müsste sich ebenfalls "therealdandy.andy" zulegen.
Der Private Key liegt momentan plain-text im Directory, daher sollte noch zusätzlich eine Passwort Verschlüsselung her, damit das Klauen nicht einfach wird. Ich frag mich bloss wie sich dann DDNS automatisch starten lässt. (z.B. nach Stromausfall).
Da gab es doch einen ähnlichen Fall mit sex.com. Ein Telefonat und die Domain war weg, danach folgten 6 Jahre Gerichtsverhandlungen... http://www.circleid.com
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und wie verifiziert man die PublicKeys? Wenn man die neuen Keys jeweils mit dem alten signiert, lässt sich ein Key zwar als legitimer Nachfolger bestimmen, aber was ist mit dem ursprünglichen Key? Solange das nicht gelöst ist, lässt sich mit einer MIM-Attacke in der Nähe eines grossen Providers in kurzer Zeit ein netter Katalog von Domains erstellen, die jederzeit manipuliert werden können.
Was den Gerichtsfall angeht, so war das eine selten blöde Angelegenheit. Der Registrar war offensichtlich der Meinung, das er laut Vertrag nicht dazu verpflichtet war, zu prüfen, ob der Änderungsantrag wirklich vom Domaininhaber stammt. Sämtliche angerufene Gerichte haben ihm aber zu verstehen gegeben, dass er dem Inhaber die Domain vertraglich zugesichert hat, und das die unatorisierte Übertragung somit ein Vertragsbruch ist. Bei solchen Fällen ist das US-Recht eindeutig (ausnahmsweise ;-). Leider sind in deren Rechtssystem jahrelange Streitigkeiten auch bei völlig klarer Rechtslage durchaus möglich.
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
Kannst du die "Man-In-the-Middle" Attacke genauer erklären? Das Abfangen des neuen unterschriebenen Schlüssels ist für den MIM wertlos, solange der den Private Key nicht kennt.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok danke, hab das Prinzip nun begriffen. In der Tat sehe ich für dieses Problem keine Lösung.
Das Problem gibt es immer solange nur ein Weg ins Netz führt. Gibt es bei diesem Weg eine MIM-Attacke, dann gibt es nur eine Möglichkeit: Der Public Key muss auf einem anderen Weg ins Netz gelangen.
Das WoT geht einen sozialen Weg, mit PGP Signing Parties, etc.
Die CAs können zwar eine Identität bestätigen, jedoch ein MIM kann ebenfalls bei der CA einen Key bestellen. Damit kann man eine MIM Attacke nicht verhindern aber zumindest feststellen wer es war.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und Spammerlisten werden veröffentlicht...
http://www.crypto-world.com/spam/spam.html
http://news.spamcop.net/pipermail/spamcop-list/2003-June/044987.html
__
Husch, das war's.
|
|
|
|
|
|
