Hidden Services brauchen etwas Liebe

Hidden Services befinden sich in einer besonderen Situation. Während sie eine treue Fangemeinde haben, gibt es keine engagierten Tor-Entwickler, die sich um sie kümmern. Dies führt zu einem großen Haufen an Funktionen, die erforscht, implementiert und eingesetzt werden müssen, um die versteckten Dienste sicherer und effektiver zu machen.

Der Zweck dieses Blogposts ist dreifach:

Den Betreibern von Hidden Services verschiedene Unzulänglichkeiten der Hidden-Service-Architektur vor Augen zu führen.
Forschern werden verschiedene Forschungsfragen zu Hidden Services vorgestellt.
Entwicklern soll die Fülle an Programmieraufgaben vorgestellt werden, die im Ökosystem der Hidden Services noch zu erledigen sind.
Beachten Sie, dass sich nicht jede Idee, die in diesem Blogbeitrag aufgeführt ist, als großartige Idee erweisen wird. Dieser Beitrag ist eher ein Brain-Dump als eine solide, vollständig analysierte Agenda.

In jedem Fall sollten wir uns den Themen zuwenden:

Skalierung Hidden Service

Die derzeitige Architektur der versteckten Dienste ist nicht gut skalierbar. Idealerweise sollten große Webseiten die Möglichkeit haben, komplett zu Tor Hidden Services zu migrieren, aber das ist mit der derzeitigen Architektur nicht möglich.

Eines der Hauptprobleme eines gut ausgelasteten versteckten Dienstes ist, dass die Einführungspunkte von Kunden überrannt werden. Da Einführungspunkte reguläre Tor-Relays sind, sind sie nicht dafür gedacht, eine solche Last zu bewältigen.

Daher ist einer der ersten Schritte, um die Skalierbarkeit der versteckten Dienste zu verbessern, die Erhöhung der Lebensdauer der Einführungspunkte. Momentan wählt ein versteckter Dienst die Anzahl seiner Einführungspunkte (zwischen einem und zehn) basierend auf einer Selbsteinschätzung seiner eigenen Popularität. Ob die derzeit verwendete Formel die beste ist, ist eine offene Forschungsfrage.

Ein weiteres Problem der versteckten Dienste ist das Fehlen von Lastausgleichsoptionen. Während man einen Hidden Service mit Hilfe von TCP/HTTP-Loadbalancern (wie HAProxy) ausbalancieren kann, gibt es keine Load-Balancing-Option, die dem DNS-Round-Robin ähnelt, bei dem die Lastverteilung durch das Senden von Clients an verschiedene Server-IP-Adressen erfolgt. Eine solche Lastverteilung könnte dadurch erreicht werden, dass ein versteckter Dienst mehrere “Unterdienste” haben kann. Eine solche Architektur ist zwar verlockend, wirft aber zahlreiche Probleme auf, z. B. die Kommunikation zwischen den Unterdiensten, die Frage, wo das langfristige Schlüsselpaar gespeichert wird, die Zuweisung der Einführungspunkte, usw.

Verteidigung gegen Denial of Service von Einführungspunkten

Die gegnerische Version des vorigen Abschnitts beinhaltet, dass Angreifer absichtlich die Einführungspunkte eines versteckten Dienstes angreifen, um ihn für ehrliche Clients unerreichbar zu machen. Das bedeutet, dass ein Angreifer einen versteckten Dienst vorübergehend lahmlegen kann, indem er eine kleine Anzahl von Tor-Servern angreift.

Um sich gegen solche Angriffe zu verteidigen, haben Syverson und Øverlier Valet-Knoten in ihrem PETS 2006 Paper vorgestellt: “Valet Services: Improving Hidden Servers with a Personal Touch”. Valet-Knoten stehen vor den Einführungspunkten und fungieren als Schutzschicht. Dies ermöglicht es Hidden Services, eine begrenzte Anzahl von Introduction Points, aber viel mehr Kontaktpunkte zu unterhalten, ohne dass die Kunden die tatsächlichen Adressen der Introduction Points erfahren.

Valet-Knoten sind noch nicht implementiert, hauptsächlich wegen des großen Implementierungs- und Bereitstellungsaufwands, den sie erfordern.

Das langfristige Schlüsselpaar eines Versteckten Dienstes ist ein RSA-1024-Schlüsselpaar, das heutzutage als schwach gilt. Das bedeutet, dass Hidden Services in Zukunft auf eine andere Schlüssellänge und/oder einen asymmetrischen kryptographischen Algorithmus umsteigen müssen.

Ein Nebeneffekt einer solchen Migration ist, dass Hidden Services eine andere Onion-Adresse erhalten, was für Hidden Services, die eine gut etablierte Onion-Adresse haben, problematisch sein kann. Um den Übergang reibungsloser zu gestalten, sollten Hidden Services eine Zeit lang sowohl alte als auch neue Schlüsselpaare verwenden können, um ihre Kunden auf die neue Adresse verweisen zu können.

Unglücklicherweise gibt es noch keine Vorschläge zur Verbesserung der Kryptographie der versteckten Dienste, obwohl die Arbeit an der Stärkung einiger Teile der Kryptographie von Tor begonnen hat.

Angriffe durch die Verzeichnisserver der versteckten Dienste

Hidden Services laden ihren Deskriptor auf Tor-Knoten hoch, die Hidden Service Directory Servers (HSDirs) genannt werden. Klienten holen dann diesen Deskriptor ab und benutzen ihn, um sich mit dem versteckten Dienst zu verbinden.

Im aktuellen System sind HSDirs in einer interessanten Position, die es ihnen erlaubt, die folgenden Aktionen durchzuführen

Erlernen der .onion-Adresse eines versteckten Dienstes und Herstellen einer Verbindung zu ihm die Popularität eines versteckten Dienstes zu bewerten, indem sie die Anzahl der Kunden verfolgen, die eine Suche nach diesem versteckten Dienst durchführen sich weigern, einem Client zu antworten, und wenn genügend HSDirs dies tun, ist der Hidden Service vorübergehend unerreichbar
Diese Szenarien werden im kommenden IEEE S&P Paper mit dem Titel “Trawling for Tor Hidden Services” erforscht: Detection, Measurement, Deanonymization” von Alex Biryukov, Ivan Pustogarov und Ralf-Philipp Weinmann. Sieh es dir auf jeden Fall an (sobald sie es veröffentlichen)!

Schauen wir uns einige vorgeschlagene Lösungen für die Angriffe an, die von Hidden Service Directory Servern durchgeführt werden können:

Verteidigungsmaßnahmen gegen die Aufzählung von Onionadressen

Hidden Services verwenden einen Hash-Ring, um auszuwählen, welche HSDirs ihre Deskriptoren beherbergen werden; das bedeutet, dass HSDirs einfach darauf warten können, von den versteckten Diensten ausgewählt zu werden, und dann ihre Deskriptoren und Onionadressen sammeln. Da der Hash-Ring rotiert, erhalten die HSDirs in jeder Rotationsperiode neue Deskriptoren der Hidden Services.

Eine mögliche Lösung für dieses Problem wäre, einen symmetrischen Schlüssel an die Onion-Adresse anzuhängen und diesen zur Verschlüsselung des Deskriptors zu verwenden, bevor er an HSDirs gesendet wird (ähnlich wie die Authentifizierung mit Deskriptor-Cookies derzeit funktioniert). Ein Client, der die Onion-Adresse kennt, kann den Deskriptor entschlüsseln, aber ein HSDir, der die Onion-Adresse nicht kennt, kann den Namen des Hidden Service nicht ableiten. Der Nachteil dieses Schemas ist, dass die Größe der Onion-Adressen zunehmen wird, ohne dass die Sicherheit ihrer Selbstauthentifizierungseigenschaft erhöht wird. Außerdem ist HSDirs immer noch in der Lage, den öffentlichen Schlüssel des Versteckten Dienstes aus dem Deskriptor zu extrahieren, was es HSDirs ermöglicht, die Deskriptoren bestimmter Hidden Service zu verfolgen.

Eine andere Lösung wurde von Robert Ransom vorgeschlagen:

Roberts Schema verwendet das langfristige Schlüsselpaar eines versteckten Dienstes, um (in einer Einbahnstraße) ein zweites Schlüsselpaar abzuleiten, das zum Verschlüsseln und Signieren des Deskriptors verwendet wird, der zu den HSDirs hochgeladen wird. Durch diese Konstruktion kann der HSDir, ohne das langfristige Schlüsselpaar des verborgenen Dienstes oder den Inhalt des Deskriptors zu kennen, überprüfen, ob derjenige, der den Deskriptor hochgeladen hat, im Besitz des langfristigen privaten Schlüssels des verborgenen Dienstes ist. Ein Client, der den öffentlichen Langzeitschlüssel des Versteckten Dienstes kennt, kann den Deskriptor aus dem HSDir holen und überprüfen, ob er vom Versteckten Dienst selbst erstellt wurde. Siehe das entsprechende Trac-Ticket für eine genauere Analyse der Idee.

Roberts Idee vergrößert die Größe von Onion-Adressen, macht sie aber auch widerstandsfähiger gegen Imitationsangriffe (die derzeitige 80-Bit-Sicherheit von Onion-Adressen ist nicht sehr vertrauenserweckend gegen Impresonationsangriffe). Außerdem erlaubt seine Idee HSDirs nicht, die Deskriptoren der versteckten Dienste über die Zeit zu verfolgen.

Obwohl Roberts Schema ziemlich einfach ist, ist eine ordentliche Sicherheitsevaluierung angebracht und es muss ein Tor-Vorschlag geschrieben werden. Für zusätzlichen Spaß erfordert seine Idee, dass das langfristige Schlüsselpaar des versteckten Dienstes ein diskretes Log-Kryptosystem verwendet, was bedeutet, dass eine Schlüsselpaar-Migration notwendig ist, wenn wir mit diesem Plan fortfahren wollen.

Blockieren der Verfolgung der Popularität von Versteckten Diensten

HSDirs kann die Anzahl der Benutzer verfolgen, die nach einem versteckten Dienst suchen, und so herausfinden, wie beliebt er ist. Wir können es HSDirs erschweren, die Popularität eines Versteckten Dienstes zu verfolgen, indem wir ein PIR-Protokoll (Private Information Retrieval) für den Abruf von Deskriptoren für Hidden Services verwenden. Natürlich wird dies die Einführungspunkte eines versteckten Dienstes nicht davon abhalten, das Tracking durchzuführen, aber da die Einführungspunkte vom versteckten Dienst selbst ausgewählt wurden, ist die Gefahr geringer.

Wenn wir die Einführungspunkte daran hindern wollten, die Popularität der versteckten Dienste zu verfolgen, könnten wir versuchen, die Identität des versteckten Dienstes vor seinen Einführungspunkten zu verbergen, indem wir ein Cookie-Schema verwenden, ähnlich wie es derzeit beim Rendezvous der Fall ist, oder indem wir Roberts Trick zur Ableitung von Schlüsselpaaren anwenden und die Einführungseinrichtung mit dem neuen Schlüsselpaar signieren. Eine sorgfältige Sicherheitsbewertung dieser Ideen ist erforderlich.

Erschweren Sie es, ein gegnerischer HSDir zu werden

Wegen der Sicherheitsimplikationen, die HSDirs für Hidden Services haben, haben wir angefangen, daran zu arbeiten, dass es für einen Tor-Server schwieriger wird, ein HSDir-Knoten zu werden.

Außerdem kann ein Angreifer die Identitätsschlüssel vorhersagen, die er in der Zukunft benötigt, um einen bestimmten versteckten Dienst anzugreifen. Wir haben überlegt, wie wir diesen Angriff verhindern können.

Verbesserung der Leistung
Hidden Services sind slooooowwww und wir verstehen nicht einmal, warum. Sie sind vielleicht deshalb so langsam, weil das Einrichten einer Hidden Service-Schaltung so teuer ist, oder weil Hidden Service-Schaltungen 6 Hops haben, oder aus einem anderen Grund. Es wurden viele Vorschläge gemacht, um die Latenzzeit von Hidden Services zu verringern. Sie reichen von Hacks für das Hidden Service-Protokoll über Javascript-Hacks bis hin zu einer radikalen Änderung der Art und Weise, wie die Hidden Service-Schaltung aufgebaut wird.

Lassen Sie uns einige dieser Vorschläge untersuchen:

Verringerung der Komplexität des Aufbaus eines Hidden Service-Kreislaufs

Während der PETS 2007 präsentierten Syverson und Øverlier “Improving Efficiency and Simplicity of Tor circuit establishment and hidden services” (Verbesserung der Effizienz und Einfachheit des Aufbaus von Tor-Schaltungen und versteckten Diensten).

Sie stellten fest, dass durch die Verwendung von Valet-Knoten das Konzept der Rendezvous-Punkte überflüssig ist und dass ein Versteckter Dienst-Schaltkreis nur durch die Verwendung von Valet-Knoten und Einführungspunkten gebildet werden kann. Karsten Loesing schrieb einen Tor-Vorschlag für eine Variante dieser Idee.

Der Grund, warum dieses Schema nicht implementiert wird, ist, dass die damit verbundenen Sicherheitskompromisse nicht gut verstanden werden, und es gibt auch einige technische Hindernisse (wie die Tatsache, dass die gemeinsame Nutzung von Schaltungen durch mehrere Clients derzeit nicht unterstützt wird).

Analysiere das Timing des Verbindungsaufbaus von versteckten Diensten mit Torperf

Um eine Verbindung zu einem versteckten Dienst aufzubauen, braucht man derzeit zwei Tor-Relais, den Einführungs- und den Rendezvouspunkt, und 10 weitere Relais, die sich auf vier Schaltkreise verteilen, um sich mit ihnen zu verbinden. Niemand hat wirklich erforscht, wie viel Zeit Tor in jedem Schritt dieses komplizierten Prozesses verbringt. Es wäre nicht überraschend, wenn ein großer Teil der Zeit in einem unerwarteten Teil des Prozesses verbracht wird.

Um dies richtig zu untersuchen, sollte man Torperf benutzen, um das Zeitdelta zwischen den Schritten des Prozesses zu analysieren. Leider verwendet Torperf Controller-Ereignisse, um zwischen den Phasen des Tor-Protokolls zu unterscheiden, aber nicht alle Schritte des Hidden Service Schaltkreises haben Controller-Ereignisse zugewiesen. Um dies zu implementieren, muss man die Kontrollport-Trigger zur Tor-Codebasis hinzufügen, Torperf laufen lassen und dann die Ergebnisse sammeln und auswerten.

Hidden Services sollten alte Einführungspunkte wiederverwenden

Momentan hören Hidden Services auf, Verbindungen zu alten Einführungspunkten aufzubauen, nachdem sie unterbrochen wurden. Obwohl dieses Verhalten sinnvoll ist, bedeutet es, dass Klienten, die alte Deskriptoren für Hidden Services haben, sich immer wieder an den falschen Einführungspunkten anmelden. Dies ist besonders schmerzhaft in Roaming-Situationen, in denen Benutzer häufig das Netz wechseln (und bestehende Verbindungen verlieren).

Eine Lösung für dieses Problem wäre, dass die versteckten Dienste ausgefallene Verbindungen zu alten Einführungspunkten wiederherstellen (wenn die Verbindungen aufgrund von Netzwerkausfällen zerstört wurden). Wir sollten die Sicherheitsfolgen eines solchen Vorgehens untersuchen und auch die genaue Zeitspanne, in der Einführungspunkte als “alt” gelten, aber immer noch “es wert sind, Schaltungen zu ihnen wiederherzustellen”.

Verschlüsselte Dienste sind die korrekte Form der Implementierung der inzwischen abgeschafften Exit Enclaves.

Mit verschlüsselten Diensten können Sie einen nicht anonymen versteckten Dienst ausführen, bei dem die serverseitige Rendezvous-Verbindung nur einen Hop beträgt. Dies ist in Szenarien sinnvoll, in denen der versteckte Dienst sich nicht um seine Anonymität kümmert, aber dennoch seinen Klienten erlauben will, anonym auf ihn zuzugreifen (und mit all den anderen Funktionen, die selbst-authentifizierende Namen bieten). Siehe Rogers ursprünglichen Vorschlag für weitere Anwendungsfälle und Informationen.

Zu diesem Thema schlug Robert Ransom vor, Encrypted Services als ein von Tor getrenntes Programm zu implementieren, da es ein ganz anderes Bedrohungsmodell bedient. Außerdem würden die Nutzer auf diese Weise das Tor-Netzwerk nicht überlasten und es würde auch eine größere Vielseitigkeit und eine einfachere Bereitstellung ermöglichen.

Menschliche einprägsame Onionadressen

Das Zooko-Dreieck charakterisiert Onionadressen als sicher und global, aber nicht als speicherbar. Inzwischen wurden einige Systeme vorgeschlagen, um Adressen von versteckten Diensten einprägsam zu machen, aber aus verschiedenen Gründen war keines davon besonders erfolgreich.

Dies waren nur einige der Dinge, die im Bereich der Versteckten Dienste getan werden müssen. Wenn du daran interessiert bist, uns zu helfen, lies bitte die Links und Trac-Tickets, und melde dich mit Vorschlägen, Patches und Anregungen. Benutze die [tor-dev] Mailingliste oder unsere IRC-Kanäle für entwicklungsbezogene Kommunikation.

Bitte beachte, dass dieser Blogpost nur Themen behandelt hat, die die Codebasis von Tor oder das Hidden Service Protokoll und seine Kryptographie betreffen. Wenn wir jedoch wollen, dass die versteckten Dienste wirklich erfolgreich und einflussreich sind, ist es auch wichtig, ein lebendiges Ökosystem um sie herum aufzubauen. Wir brauchen zum Beispiel datenschutzfreundliche Archivierungssysteme und Suchmaschinen (und Technologien und Regeln, wie sie funktionieren sollten), wir brauchen einfach zu bedienende Veröffentlichungsplattformen, Internetdienst-Dämonen und Protokolle, die für Verbindungen mit hoher Latenz optimiert sind, anonymen Dateiaustausch, Chatsysteme und soziale Netzwerke.