Das NLnet Projekt: Versteckte Dienste beschleunigen

Versteckte Dienste bei Tor erlauben dem Nutzer anonyme Informationsdienste wie Webseiten zu erstellen, welche nur über das Tor-Netzwerk erreichbar sind und deren Aufenthaltsort geheim bleibt. Die kritischsten Einschränkungen von versteckten Diensten sind momentan die Zeit, die es dauert, bis ein versteckter Dienst im Netzwerk registriert ist und die Zeit die es dauert, bis eine Verbindung zum versteckten Dienst hergestellt ist, wenn ein Nutzer auf den Dienst zugreifen möchte. Auf Grund von Designproblemen im originalen Tor Protokoll kann eine Verbindung zu einem versteckten Dienst mehrere Minuten dauern, was dafür sorgt, dass die meisten Nutzer den Verbindungsversuch aufgeben, bevor die Verbindung hergestellt wurde. Versteckte Dienste für eine direkte, interaktive Kommunikation zwischen Nutzern zu verwenden (z.B. für Instant Messenger) ist auf Grund der hohen Latenz für den Verbindungsaufbau daher momentan nahezu unmöglich.

Das Ziel dieses Projektes ist es, versteckte Dienste zu beschleunigen, in dem sowohl die Methode, mit der Verbindungen zwischen den Nutzern und den versteckten Diensten hergestellt werden, als auch die Methode für die Registrierung von versteckten Diensten im Netzwerk, verbessert werden. In einem ersten Schritt wird eine präzise Diagnose von versteckten Diensten unter Labor- als auch unter Realbedingungen durchgeführt, um den Hauptgrund für die schlechte Performanz zu finden. Basierend auf diesen Diagnosen werden Optimierungsstrategien erarbeitet und auf mögliche unerwünschte Effekte für die Sicherheit und Anonymität des Tor-Netzwerks untersucht. Die vielversprechensten Lösungen werden dann implementiert, um eine Verbesserung für den Nutzer zu erreichen. In der Diagnosephase, sobald bekannt ist wo Zeit verloren geht und was für Verbesserungen wahrscheinlich sind, werden auch genaue Erfolgsmaßstäbe entwickelt. Das Ziel ist es, die Veränderungen am Protokoll von versteckten Diensten innerhalb von 12 Monaten entwickelt und in Tor integriert zu haben.

Dieses Projekt wird großzügigerweise gesponsert von:

Projekt	Fälligkeit
Etappe A: Analyse, Messungen und Problem eingrenzen Da das Protokoll von versteckten Diensten in den letzten Jahren nicht aktiv weiterentwickelt wurde, sind bestimmte Teilaspekte des Problems nicht ausreichend erforscht. Um die genaue Quelle für die Latenz und den Zeitverlust zu finden, muss eine ausführliche Analyse der Hintergründe durchgeführt werden. Etappe A wird ungefähr einen Monat benötigen. Die Ergebnisse der Analyse werden die Designentscheidungen von Etappe B beeinflussen.	15. Juni 2008
Etappe B: Design und Bewertung der nötigen Veränderungen Die Veränderungen an den versteckten Diensten werden Kernfunktionen des Tor Protokolls berühren und müssen daher genau auf mögliche Gefahren für die Sicherheit und Anonymität untersucht werden. Für die Design- und Überprüfungsphase, welche mit einer ausführlichen, externen Prüfung endet, sind 2 Monate vorgesehen	15. August 2008
Etappe C: Implementation Nach Design, Folgeabschätzung und externer Prüfung müssen die Veränderungen umgesetzt und in die aktuellen Torquellen eingepflegt werden. Die eigentliche Umsetzung der Veränderungenn wird etwa 2 Monate dauern.	15. Oktober 2008
Etappe D: Implementation und Evaluation der Änderungen bis zur Veröffentlichung Die Veränderung ist sehr kritisch für die Sicherheit und Anonymität des Tor-Netzwerks. Sie benötigt daher intensive Tests und Fehlersuche sowohl im Labor als auch unter realen Bedingungen. Wir planen für diese Phase 3 Monate ein, wobei der verantwortliche Entwickler 1/3 seine Zeit mit den Test verbringt. Ein Teil der Testphase wird eine öffentliche Betaphase beinhalten.	15. Januar 2009
Etappe E: Veröffentlichung Die eigentliche Veröffentlichung für das Tor-Server-Netzwerk wird mit dem regulären Veröffentlichungsplan von Tor abgestimmt. Da dieser Plan von mehreren externen Faktoren, wie zum Beispiel der Vervollständigung andere Softwareprojekte die in die gleiche Version einfließen sollen, abhängt, kann die Zeit zwischen Veröffentlichung und Installation auf den meisten Tor Servern variieren. Aus Erfahrung kann ein Zeitraum von 3 bis 4 Monaten angenommen werden.	15. Mai 2009

Monatliche Statusberichte

Es wird insgesamt acht monatliche Statusberichte geben. Der Erste wird mit dem Abschluss der ersten Etappe am 15. Juni 2008 erscheinen, der Letzte mit dem Abschluss der Tests und der Implementation am 15. Januar 2009.

Monat,	Statusbericht
Juni 08	Das ursprüngliche Ziel, das Problem, welches die versteckten Dienste verlangsamt, zu finden, wurde erreicht. Ein Teil dieser Analyse war es, die Verzögerung zu messen, die ein Nutzer erlebt, wenn er auf einen versteckten Dienst zugreifen möchte. Messdaten aus dem April 08 konnten dafür genutzt werden, zu erforschen welche internen Schritte wie lange dauern, wenn ein Nutzer sich zu einem versteckten Dienst verbinden möchte. Die Ergebnisse dieser Analyse sind in einem 22-seitigen Bericht (engl.) enthalten, der auf der Entwickler Mailingliste veröffentlicht wurde. Die Analyse hat ausserdem ein paar Fehler ans Licht gebracht, die für einen Teil der Verzögerung verantwortlich waren. Ein paar Fehler wurden direkt nach der Analyse behoben, andere werden bald behoben sein. Die Untersuchung hat ausserdem mehrere mögliche Performanzverbesserungsansätze gebracht. Mehrere der Ansätze können direkt umgesetzt werden, andere benötigen intensivere Untersuchungen und neue Messungen. Im Zuge der Analyse fanden wir auch heraus, dass einigen der Ansätze tiefgreifende Änderungen an Tor benötigen, die nicht direkt mit versteckten Diensten zusammenhängen. Diese Veränderungen können innerhalb der Zeitplanungen dieses Projektes nicht umgesetzt werden.
Juli 08	Alle in der Analyse gefundenen Fehler wurden behoben. Dies beinhaltet 2 Fehler die schon während der Analyse behoben wurden sowie 4 weitere Fehler, die in den letzten 30 Tagen entfernt wurden. Während die Fehlerbehebungen nur ungewollte Performanzprobleme auf Grund von Programmierfehlern behoben haben, werden einige der in der Analyse entdeckten Designveränderungen einen Einfluss auf Anonymität oder die generelle Netzwerklast im Tor-Netzwerk haben. Diese Einflüsse müssen gegen die individuellen Performanzsteigerungen evaluiert werden. Ein Bericht mit 7 möglichen Designveränderungen die diskutiert werden müssen, wurde auf der Entwicklermailingliste veröffentlicht. Bei mehreren Überprüfungen (genauer die Messungen bei niedrigen Bandbreiten und der "Grand Scaling Plan") hat sich herausgestellt, dass sie mehr Zeit als erwartet benötigen und sie wurden daher für eine spätere Etappe eingeplant. Der aktuelle Plan ist, diese Überprüfungen innerhalb eines Zeitraums bis zum 15. Januar 2009 zu erledigen und bis dahin mit Abschätzungen zu arbeiten.
Aug. 08	Während der letzen 30 Tage wurden 7 der vorgeschlagenen Designs weiter untersucht und diskutiert. Vier davon wurden im Hinblick auf die zu erwartenden Codeänderungen und Auswirkungen auf die Anonymität als machbar eingeschätzt. Eines wurde eher als Fehler als als Designveränderung gesehen. Zwei wurden auf Grund von unvorhersehbaren Sicherheitsauswirkungen oder unklarer Performanzgewinne ausgeschlossen. Zusammen mit den Ergebnissen vom 15. Juli wurde die Designphase beendet. Die Aufgaben für die kommende Umsetzung sind jetz klar: Ein Fehler muss behoben und 4 Designveränderungen müssen implementiert werden. Ausserdem müssen Untersuchungen des veränderten Designs zeigen, ob diese sinnvoll sind. Ein Bericht mit den Ergebnissen der Designphase wurde auf der Entwickler Mailingliste veröffentlicht.
Sep. 08	Während der ersten Hälfte der Umsetzungsphase konnten 2 Fehler behoben werden, die mit versteckten Diessnten zusammenhingen: der erste Fehler wurde bereits in der Designphase entdeckt und war für eine außergewöhnliche Fehlerrate beim Verfügbarmachen von versteckten Diensten verantwortlich; der zweite Fehler wurde in der Umsetzungsphase gefunden und war dafür verantwortlich, dass Verbindungen zu aktiven, versteckten Diensten fehlschlagen konnten. Beide Fehlerbehebungen werden in der nächsten unstable Version enthalten sein und werden wahrscheinlich auch in eine der nächsten stable Veröffentlichungen zurückportiert werden. Die vier Designveränderungen die in der Designphase überlegt wurden, wurden in einen experimentellen Zweig des unstable Entwicklungspfads eingebaut.Erste Funktionstests zeigen, dass diese Veränderungen funktionieren und bessere (gefühlte) Performanz bieten. Dies muss über die nächsten 4 Wochen in internen Tests überprüft werden. Das nächste Ziel ist es eine Version dieses experimentellen Zweigs für Betatester zu Beginn der folgenden Testphase zu veröffentlichen.
Okt. 08	Die Umsetzungsphase wurde beendet. Die Fehler die in den letzten 30 Tagen gefunden wurden, sind in der Entwicklerversion 0.2.1.6-alpha veröffentlicht worden. Die vier Designänderungen die identifiziert werden konnten, wurden in Vorschlag 155 spezifiziert. Drei Desiggnveränderungen wurden bereits in die Entwicklungscodebasis übernommen und werden in der nächsten Entwicklerversion automatisch enthalten sein. Die ersten beiden Designveränderungen verbessern die Verbindungsherstellung zu versteckten Diensten, in dem sie den die maximale Wartezeit von 60 auf 30 Sekunden reduzieren und parallel einen zweiten Verbindungsversuch nach 15 Sekunden starten. Die dritte Designveränderung beeinflusst die Veröffentlichung eines versteckten Dienstes im Netzwerk, in dem er gleichzeitig an 5 anstelle von 3 Stellen bekanntgemacht wird und sobald 3 Stellen etabliert sind, aufhört. Die vierte Veränderung hat sich als eher ineffektiv herausgestellt, würde allerdings erhebliche Codekomplexität hinzufügen und wurde daher abgelehnt. Aktuell gibt es keine weiteren Fehlerbehebungen und Designveränderungen die noch umgesetzt werden können. Alle Veränderungen sind in der Entwicklungsquellcodebasis und können in der nächsten Etappe getestet werden.
Nov. 08	Die Geschwindigkeitsverbesserungen wurden in der Tor-Version 0.2.1.7-alpha veröffentlicht. Benutzer können diese Entwicklungsversion direkt von der Tor Homepage runterladen und die Verbesserungen mit minimalem Aufwand testen. Ausserdem wurden 2 Fehler (1, 2) die während diesem Projekt gefunden wurden, in den stabilen Zweig übernommen und werden in der nächsten stable Version 0.2.0.32 enthalten sein. Die Hauptaufgabe der letzten 31 Tage war es, neue Messungen durchzuführen, ob die Verbesserungen effektiv sind oder nicht. Die Messungen wurden zwei Tage lang voom 6. bis zum 7. November durchgeführt. Dummerweise hatte das Tor-Netzwerk in dieser Zeit ein massives Problem: Ein abgelaufenes Zertifikat einer Verzeichnissauthorität hat hohe Last im Tor-Netz erzeugt, was viele Serbverbetreiber gezwungen hat, ihre Server abzuschalten. Eine zweite Messung wurde zwischen dem 13. und 15. November durchgeführt. Die Rohdaten sind hier zu bekommen (40 MB). Leider zeigen die Ergebnisse, dass die Gesamtperformanz des Tor-Netzwerks immer noch schlechter ist als im Juni 2008, als die erste Messung bezüglich versteckter Dienste durchgeführt wurde. Die zeigt sich vor allem bei Anfragen an Verzeichnissserver, die noch nicht von den Verbesserungen profitieren und die eine deutlich schlechtere Performanz als damals zeigen. Die Effekte der Verbesserungen sind sichtbar, aber absolute Zahlen sind noch nicht vergleichbar. Neue Messungen werden im Dezember durchgeführt, mit der Hoffnung, dass die Auswirkungen dieses Problems bis dahin verschwunden sind. Zusätzlich wurde noch ein möglicher Fehler in der Art, wie Tor Verzeichnissinformationen beim Starten bezieht, gefunden. Auch wenn dieser Fehler nicht direkt mit versteckten Diensten zusammenhängt, würde die Veröffentlichung von versteckten Diensten von einer Fehlerbehebung profitieren. Ein Teil der Aufgaben der nächsten 30 Tagen wir es sein diesen Fehler zu untersuchen.
Dez. 08	Ein Teil der letzten 30 Tagen wurde dafür genutzt, Fehler zu beheben, die die Messungen negativ beeinflusst haben. Die erste Fehlerbehebung behebt einen möglichen Speicherzugriffsfehler, der wahrscheinlich für eine Menge an fehlgeschlagenen Messreihen verantwortlich war. Ein anderer Fehler konnte erklärt werden, der zu massiven Verzögerungen beim Verbinden mit dem Tor-Netzwerk führte: Sehr langsame Verzeichnissauthoritäten haben startende Nutzer für lange Zeit beschäftigt, bis der Nutzer endlich aufgegeben hat und seine Daten von einer anderen Authorität bezogen hat. Ein Ergebniss war, dass die langsamsten 2 Verzeichnissauthoritäten ihren Rechnern mehr Bandbreite spendiert haben, so dass der Effekt abgemindert wurde. Ein dritter Fehler wurde mit den Performanzverbesserungen für versteckte Dienste im November eingeführt. Der Effekt war, dass Torprozesse, die versteckte Dienste angeboten haben, diese nicht mehr veröffentlichten, nachdem sie ihre Konfiguration neuluden. Ausserdem zeigte dieser Fehler, dass Tor seine Introduction Points neu aufbaute, wenn es neugeladen wurde. Dies könnte die Stabilität von versteckten Diensten beeinflusst haben. Der Fehler wurde behoben und wird in der folgenden Version 0.2.1.9-alpha enthalten sein. Neben der Fehlerbehebung wurden neue Messungen zwischen dem 8. und 10. Dezember durchgeführt. Dies werden wahrscheinlich die letzen Messungen sein, um die Performanz von versteckten Diensten jetzt mit dem Anfang des Projektes zu vergleichen. Die Daten wurden noch nicht komplett ausgewertet, daher ist es aktuell schwer eine Aussage über Verbesserungen zu machen. jedoch zeigt eine vorläufige Auswertung, dass die Veröffentlichungszeit eines versteckten Dienstes deutlich verbessert wurde. Dieser Erfolg kommt von der deutlich verbesserten Startzeit für Tornutzer und den Verbesserungen die im November eingebaut wurden. Im Gegensatz dazu sind die Ergebnisse der Verbindungsherstellung zu versteckten Diensten deutlich schlechter. Obwohl die Verbesserungen aus dem November einen positiven Effekt zu haben scheinen, zeigen einige interne Schritte eine deutlich schlechtere Performanz als vorher. Ein Beispiel dafür ist das Beziehen von Beschreibungsdateien versteckter Dienste um eine Verbindung mit diesen herstellen zu können. Eine mögliche Erklärung dafür ist dass der plötzliche Anstieg an Verzeichnissen für versteckte Dienste einen negativen Einfluss auf die Leistungsfähigkeit hatte. Ein Teil der Arbeit der letzten 31 Tage wird es sein, diese Daten genauer auszuwerten und finale Schlüsse über die erreichten Ziele dieses Projektes zu ziehen.
Jan. 09	Die Testphase ist zu Ende. Die Tests wurden in einer öffentlichen Betaphase mit den gesamten Änderungen im 0.2.1.x-alpha Zweig von Tor durchgeführt. Ein Ergebniss der öffentlichen Betaphase sind ein paar gefundene Fehler, die bereits behoben werden konnten. Ein weiterer Teil des Testens war eine zweite Messreihe, die im Dezember durchgeführt wurde. Ein Vergleich der durchgeführten Messungen im Juni und im Dezember hat uns gezeigt, dass die Veränderungen dieses Projektes effektiv sind. Die Veröffentlichungszeit für versteckte Dienste konnte von im Mittel 2:12 Minuten auf 58 Sekunden mehr als halbiert werden. Diese Verbesserung ist deutlich besser als erwartet. Mit dieser Verbesserung könnte es sogar interessant sein, über eine Reduzierung der Stabilisierungszeit von 30 Sekunden auf einen niedrigeren Wert nachzudenken. Leider ist die Zeit die es dauert, zwischen der Anforderung eines versteckten Dienstes und der Verbindungsherstellung zu diesem, bei etwa 56 Sekunden geblieben. Der Hauptgrund für die fehlende Verbesserung ist der Wechsel von einer zentralen, hin zu einer dezentralen Speicherung der Beschreibungsdateien von versteckten Diensten. Dieser negative Effekt durch die Verteilung des Verzeichnisses der versteckten Dienste wurde nicht vorhergesehen. In Zukunft sollte daher an der Beschleunigung des Herunterladens von Beschreibungsdateien aus dem verteilten Verzeichniss gearbeitet werden. Zum Beispiel durch die Parallelisierung dieser Anfragen. Dieser Report beendet die monatlichen Statusupdates. Die Verteilung der 0.2.1.x Versionen mit den Verbesserungen für versteckte Dienste wird in den nächsten Wochen und Monaten geschehen.

Das NLnet Projekt: Versteckte Dienste beschleunigen

Monatliche Statusberichte

Links