Benmchmarking 2
TeamViewer Motive 3

Verständnis - deep package inspection

lordg2009

Lt. Commander
Registriert
Apr. 2009
Beiträge
1.559
DPI ist nicht neu, aber ich beschäftige mich erst jetzt damit und im Internet finde ich keine seriöse Zusammenstellung. Der Wikipedia Artikel passt nicht recht zu vielen Artikeln und Diskussionen im Internet.

Auf wikipedia steht, dass bei dpi Header und eben auch Datenteil analysiert werden. Dienste, Protokollverletzungen, auch Inhalt wie SPAM und Viren können erkannt und reguliert werden. HTTPs strikt wäre jedoch eine Technik um dpi zu umgehen.

In verschiedenen Diskussionen wurde über dpi devices gesprochen. Diese seien in der Lage als men-in-the-middle zu fungieren und SSL geschützte Inhalte zu entschlüsseln. Da die dpi-devices eine akzeptierte CA nutzen, erstellen diese neue Zertifikate für erneute Verschlüsselung und der Nutzer bekommt keinen Hinweis für einen Zertifikat-Fehler.

Jetzt zu meinen konkreten Fragen:

Wird der Inhalt das Datenteils bei dpi sichtbar?
Kann eine HTTPs Verbindung analysiert werden?
Ist HTTPs strikt notwendig für einen wirksamen Schutz und ist dieses standartmäßig aktiviert?
Sicher kann ein dpi devices keine Zertifikat meines ursprünglichen Ziels signieren. Wenn ich mich zu meiner Bank verbinde, muss mein Browser doch erkennen, dass ich mit dem dpi-device kommuniziere und nicht mit der gewünschten Bank, oder?
Wäre ein SSL-VPN eine Möglichkeit, grundsätzlich dpi durch den Provider von jedem möglichen Traffic zu umgehen?

Vielen Dank für eure Antworten
 
lordg2009 schrieb:
Wird der Inhalt das Datenteils bei dpi sichtbar?

Bei DPI siehst du das komplette Datenpaket, alle Header und alle Daten (entweder verschlüsselt wie bei HTTPS oder unverschlüsselt wie bei HTTP).

lordg2009 schrieb:
Kann eine HTTPs Verbindung analysiert werden?

Ja, das ist möglich. Dafür nutzt man beispielsweise einen Proxyserver wie squid. Der Client wird dann so konfiguriert, dass er den Proxy für HTTPS Verkehr nutzt und installiert weiterhin das Zertifikat des Proxies.

Der Client baut dann eine HTTPS Verbindung zum Proxy auf, nennt das eigentliche Ziel, dann baut der Proxy eine eigene HTTPS Verbindung mit dem Server auf und leitet den Traffic zwischen Client und Server hin und her. Dabei arbeitet der Proxy auf dem unverschlüsselten Datenverkehr, da er für den Client als Server agiert und für den Server als Client.

lordg2009 schrieb:
Ist HTTPs strikt notwendig für einen wirksamen Schutz und ist dieses standartmäßig aktiviert?

Schutz gegen? Einen konfigurierten Proxy der extra als MitM agiert?
Ob HTTPS standardmäßig aktiviert ist, hängt von der jeweiligen Webseite ab.

lordg2009 schrieb:
Sicher kann ein dpi devices keine Zertifikat meines ursprünglichen Ziels signieren. Wenn ich mich zu meiner Bank verbinde, muss mein Browser doch erkennen, dass ich mit dem dpi-device kommuniziere und nicht mit der gewünschten Bank, oder?

Du kommunizierst bei einem Proxy (oder "DPI Device" wie du es nennst) aber nicht direkt mit dem Server der Bank sondern mit dem Proxy. Und da du vorher das Zertifikat für diesen Proxy manuell hinzugefügt haben musst, ist eine valide HTTPS Verbindung zu Stande gekommen.

lordg2009 schrieb:
Wäre ein SSL-VPN eine Möglichkeit, grundsätzlich dpi durch den Provider von jedem möglichen Traffic zu umgehen?

Wenn du ganz normales HTTPS ohne Proxy nutzt, kann der Provider selbst bei DPI außer den Informationen aus den Standardheadern wie IP/TCP keine Rückschlüsse auf den eigentlichen Traffic ziehen, da der TCP Payload ja TLS verschlüsselt ist.
 
TariusX schrieb:
Ja, das ist möglich. Dafür nutzt man beispielsweise einen Proxyserver wie squid. Der Client wird dann so konfiguriert, dass er den Proxy für HTTPS Verkehr nutzt und installiert weiterhin das Zertifikat des Proxies.

Der Client baut dann eine HTTPS Verbindung zum Proxy auf, nennt das eigentliche Ziel, dann baut der Proxy eine eigene HTTPS Verbindung mit dem Server auf und leitet den Traffic zwischen Client und Server hin und her. Dabei arbeitet der Proxy auf dem unverschlüsselten Datenverkehr, da er für den Client als Server agiert und für den Server als Client.

Vielen Dank für deine ausführliche Antwort.

Ich schließe daraus folgendes:

Wenn ich mich nicht bewusst entscheide, ein Zertifikat für einen Proxy eines dpi-device in meinem PC oder Browser zu installieren und einen Proxy zu konfigurieren, können ausgehende SSL-Verbinungen nicht entschlüsselt werden. Mein Eingreifen wäre zwingend erforderlich, wenn ich selbst Admin des Rechners bin.

Mit dpi kann der Provider unverschlüsselte Daten analysieren. Dpi-devices finden wahrscheinlich eher in Firmen Verwendung, wo Rechner nicht durch mich selbst konfiguriert werden, dem Provider helfen sie nicht weiter.
 
Wenn du das Zertifikat nicht installierst bekommst du eine Zertifikatswarnung bei jeder Webseite .. ohne den Proxy kommst du in so einem Setup üblicherweise gar nicht ins Internet :=)

Ich hab hier für mein Gastnetz eine SophosUTM (privat kostenlos) die genau das macht, aber transparent, d.h. im Browser ruft man z.B. google.de ohne eingestellten Proxy auf und die Sophos (default gateway in diesem Netz) leitet es automatisch durch den proxy.
 
Ich sage es mal so, die Gefahr, dass ein Provider durch DPI Daten aus HTTPS Traffic abgreift, stufe ich persönlich deutlichst geringer ein als sich mit einem Trojaner zu infizieren, der Daten wie Passwörter, Keyboard-Events, etc. direkt auf dem Endsystem abgreift.
Vor allem muss man im Kopf behalten, dass ein Provider nicht nur einen Kunden sondern hunderte/tausende hat. Da ist DPI nicht mal "eben so gemacht", um Credentials abzugreifen. Was ein Provider natürlich sehr einfach abgreifen und analysieren könnte: DNS Traffic, z.B. um ein einfaches Userprofil zu erstellen (Kunde XYZ ist auf irgendwelchen dubiosen Seiten unterwegs).

Die Frage ist, wovor möchtest du dich schützen? Dass der Provider Einblicke in dein Surfverhalten erhält oder dass der Provider an deine Banklogindaten gelangt?

Was man immer bedenken sollte: 100%ige Sicherheit gibt es nicht. Wenn es um deine Bankdaten geht, kann es genau so gut sein, dass die Bankinfrastruktur (z.B. der Loginserver) infiltriert wurde und die Logindaten dort abgeschöpft werden. Da bringt dir HTTPS auch nichts. Auch könnte das letzte/nächste Update deines Browsers modifiziert worden sein (je nachdem welche Verifikationsmechanismen der Browser durchführt), sodass der Browser von "Haus aus" ein solches Proxy-Zertifikat akzeptiert und die nötigen Einstellungen herstellt, um nur noch mit dem Proxy zu kommunizieren. Theoretisch ist alles möglich. Die Frage ist, wie verrückt will man sich machen.

Vielleicht gibt es von anderen Usern noch komplett andere Ansichten oder Einblicke.

Ein Setup mittels Proxy findet in der Tat häufiger in größeren Organisationen Verwendung, damit Malware nicht via HTTPS durch die Trafficanalyse schlüpft.
 
Wird der Inhalt das Datenteils bei dpi sichtbar?
Natürlich, der Datenteil ist immer sichtbar, schließlich muss ein Router und auch ein Switch das Paket ja 1:1 durchreichen und somit auch jedes einzelne Bit davon sehen können. Der Unterschied ist nur der, dass ohne DPI der Datenteil einfach nur stur durchgereicht wird, weil er für das Routing, NAT und Firewall irrelevant ist und so wird eben nur der Header ausgewertet, Quelle, Ziel, Port, etc..
Bei DPI wird dagegen auch der Datenteil ausgewertet, um zB in einer Firewall aufgrund der darin enthaltenen Informationen eine Verbindung zu blockieren obwohl die Header-Informationen die Verbindungen eigentlich zulassen würden.

Kann eine HTTPs Verbindung analysiert werden?
Bei https wird die Identität des Servers geprüft. D..h. der Browser prüft ob www.computerbase.de auch wirklich offiziell als www.computerbase.de bestätigt wird. Es ist nicht so ohne weiteres möglich, dies zu faken. Sonst würden wir im Zeitalter von Online Banking im totalen Chaos leben.
Hier wird erklärt wie https prinzipiell funktioniert bzw. wie eine MitM-Attacke ablaufen kann.

Ist HTTPs strikt notwendig für einen wirksamen Schutz und ist dieses standartmäßig aktiviert?
https ist keineswegs Pflicht. Ob der jeweilige Webserver daher neben unverschlüsseltem http auch einen verschlüsselten https Zugriff bietet, obliegt dem Betreiber des Webservers. Solange beispielsweise keine Logins, o.ä. übertragen werden, muss die Verbindung nicht zwangsläufig verschlüsselt werden.

Wenn ich mich zu meiner Bank verbinde, muss mein Browser doch erkennen, dass ich mit dem dpi-device kommuniziere und nicht mit der gewünschten Bank, oder?
Siehe hier (derselbe Artikel wie bei #2). Die Sicherstellung der Identität ist ja gerade der Knackpunkt. Sobald die Identität akzeptiert wurde - sei es nun durch eine korrekte Prüfung, einen Fake oder auch eine manuelle Ausnahme durch den Benutzer - werden Schlüssel ausgetauscht und eine verschlüsselte Übertragung gestartet, bei der niemand außer der Quelle und dem Ziel mitlesen kann. Hat man aber zB die Identität der Gegenstelle durch eine Ausnahme manuell besätigt, kann das eben auch der Mann im Mo.. äh.. in der Mitte sein. Blauäugige Nutzer können das System daher auch aushebeln.

Wäre ein SSL-VPN eine Möglichkeit, grundsätzlich dpi durch den Provider von jedem möglichen Traffic zu umgehen?
Ein VPN ist eine verschlüsselte Punkt-zu-Punkt-Verbindung. D.h. wenn du zB eine unverschlüsselte http Seite ansurfst, kann prinzipiell jeder mitlesen, da unverschlüsselt. Surfst du nun über eine VPN-Verbindung (zB Cyberghost), dann wird diese http-Verbindung in einem VPN-Tunnel gekapselt - von deinem PC aus bis zum VPN-Server. Der VPN-Server wiederum packt das VPN-Paket aus und leitet es auf herkömmlichem Wege weiter, also im Falle von http eben auch als unverschlüsseltes http.

PC <---VPN (http) VPN---> VPN-Server <---http--->Ziel

Dein Internet-Provider kann daher auch mit DPI nichts mit den Daten innerhalb eines VPNs anfangen, weil er via DPI eben einfach nur kryptische Zeichen sieht. Der VPN-Anbieter wiederum entschlüsselt die Daten ja wieder und kann sie demnach auch einsehen sofern die ursprünglichen Daten unverschlüsselt sind. Das gleiche gilt für den Internet-Provider des VPN-Anbieters und alle Zwischenstationen bis zum endgültigen Ziel.
Aus diesem Grund ist Surfen via VPN nicht per Definition sicher, da sich das (Vertrauens-)Problem prinzipiell nur vom Internet-Anbieter zum VPN-Anbieter verlagert.
 
  • Gefällt mir
Reaktionen: paulinus und azereus
Raijin schrieb:
Aus diesem Grund ist Surfen via VPN nicht per Definition sicher, da sich das (Vertrauens-)Problem prinzipiell nur vom Internet-Anbieter zum VPN-Anbieter verlagert.
Sehr richtig und da ist die Frage: vertraue ich eher meinem ISP oder einem VPN-Anbieter. Persönlich würde ich da wohl eher zu meinem ISP tendieren.
 
Definitiv.

Prinzipiell muss man bei DPI auch bedenken, dass es sehr ressourcenintensiv ist. Zum Vergleich:

Ohne DPI muss eine Firewall nur ~20 Byte pro Paket anschauen, Quelle, Ziel, Protokoll, etc.
Mit DPI muss eine Firewall unter Umständen alle ~1500 Byte pro Paket anschauen, inkl. Nutzlast (Daten)

Es ist daher beliebig unwahrscheinlich, dass jemand (zB der Internet-Provider) auf Verdacht per DPI alle Kunden überwacht. Man kann sich das so vorstellen als wenn die DHL nicht einfach nur auf den Adressaufkleber guckt, um das Paket in den richtigen Wagen zu packen, sondern jedes Paket öffnet, den Inhalt durchstöbert, um dann im Detail zu entscheiden, ob das Paket mit diesem Inhalt nicht doch an eine andere Adresse geschickt werden sollte :freak:

*edit
Während normales Routing, etc. in der Regel in Hardware passiert, also nahezu ohne Verzögerung, wird DPI von der CPU selbst übernommen, weil sie den Inhalt des Pakets individuell beurteilen muss.
 
Hi,

prinzipiell habe ich nichts zu verbergen, will es aber grundsätzlich. Vor allem interessiert mich was es für Möglichkeiten gibt, meinen Datenverkehr abzuhören. Mir ging es in dem Thread spezifisch um dpi durch den ISP und nicht um anonymes Surfen im Netz. Auch ich würde keinem dubiosen VPN Dienst Vertrauen und nutze auch nur mein eigenes VPN von außen, bzw. das VPN meines Arbeitgebers. Ich habe bei meiner Recherche den Eindruck gewonnen, der ISP könnte unter Umständen meinen TLS verschlüsselten Datenteil entschlüsseln, ohne, dass ich es mitbekomme. Das ist offenbar nicht so.

Danke für eure Antworten :)
 
Auch wenn der Begriff "Man-in-the-Middle" suggeriert, dass jemand irgendwo auf dem Weg gewissermaßen mit einem Ohr den Datenverkehr abhören kann, beschreibt MitM etwas ganz anderes. Bei solch einer Attacke muss sich der Angreifer zunächst aktiv als Ziel einschleusen. Das kann zB durch einen Link auf einer Seite oder auch in einer Phishing-eMail sein oder zB auch durch einen falschen DNS Eintrag (zB in die hosts-Datei eingeschmuggelt). Der Internet-Provider könnte das zB durch einen falschen Eintrag in seinem eigenen DNS erreichen und somit auf einen eigenen Server verweisen anstatt auf die offizielle IP der Bank zum Beispiel.

Ist das Opfer dann erstmal auf den gefaketen Server geleitet, beginnt die eigentliche MitM Attacke, weil der Fake-Server dann seinerseits eine Verbindnug zum ursprünglichen Ziel aufbaut und so als Vermittler in der Mitte agiert und die Daten vom Opfer zum eigentlichen Ziel bzw. die Antwort entsprechend manipuliert.

Das heißt im Klartext: Der Provider müsste aktiv in die Verbindung eingreifen. Rein durch "Mitlesen" funktioniert das nicht, da sonst nur verschlüsseltes Zeugs sichtbar wäre. Man muss wohl nicht erwähnen wie illegal das wäre.....
 
Raijin schrieb:
Auch wenn der Begriff "Man-in-the-Middle" suggeriert, dass jemand irgendwo auf dem Weg gewissermaßen mit einem Ohr den Datenverkehr abhören kann, beschreibt MitM etwas ganz anderes. Bei solch einer Attacke muss sich der Angreifer zunächst aktiv als Ziel einschleusen. Das kann zB durch einen Link auf einer Seite oder auch in einer Phishing-eMail sein oder zB auch durch einen falschen DNS Eintrag (zB in die hosts-Datei eingeschmuggelt). Der Internet-Provider könnte das zB durch einen falschen Eintrag in seinem eigenen DNS erreichen und somit auf einen eigenen Server verweisen anstatt auf die offizielle IP der Bank zum Beispiel.

Ist das Opfer dann erstmal auf den gefaketen Server geleitet, beginnt die eigentliche MitM Attacke, weil der Fake-Server dann seinerseits eine Verbindnug zum ursprünglichen Ziel aufbaut und so als Vermittler in der Mitte agiert und die Daten vom Opfer zum eigentlichen Ziel bzw. die Antwort entsprechend manipuliert.

Das heißt im Klartext: Der Provider müsste aktiv in die Verbindung eingreifen. Rein durch "Mitlesen" funktioniert das nicht, da sonst nur verschlüsseltes Zeugs sichtbar wäre. Man muss wohl nicht erwähnen wie illegal das wäre.....

Auch wenn dieser Angriff durch den ISP nur theoretischer Natur ist, würde er doch trotzdem durch die Zertifikate verhindert werden, oder. Auch wenn der ISP meinen Traffic umleitet, kann es sich doch nicht als Inhaber der domain meiner Bank ausweisen.
 
Nicht so ohne weiteres. Im verlinkten Artikel wird beschrieben wie so ein Angriffsvektor aussehen kann. Im einfachsten Falle meckert der Browser über ein falsches Zertifikat und der unbedarfte Nutzer versteht gar nicht was der Browser da überhaupt von ihm will und klickt blauäugig auf "Zertifikat akzeptieren", o.ä.

Wie dem auch sei, solche Angriffe sind stets zielgerichtet. So könnte ein Angreifer beispielsweise versuchen, das Online Banking der Commerzbank zu faken. Wenn das vermeintliche Opfer jedoch bei der Deutschen Bank ist, funktioniert der Angriff schon nicht mehr.
 
Raijin schrieb:
Prinzipiell muss man bei DPI auch bedenken, dass es sehr ressourcenintensiv ist.

Es ist daher beliebig unwahrscheinlich, dass ...
Du überschätzt den Aufwand. Schon ohne Spezialhardware, also mit PC-Technik, bekommt man Analysen bis in den GBit-Bereich hin. Natürlich kommt es immer darauf an, welche Details man genau inspizieren möchte. Das Argument "unwahrscheinlich weil zu viel Aufwand" kann man jedenfalls für sämtliche praxisrelevanten Analysewünsche komplett beerdigen.

Selbst bei extrem hohen Datenraten ist die Analyse technisch kein so großes Ding. Der Datenverkehr wird mitgeschnitten, zeitlich oder grob inhaltlich aufgesplittet und die Detailanalyse dann parallel auf mehreren, billigen Rechnern durchgeführt. Nur für den 1. Teil ist Spezialhardware nötig. Das Ergebnis steht damit wenige Sekunden später zur Verfügung als bei einer Live-Analyse.
 
Ich meinte damit auch eher die groß angelegte Analyse aller Kunden beim Provider. Da reden wir ja nicht von 1 Gbit/s sondern .. .. ein wenig mehr. Und das ganze auf blauen Dunst hin und zudem ohne jedwede rechtliche Handhabe.

Es mag unglücklich formuliert geweseb sein, aber mir ging es primär darum, dass es so oder so mit Aufwand verbunden ist und der Provider keinen erkennbaren Nutzen davon hat. Von den potentiellen rechtlichen Konsequenzen ganz zu schweigen.

Wobei man auch da differenzieren muss. Ich meine mich zu erinnern, dass der rosa Riese mal in der Kritik stand, dass sie aktiv Streaming gedrosselt haben - ungeachtet der Plattform. Ob da evtl DPI im Spiel war weiß ich nicht, möglich wäre es.
 
Zuletzt bearbeitet:
Zurück
Oben