Comprendre les lacunes de Wehe sur la détection du trafic HTTPS

Tableau des liens

Résumé et introduction

Travail et contexte connexes

Défis liés au développement de configurations de mesure de détection TD

Étude de cas : Wehe - Outil de détection TD pour environnement mobile

Lacune de Wehe sur le trafic HTTPS

Détection TD du trafic HTTPS

Conclusion et références

V. DÉFAUT DE WEHE SUR LE TRAFIC HTTPS

Notre étude se concentre sur la validation des réponses du réseau pour les flux de trafic rejoués, la détection TD et la faisabilité opérationnelle dans diverses configurations réseau. Alors que la faisabilité opérationnelle est validée à l'aide de l'application Android « Wehe » accessible au public sur Google Playstore, les scénarios de détection TD sont validés à l'aide d'arguments théoriques. La validation des réponses du réseau nécessite une analyse de la bande passante du flux de trafic reçu. Cette analyse nécessite les journaux réseau pour la relecture spécifique effectuée selon le scénario de validation. Le replay effectué sur l'appareil et plusieurs autres streamings

Fig. 6. Classification du trafic du trafic YouTube relu

les services exécutés en parallèle sont l’un de ces scénarios. L'application Wehe ne fournit pas immédiatement de tels journaux réseau pour les rediffusions après la fin des tests. Nous avons donc implémenté l'utilisateur-client et le serveur qui imite le comportement de l'outil Wehe.

Nous utilisons une configuration client-serveur similaire à la configuration présentée sur la figure 3 pour valider Wehe. Dans la configuration actuelle, nous avons remplacé le serveur du service d'origine par un serveur de relecture. Le client utilisateur et le serveur de relecture sont connectés via un façonneur de trafic commercial. De plus, notre configuration permet d'effectuer plusieurs replays en parallèle. Notre configuration de validation ne nécessite pas de canaux administratifs ni de frais généraux, par exemple des canaux secondaires. Notre serveur doit toujours prendre en charge un client mono-utilisateur. La validation de scénarios avec plusieurs clients utilise directement l'application Wehe en raison de la non-exigence d'une analyse de trafic associée.

Rappel de cette section décrit les résultats de la validation.

A. Émulation du trafic du service d'origine

Les réponses du réseau dépendent de l'application de politiques de réseau basées sur une classification correcte du trafic par boîtiers de médiation du réseau, comme mentionné dans la Section III-A. Nous avons validé la classification du trafic émulé de Wehe à l'aide d'un modeleur de trafic commercial. La classification du trafic émulé est observée à l'aide de l'interface utilisateur du modeleur de trafic commercial.

Pour réaliser l'expérience, les données de l'application YouTube sont relues du serveur de relecture au client utilisateur via un façonneur de trafic commercial. Pendant le transfert de données, la fenêtre de l'interface utilisateur du gestionnaire de trafic commercial est observée pour détecter la présence de trafic YouTube. Nous avons également accédé au trafic YouTube à l'aide d'un navigateur Internet et observé les résultats de la classification du traffic shaper pour baser nos observations sur la classification du trafic.

La figure 6 montre le résultat de la classification du trafic tel qu'illustré par la fenêtre d'interface utilisateur d'un façonneur de trafic commercial pour le trafic accessible directement à l'aide d'un navigateur Internet à partir d'un serveur YouTube. Il montre l'activité Internet dans la fenêtre de gauche et la classification du trafic correspondant dans la fenêtre de droite.

La figure 6(a) montre que le trafic consulté à l'aide d'un navigateur Internet est correctement classé comme YouTube. Ceci est conforme au comportement prévu du régulateur de trafic commercial.

La figure 6(b) montre le résultat de la classification du trafic pour le trafic accessible à l'aide d'un client utilisateur. Il montre la preuve qu’aucun trafic YouTube n’est transféré via le lien de communication. De plus, il classe le même trafic que le trafic HTTPS. Le résultat de cette expérience montre que tous les boîtiers de médiation du réseau ne peuvent pas classer correctement le trafic relu de Wehe.

B. Effet du débit de données dans le script de relecture

La génération de trafic de sondage a un impact sur la réponse du réseau comme prévu par l'algorithme de détection TD. Wehe utilise la trace du trafic du service d'origine pour générer des scripts de relecture qui préservent les données de l'application et leur relation temporelle. Ce script de replay est utilisé sur le réseau d'origine ainsi que sur des réseaux différemment géolocalisés. Comme le taux de mise en forme du trafic varie à travers les réseaux pour le même service (comme mentionné dans [32]), le taux de trafic conservé dans le script de relecture peut être différent du taux de mise en forme du trafic du réseau actuellement considéré. Le taux de trafic de relecture peut être inférieur au taux de mise en forme du trafic.

La méthodologie Wehe ne détecte pas la différenciation du trafic si le débit de trafic du script de relecture est inférieur au débit de mise en forme du réseau, car cela n'affecte pas le flux de trafic. De tels scripts de relecture ne peuvent jamais détecter la formation de trafic sur de tels réseaux. Ainsi, la capacité de détection TD de l'outil Wehe est limitée par le taux de trafic de sondage du script de relecture.

C. Utilisation du numéro de port 80

Les réponses du réseau sont déterminées par la perception des boîtiers de médiation du réseau concernant le trafic de sondage (voir la section III-A). Le script de relecture préserve les données dans la trace réseau d'origine des applications. Les serveurs d'applications d'origine utilisent le port 80 pour les données en texte brut et le port 443 pour le transfert de données cryptées. Le script de relecture Wehe utilise directement les données cryptées de la trace réseau de l'application et les transmet sur le port 80. Dans de tels cas, Wehe s'attend à ce que son flux de trafic de relecture d'origine soit classé correctement par les périphériques réseau utilisant les données d'application cryptées. Il est impossible de transférer de telles données sur le port 80, car les données de trafic cryptées ne peuvent pas révéler leur identification au périphérique réseau. Ainsi, l'outil Wehe ne peut pas générer les flux de trafic requis pour les services exécutés sur le numéro de port 443 en raison de l'utilisation par défaut du port 80 pour l'exécution de la relecture.

D. Comportement du réseau régi par la charge de trafic

Notez que la rareté des ressources incite les réseaux à appliquer une certaine gestion du trafic réseau, en particulier dans les scénarios de charge réseau importante, qui sont bénéfiques pour tous les services actifs sur son réseau, par exemple, la gestion du trafic basée sur la QoS (voir Sec. III-A). Nous avons validé l'effet d'une telle gestion du trafic

Fig. 7. Effet de la charge du réseau sur les performances du flux de trafic de Wehe

sur les performances des rediffusions de contrôle et originales. La validation utilise les trois scénarios suivants pour la validation,

• Rejouer uniquement les deux flux de trafic de Wehe sans aucune charge sur le réseau (Fig 7 (a))

• Relecture des trois flux de trafic de Wehe avec un service de streaming supplémentaire fonctionnant en parallèle (Fig. 7(b))

• Relecture des trois flux de trafic de Wehe avec 2 services de streaming supplémentaires fonctionnant en parallèle (Fig. 7(c))

Les performances de la figure 7 (a) montrent que les performances des flux de trafic générés par l'outil Wehe sont les mêmes sans conditions de charge de réseau supplémentaires. À mesure que la charge du réseau augmente, les performances de la relecture de contrôle s'écartent de celles de la relecture originale et à un niveau supérieur (Fig. 7 (b)). Bien que les performances de la relecture de contrôle s'écartent davantage de la relecture originale sur la face inférieure, deux rediffusions originales montrent toujours des performances similaires, comme le montre la figure 7 (c). Cela invalide l'attente de l'outil Wehe selon laquelle la relecture de contrôle ne sera pas différenciée. Cela invalide également la prétention de l'outil de détection du TD en raison de la bande passante totale.

E. Wehe teste à partir de plusieurs appareils au sein du même sous-réseau

Les canaux latéraux sont introduits dans la conception Wehe pour prendre en charge plusieurs clients utilisateurs simultanément. Les canaux secondaires aident également à identifier le mappage entre l'utilisateur-client et une combinaison d'adresses IP et de ports. C'est utile dans le cas de réseaux utilisant des NAT [33]. Nous avons validé la prise en charge de Wehe pour plusieurs clients et réseaux compatibles NAT à l'aide de deux tests différents. Tout d'abord, nous avons connecté deux utilisateurs-clients du même sous-réseau, c'est-à-dire des clients partageant la même adresse IP publique. Dans un test, l'outil Wehe teste le même service sur les deux appareils, par exemple, l'application Wehe sur les deux appareils teste YouTube. Le résultat montre que le test Wehe s'est terminé sur un seul appareil tandis que l'application Wehe s'est brusquement fermée sur un autre appareil. Nous avons répété le même scénario, mais cette fois, Wehe teste différents services, par exemple Wehe sur un appareil testant YouTube pendant qu'un autre teste Netflix. Nous avons constaté que le test Wehe sur un appareil se termine correctement tandis que le test Wehe sur un autre appareil génère une erreur à l'écran, informant l'utilisateur qu'un autre client effectue déjà le test, comme le montre la figure 9. Ces tests montrent que Wehe le fait. ne prend pas en charge plusieurs appareils s’ils partagent la même adresse IP. Bien qu'un canal secondaire soit utile pour identifier chaque replay d'un utilisateur-client connecté directement au serveur de replay Wehe, il n'est pas utile dans le réseau utilisant des appareils NAT. Plusieurs utilisateurs partagent la même adresse IP dans le cas du NAT. Dans de tels cas, le canal secondaire ne peut pas mapper de manière unique chaque exécution de réexécution à un client. Il limite l'utilisation de Wehe à un seul client actif par serveur de relecture, FAI et application. Cette limitation est également documentée par les développeurs Wehe.

F. Effet de la charge du réseau de périphériques sur la détection TD

Le serveur de relecture de Wehe utilise les mêmes délais entre les transferts de données d'application que ceux du trafic d'application d'origine. Une telle stratégie de transmission ne devrait pas épuiser la bande passante disponible. Par conséquent, l'effet de la modulation du débit source dû à un dépassement du débit de trafic au-dessus de la bande passante disponible est peu probable. Les rediffusions originales et de contrôle affichent des performances de trafic similaires, à moins qu'elles ne soient délibérément modifiées par les politiques du réseau, par exemple TD.

Néanmoins, cette attente n'est pas toujours satisfaite car le débit de données du trafic est modulé par la charge du réseau sur la machine utilisateur lors de l'exécution des tests Wehe. De telles perturbations créent des divergences dans la mesure où l'effet de la charge actuelle du réseau, variable dans le temps, sur le trafic de sondage varie également dans le temps et peut ne pas toujours être le même. La stratégie de relecture consécutive de Wehe garantit que les flux de trafic de sondage (relecture d'origine et relecture de contrôle) sont affectés différemment par la charge actuelle du réseau. Sous une telle charge de réseau côté appareil, la notion de services n'épuisant pas la bande passante disponible cesse d'exister ainsi que ses avantages pour la détection TD. Il est nécessaire de normaliser ces facteurs de confusion (voir Sec. III-B) avant la détection du TD.