The Second-Generation Onion Router - Revision history

Eric: /* Exit Policies */

2007-08-11T13:18:46Z

Exit Policies

← Older revision		Revision as of 13:18, 11 August 2007
Line 135:		Line 135:
	=== Exit Policies ===		=== Exit Policies ===
	Jeder Onion Router beschreibt in seiner Exit Policy zu welcher externen Adresse und welchen Ports sich der Router verbindet. Dabei unterschiedet man zwischen den folgenden Arten.		Jeder Onion Router beschreibt in seiner Exit Policy zu welcher externen Adresse und welchen Ports sich der Router verbindet. Dabei unterschiedet man zwischen den folgenden Arten.
	Zum einen die Open Exit Nodes, die überall hin verbinden. Zum anderen die Middleman Nodes, die nur zu anderen TOR-Knoten verbinden. Desweiteren gibt es private Exit Nodes, die nur zu lokalen Rechnern oder dem lokalen Netzwerk verbinden. Die vierte Variante sind Restricted Exit Nodes, die am Häufigsten vorkommen. Sie ermöglichen die ~~Verbidnung~~ nach außen, verhindern aber den Zugang zu gewissen, missbrauchsanfälligen Adressen und Diensten wie zum Beispiel SMTP. Diese Variante eignet sich sehr gut für den Administrator, weil er wählen kann welche Ports freigeschaltet ~~sind~~ und welche nicht. Fraglich ist jetzt, in welchem Verhältnis die verschiedenen Möglichkeiten angewandt werden sollten. Viele Middleman Nodes erstellen ein großes, robustes Netzwerk, aber wenn man nur wenig Exit Nodes hat, erleichtert man Angreifern auch die Überwachung des Datenverkehrs. Eine Mischung aus Open und Restricted Nodes erlaubt die größte Flexibilität für den Administrator.		Zum einen die Open Exit Nodes, die überall hin verbinden. Zum anderen die Middleman Nodes, die nur zu anderen TOR-Knoten verbinden. Desweiteren gibt es private Exit Nodes, die nur zu lokalen Rechnern oder dem lokalen Netzwerk verbinden. Die vierte Variante sind Restricted Exit Nodes, die am Häufigsten vorkommen. Sie ermöglichen die Verbindung nach außen, verhindern aber den Zugang zu gewissen, missbrauchsanfälligen Adressen und Diensten wie zum Beispiel SMTP. Diese Variante eignet sich sehr gut für den Administrator, weil er wählen kann welche Ports freigeschaltet werden und welche nicht. Fraglich ist jetzt, in welchem Verhältnis die verschiedenen Möglichkeiten angewandt werden sollten. Viele Middleman Nodes erstellen ein großes, robustes Netzwerk, aber wenn man nur wenig Exit Nodes hat, erleichtert man Angreifern auch die Überwachung des Datenverkehrs. Eine Mischung aus Open und Restricted Nodes erlaubt die größte Flexibilität für den Administrator.

	=== Directory Servers ===		=== Directory Servers ===

Eric: /* Threat-Modell */

2007-08-11T13:15:08Z

Threat-Modell

← Older revision		Revision as of 13:15, 11 August 2007
Line 25:		Line 25:

	=== Threat-Modell ===		=== Threat-Modell ===
	Für ein anonymes Netzwerk haben Bedrohungen meistens die Form einer passiven globalen Analyse des Netzwerkverkehrs. Gegen Angriffe solcher Stärke hat TOR jedoch kaum Chancen und nimmt daher an, dass Angriffe er in der Art erfolgen, dass Teile des Netzwerkverkehrs überwacht, dieser erzeugt, verändert, gelöscht oder verzögert werden kann, oder dass Onion Router übernommen und nach belieben gesteuert werden können.		Für ein anonymes Netzwerk haben Bedrohungen meistens die Form einer passiven globalen Analyse des Netzwerkverkehrs. Gegen Angriffe solcher Stärke hat TOR jedoch kaum Chancen und nimmt daher an, dass Angriffe eher in der Art erfolgen, dass Teile des Netzwerkverkehrs überwacht, dieser erzeugt, verändert, gelöscht oder verzögert werden kann, oder dass Onion Router übernommen und nach belieben gesteuert werden können.
	Nun kann der Angreifer entweder passiv agieren und den Verkehr an beiden Enden der Verbindung abhören und sie durch Timing und Volumen der Pakete miteinander verbinden.		Nun kann der Angreifer entweder passiv agieren und den Verkehr an beiden Enden der Verbindung abhören und sie durch Timing und Volumen der Pakete miteinander verbinden.
	Wenn er aktiv agiert, kann der Angreifer versuchen die Schlüssel zu cracken oder Timing Signaturen einfügen um Unterschiede zwischen den Paketen noch deutlicher sichtbar zu machen.		Wenn er aktiv agiert, kann der Angreifer versuchen die Schlüssel zu cracken oder Timing Signaturen einfügen um Unterschiede zwischen den Paketen noch deutlicher sichtbar zu machen.

Hormozdi: /* Directory Servers */

2007-08-07T11:02:22Z

Directory Servers

← Older revision		Revision as of 11:02, 7 August 2007
Line 138:		Line 138:

	=== Directory Servers ===		=== Directory Servers ===
			Directory Server sind ein zentraler Bestandteil des TOR-Netzwerkes. Es gibt nur wenige gut ausgewählte Onion Router, die als Directory Server (DS) genutzt werden.
			Sie verfolgen alle Änderungen in der Netz-Topologie und im Status von Knoten und bieten für alle Knoten und Proxies einen einfachen Look-up-Dienst an.
			Jeder Onion Router schickt periodisch signierte Statusinformationen an einen oder mehrere DS. Diese Informationen umfassen Exit-Policies, Schlüssel als auch Information über die Nachbarschaft des Onion Routers.

			Jeder neue Onion Router muss von Hand von einem DS-Admin für diesen Vorgang zugelassen werden. Die Automatisierung dieser Zulassung unter Berücksichtigung der Sicherheit des Netzwerkes ist ein aktives Forschungsgebiet.

			DS bilden aus allen vorhandenen Informationen einen signierten Descriptor. Dieser Descriptor stellt das Verzeichniss dar. Die Directory Server gleichen ihre Descriptoren untereinander ab und legen durch einen Mehrheitsentscheid fest wie der IST-Zustand des Netzwerkes aussieht.

	== Angriffe und Angriffsabwehr ==		== Angriffe und Angriffsabwehr ==

Hormozdi: /* Rendezvous Points und Hidden Services */

2007-08-07T10:52:55Z

Rendezvous Points und Hidden Services

← Older revision		Revision as of 10:52, 7 August 2007
Line 123:		Line 123:
	Auf Stream-Ebene funktioniert die Datenfluss-Kontrolle prinzipiell genauso, jedoch auf End-to-End basis. Zusätzlich muss geprüft werden ob die Daten des TCP-Streams an den Endpunkten auch geflusht werden. Deshalb wird ein Relay-Sendme nur dann geschickt wenn nicht zuviele Bytes gerade auf einen Flush warten.		Auf Stream-Ebene funktioniert die Datenfluss-Kontrolle prinzipiell genauso, jedoch auf End-to-End basis. Zusätzlich muss geprüft werden ob die Daten des TCP-Streams an den Endpunkten auch geflusht werden. Deshalb wird ein Relay-Sendme nur dann geschickt wenn nicht zuviele Bytes gerade auf einen Flush warten.

	=== Rendezvous Points und Hidden Services ===		=== Rendezvous Points und Hidden Services ===
	[[Image:hidden_service_tor.png\|right\|~~500px~~\|thumb\|Versteckter Dienst durch TOR]]		[[Image:hidden_service_tor.png\|right\|450px\|thumb\|Versteckter Dienst durch TOR]]
	Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können.		Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können.
	Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.		Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.

Hormozdi: /* Rendezvous Points und Hidden Services */

2007-08-07T10:52:08Z

Rendezvous Points und Hidden Services

← Older revision		Revision as of 10:52, 7 August 2007
Line 124:		Line 124:

	=== Rendezvous Points und Hidden Services ===		=== Rendezvous Points und Hidden Services ===
⚫	Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können.
	[[Image:hidden_service_tor.png\|right\|500px\|thumb\|Versteckter Dienst durch TOR]]		[[Image:hidden_service_tor.png\|right\|500px\|thumb\|Versteckter Dienst durch TOR]]
		⚫	Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können.
	Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.		Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.

Hormozdi: /* Rendezvous Points und Hidden Services */

2007-08-07T10:51:34Z

Rendezvous Points und Hidden Services

← Older revision		Revision as of 10:51, 7 August 2007
Line 124:		Line 124:

	=== Rendezvous Points und Hidden Services ===		=== Rendezvous Points und Hidden Services ===
			Ziel der versteckten Dienste ist die Möglichkeit anonym Dienste bereitstellen- und nutzen zu können.
	TODO
			[[Image:hidden_service_tor.png\|right\|500px\|thumb\|Versteckter Dienst durch TOR]]
			Bobs Dienst wird durch einen Hash identifiziert und zusammen mit einer Liste von Introduction Points (IP) in einem Directory Server gespeichert. Bob signiert diese Dienstbeschreibung damit niemand einen Dienst als Bob's Dienst anbieten kann. Bob unterhält Verbindungen zu all den Introduction Point's die er angegeben hat.

			Wenn Alice nun den Dienst von Bob nutzen möchte schaut sie im Directory Server nach, welche Introduction Point sie nutzen kann. Sie verbindet sich zu einem dieser Introduction Points und hinterlässt ein rendezvous-cookie sowie die Information welchen OR sie als Rendezvous Point (Treffpunkt) ausgesucht hat.
			Anschließend verbindet sich Alice mit dem Rendezvous Point und wartet dort auf Bob.

			Falls Bob die Anfrage von Alice beantworten möchte verbindet er sich mit dem Rendezvous Point und kann Alice anhand dem Rendezvous-Cookie erkennen. Der Rendezvous-Point leitet nun Dtaen zwischen Alice und Bob weiter.

	=== Exit Policies ===		=== Exit Policies ===

Hormozdi: /* Datenfluss-Kontrolle (Congestion Controll) */

2007-08-07T10:33:44Z

Datenfluss-Kontrolle (Congestion Controll)

← Older revision		Revision as of 10:33, 7 August 2007
Line 120:		Line 120:

	Durch diesen Mechanismus werden Engpässe und Datenstau vermieden. Das Tor-Design sieht eine relativ Konservative Bemessung zugunsten der Betreiber von OR vor. D.h. Es wird der Schutz der OR-Betreiber vor die Performance des Netzwerkes gestellt.		Durch diesen Mechanismus werden Engpässe und Datenstau vermieden. Das Tor-Design sieht eine relativ Konservative Bemessung zugunsten der Betreiber von OR vor. D.h. Es wird der Schutz der OR-Betreiber vor die Performance des Netzwerkes gestellt.

			Auf Stream-Ebene funktioniert die Datenfluss-Kontrolle prinzipiell genauso, jedoch auf End-to-End basis. Zusätzlich muss geprüft werden ob die Daten des TCP-Streams an den Endpunkten auch geflusht werden. Deshalb wird ein Relay-Sendme nur dann geschickt wenn nicht zuviele Bytes gerade auf einen Flush warten.

	=== Rendezvous Points und Hidden Services ===		=== Rendezvous Points und Hidden Services ===

Hormozdi: /* Datenfluss-Kontrolle (Congestion Controll) */

2007-08-07T10:30:24Z

Datenfluss-Kontrolle (Congestion Controll)

← Older revision		Revision as of 10:30, 7 August 2007
Line 109:		Line 109:

	====Datenfluss-Kontrolle (Congestion Controll)====		====Datenfluss-Kontrolle (Congestion Controll)====
			Drosselung findet sowohl auf Verbindungstunnel-Ebene, als auch au Stream-Ebene statt. Jeder OR überwacht zwei Fenster nach denen sich entscheidet welche Aktivität der OR überhaupt ausübt.

			'''packaging window''': wieviele Relay-Data-Cells darf der OR packen (tcp-traffic von ausserhalb des TOR-Netzwerkes)

			'''delivery window''': wieviele Relay-Data-Cells darf der OR ausd TOR-Netzwerk nach Aussen weiterleiten

			Diese Fenster werden zu Beginn mit einem Startwert (z.B 1000) initialisiert und bei jedem Packet der zuugehörige Wert dekrementiert. Sobald ein Wert bei Null angelangt ist stellt der OR die über das Fenster definierte Tätigkeit ein, bis sich der Wert wieder ändert.

			Durch Relay-Sendme Zellen können die Fenster wieder aufgestockt werden. Ein OR schickt z.B ein Relay-Send-Me wenn er bereit ist weitere Daten von einem anderen OR anzunehmen.

			Durch diesen Mechanismus werden Engpässe und Datenstau vermieden. Das Tor-Design sieht eine relativ Konservative Bemessung zugunsten der Betreiber von OR vor. D.h. Es wird der Schutz der OR-Betreiber vor die Performance des Netzwerkes gestellt.

	=== Rendezvous Points und Hidden Services ===		=== Rendezvous Points und Hidden Services ===

Hormozdi: /* Weiterleiten von Zellen */

2007-08-07T09:57:00Z

Weiterleiten von Zellen

@@ Line 75: / Line 75: @@
 ====Weiterleiten von Zellen====
 [[Image:encrypted_cells.png|thumb|500px|Verschlüsselungsschichten einer Zelle|right]]
 ====Öffnen von Streams====

Hormozdi: /* Aufbau eines Verbindungstunnels */

2007-08-07T09:56:24Z

Aufbau eines Verbindungstunnels

@@ Line 62: / Line 62: @@
 ====Aufbau eines Verbindungstunnels====
-OP baut Verbindungstunnel schrittweise auf durch aushandeln eines symmetrischen Schlüssels (Session-Key) mit jedem OR des Verbindungstunnels. (diffie-hellman-handshake)
+#OP baut Verbindungstunnel schrittweise auf durch aushandeln eines symmetrischen Schlüssels (Session-Key) mit jedem OR des Verbindungstunnels. (diffie-hellman-handshake)
-create cell (von Alice) enthält die erste hälfte des Diffie-Hellman-Handshakes g^x1 verschlüsselt mit dem onion key (public key) von OR1
+#created cell (von OR1) enthält g^y1 und den Hash von K=g^x1y1
 ====Weiterleiten von Zellen====