Time Stamp Attacken

[chinamaschiene]

guten abend,

ich habe gelesen das man auf proxyserver die einen anonym machen sehr leicht timestamp attacken machen kann die die anonymität in gefahr bringen. wo kann ich allgemeine informationen dazu finden wie das funktioniert? in google finde ich da keine richtigen seiten, wenn ich den begriff eingebe. nur irgentwelche komischen seiten die uralt sind oder speziell von irgentnen lücke in einer software reden. vieleicht hat das ja auch noch einen anderen namen den ihr kennt.

viele grüße

 

[luky37]

Sowas ist mir nicht bekannt und ich bezweifle dass das funktioniert.


Das einzige, was mir konkret einfällt ist, dass du mit ein paar Timestamp Werte aus dem HTTP Header einen vermuteten transparenten Proxy in deinem Netzwerk erkennen kannst (siehe http://www.lagado.com/tools/cache-test).


Das hat aber weniger mit deinem Anliegen zu tun.


Vielleicht kannst du uns mal deine Quelle nennen.

 

[chinamaschiene]

danke für die antwort. das mit dem transparenten proxy kann ich mir gut vorstellen. die quelle ist wohl auch nicht gerade seriös was technische dinge angeht:

Er [nen anonymer proxy] ist sehr anfällig vor Timestamp-Attacken, bei denen die Zeit der Ankunft und des Verlassens eines Datenpaketes zum Proxy und/oder dessen Größe bzw. Inhalt verglichen und so die Anonymität zerstört wird.

 

[luky37]

OK, jetzt verstehe ich wie das gemeint ist.


Es ist gemeint dass die eingehenden und ausgehenden Verkehrsdaten verglichen werden und daraus Rückschlüsse auf den User gemacht werden können.


Das kann allerdings nur das Datacenter des Proxy Servers tun, niemand sonst, und es fast unmöglich, wenn auf dem Proxy sehr viel Traffic fließt.


Mann muss schon eine sehr große Paranoia haben, um deswegen Proxies als unsicher zu bezeichnen.

Außerdem betrifft das auch VPNs und jeglichen Traffic, der genattet wird.

 

[chinamaschiene]

du scheinst dich ja acht gut auszukennen mit netzwerken. das man vor dem proxy nicht anonym ist ist doch sowieso klar. ich mein der kann ja auch bei nat einfach loggen das IP A nach IP B eine anfrage macht. die datenmengen werden natürlich enorm groß. ist es das was gemeint ist?

 

[luky37]

Nein.


Nehmen wir an, unser Client (Node A), verbindet sich mit einem Proxy Server (Node B).


Node A will auf Node C (z.B: ein Webserver) zugreifen, allerdings anonym über Node B (dem Proxy Server).


Dazu hat der Proxy Server noch eine Verbindung laufen, vom Node D (ein anderer Client) zu Node E (ein anderer Server).



Nehmen wir weiters an, dass Node B (unser Proxy Server) die Verbindungen nicht loggt.




In diesem Fall kann der ISP von Node B (dem Proxy Server), die ausgehenden und eingehenden Verbindungen analysieren.


Der ISP sieht folgende Verbindungen:

Node A zu Node B
Node D zu Node B
Node B zu Node C
Node B zu Node E

Der ISP kann aber nicht wissen, dass Node A auf Node C und Node D auf Node E zugreifen will bzw. zugreift, da er die NAT Tabelle (oder die Proxy Logs) von Node B nicht zur Verfügung hat.

Soweit die Theorie.



Jetzt kommt dieser theoretische Angriff:



Der ISP sieht einen 2 Mbit Traffic Flow von Node B upstream zu Node C und einen 2 Mbit downstream Flow von Node B zu Node A.


Dazu einen 1 Mbit downstream von Node B zu Node E und 1 Mbit upstream von Node B zu Node D.



Durch die Analyse des Traffics kann der Provider mit ziemlicher Sicherheit davon ausgehen, dass Node A mit Node C und Node D mit Node E kommunizieren (immer über einen Proxy Server oder NAT Gateway der nicht loggt).


Somit wurde durch die Analyse des Traffic der ursprüngliche Host ausgemacht. Im Beispiel habe ich es anhand des Traffic veranschaulicht, dasselbe lässt sich aber auch die Größe der Packete sowie Timestamps machen.


Das ganze ist allerdings sehr aufwendig und setzt voraus, dass der Angreifer komplette Einsicht in den ein und ausgehenden Traffic des Proxies/NAT Gateways hat.



Das Modell der Trafficanalyse lässt sich auch bei verschlüsselten VPNs anwenden, allerdings ist es nahezu unmöglich, falls der Proxy viele Verbindungen hat.

Das Modell von Timestamps und Packetgrößen lässt sich allerdings nur auf unverschlüsselten Proxy Server anwenden.


Wichtig ist: dabei handelt es sich um theoretische Konzepte, um die man sich in der Praxis meist keine Sorgen machen muss (oder anders gesagt: if you dont know what it means, you won't need it ).



Ich hoffe ich habe es halbwegs verständlich erklärt, trotzdem wirst du dir das mehrmals durchlesen müssen, um das Ganze nachvollziehen zu können.

 

[chinamaschiene]

Absolut geniales Posting und perfekt erklaert! Vielen Dank!

Ich finde das thema an sich extrem spannend nur manchmal schwierig nach informationen zu suchen. es hat wirklich sehr viel spass gemacht das zu lesen. du hast uebrigens recht: ich musste dein posting wirklich 2-3 mal lesen aber jetzt ist mir ein kleines licht aufgegangen. dennoch ist mir die sache mit der zusaetzlichen sicherherheit durch verschluesselung noch nicht klar.

Das Modell von Timestamps und Packetgrößen lässt sich allerdings nur auf unverschlüsselten Proxy Server anwenden.

Also timestamps befinden sich ja nicht in den paketen selbst und koennen ja von den ISP NICs (router, gateways was auch immer) trotzdem aufgezeichnet und analysiert werden. genauso die paketgroesse oder?

Klar haben die verschluesselten datenpakete A<--->B eine andere groesse als die normalerweise unverschluesselten B<--->C pakete, aber das sollte sich ja theoretisch umrechnen lassen. Und eth, ip und tcp-schicht sind bei ssl/tls ja auch nicht verschluesselt (geht ja auch schlecht *g*). der isp sieht also genau wie von dir gepostet auch noch die ein- und ausgehenden verbindungen von/zu B. also auch hier keine zusaetzliche sicherheit.

ich erkenne momentan also nicht wie eine verschluesselung die zuordnung verhindern soll. nur die daten der anwendungsschicht sind natuerlich wertlos aber darum geht es ja nicht.


Ich freue mich auf eine evtl. Antwort.

PS.

Wichtig ist: dabei handelt es sich um theoretische Konzepte, um die man sich in der Praxis meist keine Sorgen machen muss

finde das thema nur faszinierend, ich arbeite ja nicht fuer alqaida oder die NSA. zumindest nicht mit meinem wissen (und wenns doch so waere frage ich mich ob ich das hier posten wuerde)

(oder anders gesagt: if you dont know what it means, you won't need it ).

warum erinnert mich das nur an make menuconfig

 

[luky37]

ich erkenne momentan also nicht wie eine verschluesselung die zuordnung verhindern soll.

Du hast recht, bei einer HTTPS Verbindung ist das so.

Wenn man allerdings eine VPN hat (wie OpenVPN), sieht der ISP nur eine einzelne UDP Session (z.B., kann natürlich auch GRE, TCP oder ESP sein), in der dein ganzer Traffic eingekapselt ist (dadurch variiert die Größe und auch der Timestamp).

warum erinnert mich das nur an make menuconfig

 

[chinamaschiene]

Wenn man allerdings eine VPN hat (wie OpenVPN), sieht der ISP nur eine einzelne UDP Session

hmm.... ISP A sieht eine verbindung klar. Aber ISP B (B ist jetzt der vpn server statt nen webproxy) sieht doch immer noch alles. oder?

habe mich jetzt ein wenig in vpn eingelesen. von welcher art vpn waere das dann?

http://www.teco.edu/~zimmer/vpn/node12.html#SECTION00030000000000000
http://de.wikipedia.org/wiki/Virtual_Private_Network

etwas genauer:

also A1 will mit den webserver C1a, C1b, C1c usw. reden und A2 mit den Webservern C2a, C2b und C2c reden.

Die user A1, und A2 sind per VPN mit B verbunden. B verbindet sich normal (http) zu den webservern C1a, C1b, C2a, C2b usw und leitet den traffic an A1 bzw. A2 weiter.
ISP A1 und ISP A2 sehen natuerlich nur eine einzelne Verbindung zu B.(genau wie bei nen normalen webproxy) Aber ISP B sieht doch weiterhin alle Verbindungen...

wie genau aendert vpn jetzt dieses problem im vgl. zu nen normalen proxy?

leider kann ich mir nicht vorstellen was das vpn bringen soll...

 

[luky37]

ISP B sieht auch nur eine Verbindung zu A1 und eine Verbindung zu A2, da der VPN Traffic ja verschlüsselt ist.


Natürlich sieht der ISP B immernoch die Verbindungen zwischen B und Cxx, aber er kann sie keinem A mehr zuordnen.

 

[chinamaschiene]

ok da hab ich wohl irgendwie mein hirn zu arg verdreht. Nochmals vielen dank fuer die Muehe und die interesanten Postings.