Autoren:  (1) Vinod S. Khandkar und Manjesh K. Hanawal, Wirtschaftsingenieurwesen und Operations Research, Indian Institute of Technology Bombay, Mumbai, Indien und {vinod.khandkar, mhanawal}@iitb.ac.in.  Linktabelle   Zusammenfassung & Einleitung   Verwandte Arbeiten und Hintergrund   Herausforderungen bei der Entwicklung von Messaufbauten zur TD-Erkennung   Fallstudie: Wehe – TD-Erkennungstool für mobile Umgebungen   Wehe-Mangel beim HTTPS-Verkehr   TD-Erkennung von HTTPS-Verkehr   Fazit & Referenzen  V. MANGEL VON WEHE BEIM HTTPS-VERKEHR  Unsere Studie konzentriert sich auf die Validierung der Netzwerkantworten für die wiedergegebenen Verkehrsströme, die TD-Erkennung und die betriebliche Durchführbarkeit in verschiedenen Netzwerkkonfigurationen. Während die betriebliche Durchführbarkeit mithilfe der öffentlich verfügbaren Android-App „Wehe“ im Google Playstore validiert wird, werden TD-Erkennungsszenarien mithilfe theoretischer Argumente validiert. Die Validierung der Netzwerkantworten erfordert eine Bandbreitenanalyse des empfangenen Verkehrsstroms. Diese Analyse erfordert die Netzwerkprotokolle für die spezifische Wiedergabe, die gemäß dem Validierungsszenario durchgeführt wird. Die auf dem Gerät durchgeführte Wiedergabe und mehrere andere Streaming-   Abb. 6. Verkehrsklassifizierung des wiedergegebenen YouTube-Verkehrs  Parallel laufende Dienste sind ein solches Szenario. Die Wehe-App stellt solche Netzwerkprotokolle für die Wiederholungen nach Abschluss der Tests nicht sofort bereit. Daher haben wir den Benutzer-Client und den Server implementiert, die das Verhalten des Wehe-Tools nachahmen.  Zur Validierung von Wehe verwenden wir ein Client-Server-Setup ähnlich dem in Abb. 3 gezeigten Setup. Im aktuellen Setup haben wir den Server des ursprünglichen Dienstes durch einen Replay-Server ersetzt. Der Userclient und der Replay-Server sind über einen kommerziellen Traffic Shaper verbunden. Darüber hinaus verfügt unser Setup über eine Möglichkeit, mehrere Replays parallel auszuführen. Unser Validierungs-Setup benötigt keine administrativen Kanäle und Overheads, z. B. Nebenkanäle. Unser Server muss immer einen Einzelbenutzer-Client unterstützen. Die Validierung von Szenarien mit mehreren Clients verwendet die Wehe-App direkt, da keine zugehörige Verkehrsanalyse erforderlich ist.  In diesem Abschnitt werden die Ergebnisse der Validierung beschrieben.   A. Verkehrsemulation des ursprünglichen Dienstes  Die Netzwerkantworten hängen von der Anwendung von Netzwerkrichtlinien ab, die auf der korrekten Klassifizierung des Datenverkehrs durch Netzwerk-Middle-Boxen basieren, wie in Abschnitt III-A erwähnt. Wir haben die Klassifizierung des emulierten Datenverkehrs von Wehe mithilfe eines kommerziellen Traffic Shapers validiert. Die Klassifizierung des emulierten Datenverkehrs wird mithilfe der Benutzeroberfläche des kommerziellen Traffic Shapers beobachtet.  Zur Durchführung des Experiments werden die YouTube-Anwendungsdaten über einen kommerziellen Traffic Shaper vom Wiedergabeserver an den Benutzer-Client wiedergegeben. Während der Datenübertragung wird das Benutzeroberflächenfenster des kommerziellen Traffic Shapers auf das Vorhandensein von YouTube-Verkehr überwacht. Wir haben auch über einen Internetbrowser auf den YouTube-Verkehr zugegriffen und das Klassifizierungsergebnis des Traffic Shapers beobachtet, um unsere Beobachtungen zur Verkehrsklassifizierung als Grundlage zu nehmen.  Abb. 6 zeigt das Ergebnis der Verkehrsklassifizierung, wie es im Benutzeroberflächenfenster des kommerziellen Traffic Shapers für Verkehr angezeigt wird, der direkt über einen Internetbrowser von einem YouTube-Server abgerufen wird. Es zeigt die Internetaktivität im linken Fenster und die Klassifizierung des entsprechenden Verkehrs im rechten Fenster.  Abb. 6(a) zeigt, dass der über einen Internetbrowser abgerufene Datenverkehr korrekt als YouTube klassifiziert wird. Dies entspricht dem beabsichtigten Verhalten kommerzieller Traffic Shaper.  Abb. 6(b) zeigt das Ergebnis der Verkehrsklassifizierung für den über den Benutzer-Client abgerufenen Verkehr. Es zeigt, dass kein YouTube-Verkehr über die Kommunikationsverbindung übertragen wurde. Darüber hinaus klassifiziert es denselben Verkehr als HTTPS-Verkehr. Das Ergebnis dieses Experiments zeigt, dass nicht alle Netzwerk-Middleboxes den von Wehe wiedergegebenen Verkehr korrekt klassifizieren können.   B. Auswirkung der Datenrate im Wiedergabeskript  Die Generierung des Prüfverkehrs beeinflusst die Netzwerkantwort wie vom TD-Erkennungsalgorithmus erwartet. Wir verwenden die Verkehrsverfolgung des ursprünglichen Dienstes zum Generieren von Replay-Skripten, die die Anwendungsdaten und ihre zeitliche Beziehung bewahren. Dieses Replay-Skript wird über das ursprüngliche Netzwerk und auch über Netzwerke verwendet, die sich an unterschiedlichen Standorten befinden. Da die Traffic-Shaping-Rate für denselben Dienst zwischen den Netzwerken variiert (wie in [32] erwähnt), kann die im Replay-Skript gespeicherte Verkehrsrate von der Traffic-Shaping-Rate des aktuell betrachteten Netzwerks abweichen. Die Replay-Verkehrsrate kann niedriger sein als die Traffic-Shaping-Rate.  Die Wehe-Methode erkennt keine Verkehrsdifferenzierung, wenn die Verkehrsrate des Replay-Skripts niedriger ist als die Shaping-Rate des Netzwerks, da sie den Verkehrsstrom nicht beeinflusst. Solche Replay-Skripts können Verkehrsshaping in solchen Netzwerken niemals erkennen. Daher ist die TD-Erkennungsfunktion des Wehe-Tools durch die Prüfverkehrsrate des Replay-Skripts begrenzt.   C. Verwendung der Portnummer 80  Die Netzwerkantworten werden von der Wahrnehmung des Netzwerk-Middle-Boxes hinsichtlich des Sondierungsverkehrs gesteuert (siehe Abschnitt III-A). Das Replay-Skript bewahrt die Daten im ursprünglichen Netzwerk-Trace der Anwendungen. Die ursprünglichen Anwendungsserver verwenden Port 80 für die Klartextdaten und Port 443 für die verschlüsselte Datenübertragung. Das Wehe-Replay-Skript verwendet die verschlüsselten Daten direkt aus dem Netzwerk-Trace der Anwendung und überträgt sie über Port 80. In solchen Fällen erwartet Wehe, dass sein ursprünglicher Replay-Verkehrsstrom von Netzwerkgeräten, die verschlüsselte Anwendungsdaten verwenden, richtig klassifiziert wird. Für solche Daten ist Port 80 nicht möglich, da verschlüsselte Verkehrsdaten ihre Identifikation dem Netzwerkgerät nicht preisgeben können. Daher kann das Wehe-Tool die erforderlichen Verkehrsströme für Dienste, die auf Port 443 laufen, nicht generieren, da Port 80 standardmäßig für Replay-Läufe verwendet wird.   D. Durch die Verkehrslast bestimmtes Netzwerkverhalten  Beachten Sie, dass Ressourcenknappheit Netzwerke dazu veranlasst, bestimmte Netzwerkverkehrsmanagements anzuwenden, insbesondere in Szenarien mit hoher Netzwerklast, die für alle aktiven Dienste im Netzwerk von Vorteil sind, z. B. QoS-basiertes Verkehrsmanagement (siehe Abschnitt III-A). Wir haben die Wirkung eines solchen Verkehrsmanagements validiert   Abb. 7. Auswirkung der Netzwerklast auf die Verkehrsstromleistung von Wehe  auf der Leistung sowohl der Kontroll- als auch der Originalwiederholungen. Die Validierung verwendet die folgenden drei Szenarien für die Validierung,  • Wiedergabe nur der beiden Datenströme von Wehe ohne Belastung des Netzwerks (Abb. 7(a))  • Wiedergabe der drei Datenströme von Wehe mit einem zusätzlichen parallel laufenden Streaming-Dienst (Abb. 7(b))  • Wiedergabe der drei Datenströme von Wehe mit zwei zusätzlichen parallel laufenden Streaming-Diensten (Abb. 7(c))  Die Leistungen in Abb. 7(a) zeigen, dass die Leistungen der vom Wehe-Tool generierten Verkehrsströme ohne zusätzliche Netzwerklastbedingungen gleich sind. Mit zunehmender Netzwerklast weicht die Leistung der Kontrollwiedergabe von der der Originalwiedergabe und auf höherem Niveau ab (Abb. 7(b)). Während die Leistung der Kontrollwiedergabe weiter von der Originalwiedergabe auf der niedrigeren Seite abweicht, zeigen zwei Originalwiedergaben immer noch ähnliche Leistungen, wie in Abb. 7(c) gezeigt. Dies widerlegt die Erwartung des Wehe-Tools, dass die Kontrollwiedergabe nicht differenziert wird. Es widerlegt auch die Behauptung des Tools, den TD aufgrund der Gesamtbandbreite zu erkennen.   E. Wir testen von mehreren Geräten im selben Subnetz  Die Nebenkanäle werden im Wehe-Design eingeführt, um mehrere Benutzerclients gleichzeitig zu unterstützen. Nebenkanäle helfen auch dabei, die Zuordnung zwischen Benutzerclient und einer Kombination aus IP-Adressen und Ports zu identifizieren. Dies ist bei Netzwerken mit NATs nützlich [33]. Wir haben Wehes Unterstützung für mehrere Clients und NAT-fähige Netzwerke anhand von zwei verschiedenen Tests überprüft. Zunächst haben wir zwei Benutzerclients aus demselben Subnetz verbunden, d. h. Clients mit derselben öffentlichen IP-Adresse. In einem Test testet das Wehe-Tool denselben Dienst auf beiden Geräten, z. B. testet die Wehe-App auf beiden Geräten YouTube. Das Ergebnis zeigt, dass der Wehe-Test nur auf einem Gerät abgeschlossen wurde, während die Wehe-App auf einem anderen Gerät abrupt geschlossen wurde. Wir haben dasselbe Szenario wiederholt, aber dieses Mal testet Wehe unterschiedliche Dienste, z. B. testet Wehe auf einem Gerät YouTube, während es auf einem anderen Netflix testet. Wir haben festgestellt, dass der Wehe-Test auf einem Gerät ordnungsgemäß abgeschlossen wird, während der Wehe-Test auf einem anderen Gerät eine Fehlermeldung auf dem Bildschirm ausgibt, die den Benutzer darüber informiert, dass ein anderer Client den Test bereits durchführt (siehe Abb. 9). Diese Tests zeigen, dass Wehe mehrere Geräte nicht unterstützt, wenn sie dieselbe IP-Adresse teilen. Während ein Nebenkanal nützlich ist, um jede Wiedergabe von einem Benutzer-Client zu identifizieren, der direkt mit dem Wehe-Wiedergabeserver verbunden ist, ist er in einem Netzwerk mit NAT-Geräten nicht nützlich. Bei NAT teilen sich mehrere Benutzer dieselbe IP-Adresse. In solchen Fällen kann der Nebenkanal nicht jede ausgeführte Wiedergabe eindeutig einem Client zuordnen. Er begrenzt die Verwendung von Wehe auf nur einen aktiven Client pro Wiedergabeserver, ISP und Anwendung. Diese Einschränkung wird auch von den Wehe-Entwicklern dokumentiert.   F. Auswirkung der Gerätenetzwerklast auf die TD-Erkennung  Der Wiedergabeserver von Wehe verwendet dieselben Zeitabläufe zwischen der Übertragung von Anwendungsdaten wie für den ursprünglichen Anwendungsverkehr. Bei einer solchen Übertragungsstrategie wird die verfügbare Bandbreite voraussichtlich nicht erschöpft. Daher ist der Effekt der Quellratenmodulation aufgrund eines Überschreitens der Verkehrsrate über die verfügbare Bandbreite unwahrscheinlich. Dies führt dazu, dass Original- und Kontrollwiederholungen ähnliche Verkehrsleistungen aufweisen, sofern sie nicht absichtlich durch Netzwerkrichtlinien, d. h. TD, geändert werden.  Diese Erwartung wird jedoch nicht immer erfüllt, da die Datenverkehrsrate bei der Durchführung von Wehe-Tests durch die Netzwerklast am Benutzergerät moduliert wird. Solche Störungen erzeugen Diskrepanzen, da die Wirkung der zeitabhängigen aktuellen Netzwerklast auf den Testverkehr ebenfalls zeitabhängig ist und nicht immer gleich sein muss. Die Back-to-Back-Replay-Strategie von Wehe stellt sicher, dass beide Testverkehrsströme (Original- und Kontroll-Replay) unterschiedlich von der aktuellen Netzwerklast beeinflusst werden. Bei einer solchen Netzwerklast auf der Geräteseite ist die Vorstellung, dass Dienste die verfügbare Bandbreite nicht ausschöpfen, nicht mehr gegeben, und ihre Vorteile für die TD-Erkennung sind hinfällig. Vor der TD-Erkennung müssen solche Störfaktoren normalisiert werden (siehe Abschnitt III-B).  Dieses Dokument ist   . auf Arxiv unter der CC 4.0-Lizenz verfügbar

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

NetNeutrality

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Boost your HackerNoon story @ $159.99! 🚀

Die Mängel von Wehe bei der Erkennung von HTTPS-Verkehr verstehen

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Management Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Management Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps