Yazarlar:  (1) Vinod S. Khandkar ve Manjesh K. Hanawal, Endüstri Mühendisliği ve Yöneylem Araştırması Hindistan Teknoloji Enstitüsü Bombay, Mumbai, Hindistan ve {vinod.khandkar, mhanawal}@iitb.ac.in.  Bağlantı Tablosu   Özet ve Giriş   İlgili Çalışma ve Arka Plan   TD Tespit Ölçüm Kurulumu Geliştirmedeki Zorluklar   Örnek Olay: Wehe - Mobil Ortam için TD Tespit Aracı   Wehe'nin HTTPS Trafiğindeki Eksikliği   HTTPS Trafiğinin TD Tespiti   Sonuç ve Referanslar  V. WEHE'NİN HTTPS TRAFİĞİNDEKİ EKSİKLİKLERİ  Çalışmamız, tekrar oynatılan trafik akışlarına yönelik ağ yanıtlarının, TD tespitinin ve çeşitli ağ yapılandırmalarındaki operasyonel fizibilitenin doğrulanmasına odaklanmaktadır. Operasyonel fizibilite, Google Playstore'da halka açık "Wehe" Android uygulaması kullanılarak doğrulanırken, TD tespit senaryoları teorik argümanlar kullanılarak doğrulanır. Ağ yanıtlarının doğrulanması, alınan trafik akışının bant genişliği analizini gerektirir. Bu analiz, doğrulama senaryosuna göre gerçekleştirilen belirli tekrar oynatma için ağ günlüklerini gerektirir. Cihazda yapılan tekrar oynatma ve diğer birçok akış   Şekil 6. Tekrar oynatılan YouTube trafiğinin trafik sınıflandırması  paralel çalışan hizmetler böyle bir senaryodur. Wehe uygulaması, testlerin tamamlanmasının ardından tekrarlar için bu tür ağ günlüklerini hemen sağlamaz. Bu nedenle Wehe aracının davranışını taklit eden kullanıcı-istemci ve sunucuyu uyguladık.  Wehe'yi doğrulamak için Şekil 3'te gösterilen kuruluma benzer bir istemci-sunucu kurulumu kullanıyoruz. Mevcut kurulumda orijinal hizmetin sunucusunu tekrar oynatma sunucusuyla değiştirdik. Kullanıcı istemcisi ve tekrar sunucusu ticari bir trafik şekillendirici aracılığıyla bağlanır. Üstelik kurulumumuzda birden fazla tekrarın paralel olarak gerçekleştirilmesine yönelik bir hüküm bulunmaktadır. Doğrulama kurulumumuz, yan kanallar gibi yönetim kanallarına ve ek yüklere ihtiyaç duymaz. Sunucumuzun her zaman tek kullanıcılı bir istemciyi desteklemesi gerekir. Birden fazla istemciyle senaryoların doğrulanması, ilgili trafik analizine ihtiyaç duyulmaması nedeniyle doğrudan Wehe Uygulamasını kullanır.  Bu bölümün hatırlatıcısı doğrulama sonuçlarını açıklar.   A. Orijinal hizmetin trafik emülasyonu  Ağ tepkileri, Bölüm III-A'da bahsedildiği gibi ağ orta kutuları tarafından trafiğin doğru şekilde araştırılmasına dayanan ağ politikalarının uygulanmasına bağlıdır. Ticari bir trafik şekillendirici kullanarak Wehe'nin taklit trafiğinin sınıflandırmasını doğruladık. Benzetilmiş trafiğin sınıflandırılması, ticari trafik şekillendiricinin kullanıcı arayüzü kullanılarak gözlemlenir.  Deneyi gerçekleştirmek için YouTube uygulama verileri, ticari trafik şekillendirici aracılığıyla tekrar oynatma sunucusundan kullanıcı-istemciye yeniden oynatılır. Veri aktarımı sırasında ticari trafik şekillendiricinin kullanıcı arayüzü penceresi, YouTube trafiğinin varlığı açısından gözlemlenir. Ayrıca YouTube trafiğine bir internet tarayıcısı kullanarak eriştik ve trafik sınıflandırma gözlemlerimize temel oluşturmak için trafik şekillendiricinin sınıflandırma sonucunu gözlemledik.  Şekil 6, bir YouTube sunucusundan bir internet tarayıcısı kullanılarak doğrudan erişilen trafiğe yönelik ticari trafik şekillendiricinin kullanıcı arayüzü penceresi tarafından gösterildiği gibi trafik sınıflandırma sonucunu göstermektedir. Sol pencerede internet etkinliğini, sağ pencerede ise ilgili trafiğin sınıflandırmasını gösterir.  Şekil 6(a), internet tarayıcısı kullanılarak erişilen trafiğin doğru bir şekilde YouTube olarak sınıflandırıldığını göstermektedir. Bu, ticari trafik şekillendiricinin amaçlanan davranışıyla uyumludur.  Şekil 6(b), kullanıcı-istemci kullanılarak erişilen trafik için trafik sınıflandırma sonucunu göstermektedir. İletişim bağlantısı üzerinden hiçbir YouTube trafiğinin aktarılmadığına dair kanıt gösterir. Üstelik aynı trafiği HTTPS trafiğiyle sınıflandırır. Bu deneyin sonucu, tüm ağ orta kutularının Wehe'nin yeniden oynatılan trafiğini doğru şekilde sınıflandıramadığını göstermektedir.   B. Tekrar komut dosyasındaki veri hızının etkisi  Araştırma trafiği üretimi, TD tespit algoritması tarafından beklendiği gibi ağ tepkisini etkiler. Wehe, uygulama verilerini ve bunun zamanlama ilişkisini koruyan tekrar yürütme komut dosyaları oluşturmak için orijinal hizmetten gelen trafik izini kullanır. Bu yeniden oynatma komut dosyası, orijinal ağ üzerinden ve ayrıca coğrafi konumu farklı olan ağlarda kullanılır. Trafik şekillendirme oranı aynı hizmet için ağlar arasında değiştiğinden ([32]'de bahsedildiği gibi), tekrar komut dosyasında korunan trafik oranı, halihazırda dikkate alınan ağın trafik şekillendirme oranından farklı olabilir. Tekrar trafik oranı, trafik şekillendirme oranından daha düşük olabilir.  Wehe metodolojisi, tekrar komut dosyasının trafik hızı, trafik akışını etkilemediğinden ağın şekillendirme oranından düşükse trafik farklılaşmasını algılamaz. Bu tür yeniden oynatma komut dosyaları, bu tür ağlardaki trafik şekillenmesini asla tespit edemez. Bu nedenle Wehe aracının TD algılama kapasitesi, tekrar komut dosyasının tarama trafik hızıyla sınırlıdır.   C. 80 numaralı bağlantı noktasının kullanımı  Ağ yanıtları, ağ orta kutularının araştırma trafiği hakkındaki algısı tarafından yönlendirilir (bkz. Bölüm III-A). Yeniden yürütme komut dosyası, uygulamaların orijinal ağ izlemesindeki verileri korur. Orijinal uygulama sunucuları, düz metin verileri için 80 numaralı bağlantı noktasını ve şifreli veri aktarımı için 443 numaralı bağlantı noktasını kullanır. Wehe yeniden oynatma komut dosyası, uygulamanın ağ izinden gelen şifrelenmiş verileri doğrudan kullanır ve bunu 80 numaralı bağlantı noktasına iletir. Bu gibi durumlarda Wehe, orijinal yeniden oynatma trafiği akışının, şifrelenmiş uygulama verilerini kullanan ağ cihazları tarafından doğru şekilde sınıflandırılmasını bekler. Şifrelenmiş trafik verilerinin kimliğini ağ cihazına gösteremeyeceği için 80 numaralı bağlantı noktasındaki bu tür verilerin olması imkansızdır. Dolayısıyla Wehe aracı, tekrar çalıştırma için 80 numaralı bağlantı noktasının varsayılan kullanımı nedeniyle 443 numaralı bağlantı noktasında çalışan hizmetler için gerekli trafik akışlarını oluşturamaz.   D. Trafik yükü tarafından yönetilen ağ davranışı  Kaynakların kıtlığının, ağları, özellikle ağır ağ yükü senaryolarında, ağındaki tüm aktif hizmetler için yararlı olan, örneğin QoS tabanlı trafik yönetimi gibi belirli ağ trafiği yönetimini uygulamaya sevk ettiğini unutmayın (bkz. Bölüm III-A). Bu tür trafik yönetiminin etkisini doğruladık   Şekil 7. Ağ yükünün Wehe'nin trafik akışı performansına etkisi  hem kontrol hem de orijinal tekrarların performansları hakkında. Doğrulama, doğrulama için aşağıdaki üç senaryoyu kullanır:  • Ağda herhangi bir yük olmadan yalnızca Wehe'nin iki trafik akışının yeniden oynatılması (Şekil 7(a))  • Wehe'nin üç trafik akışının paralel çalışan bir ek akış hizmetiyle yeniden oynatılması (Şekil 7(b))  • Wehe'nin üç trafik akışının paralel çalışan 2 ek akış hizmetiyle yeniden oynatılması (Şekil 7(c))  Şekil 7(a)'daki performanslar, Wehe aracı tarafından oluşturulan trafik akışlarının performanslarının, hiçbir ek ağ yükü koşulu olmadığında aynı olduğunu göstermektedir. Ağ yükü arttıkça, kontrol tekrarının performansı orijinal tekrardan ve daha yüksek seviyeden sapar (Şekil 7(b)). Kontrol tekrarının performansı alt tarafta orijinal tekrardan daha da sapsa da, iki orijinal tekrar Şekil 7(c)'de gösterildiği gibi hala benzer performanslar göstermektedir. Bu, Wehe aracının kontrol tekrarının farklılaşmaması beklentisini geçersiz kılar. Ayrıca aracın toplam bant genişliği nedeniyle TD'yi tespit etme iddiasını da geçersiz kılar.   E. Aynı alt ağdaki birden fazla cihazdan test yapıyoruz  Wehe tasarımında yan kanallar, aynı anda birden fazla kullanıcı istemcisini desteklemek için eklenmiştir. Yan kanallar ayrıca kullanıcı-istemci ile IP adresleri ve bağlantı noktalarının birleşimi arasındaki eşlemenin tanımlanmasına da yardımcı olur. NAT kullanan ağlarda kullanışlıdır [33]. Wehe'nin birden fazla istemciye ve NAT özellikli ağlara verdiği desteği iki farklı test kullanarak doğruladık. İlk olarak, aynı alt ağdan, yani aynı genel IP adresini paylaşan istemcilerden iki kullanıcı-istemciyi birbirine bağladık. Bir testte, Wehe aracı aynı hizmeti her iki cihazda da test eder; örneğin Wehe Uygulaması her iki cihazda da YouTube için test eder. Sonuç, Wehe testinin yalnızca bir cihazda sonlandırıldığını, Wehe Uygulamasının başka bir cihazda aniden kapandığını gösteriyor. Aynı senaryoyu tekrarladık, ancak bu sefer Wehe farklı hizmetleri test ediyor; örneğin, Wehe bir cihazda YouTube'u test ederken diğerinde Netflix'i test ediyor. Şekil 9'da gösterildiği gibi, bir cihazdaki Wehe testinin düzgün şekilde tamamlandığını, diğer cihazdaki Wehe testinin ise ekranda bir hata vererek kullanıcıya başka bir istemcinin testi zaten gerçekleştirdiğini bildirdiğini bulduk. Bu testler Wehe'nin bunu yaptığını gösteriyor aynı IP adresini paylaşıyorlarsa birden fazla cihazı desteklemez. Bir yan kanal, doğrudan Wehe tekrar oynatma sunucusuna bağlı bir kullanıcı-istemciden gelen her tekrarı tanımlamak için faydalı olsa da, NAT cihazlarını kullanan ağda kullanışlı değildir. NAT durumunda birden fazla kullanıcı aynı IP adresini paylaşır. Bu gibi durumlarda, yan kanal her tekrar çalıştırmasını bir istemciye benzersiz şekilde eşleyemez. Wehe'nin kullanımını tekrar oynatma sunucusu, ISP ve uygulama başına yalnızca bir aktif istemciyle sınırlandırır. Bu sınırlama Wehe geliştiricileri tarafından da belgelenmiştir.   F. Cihaz ağ yükünün TD tespitine etkisi  Wehe'nin tekrar sunucusu, uygulama veri aktarımı arasında orijinal uygulama trafiğiyle aynı zamanlamaları kullanır. Böyle bir iletim stratejisinin mevcut bant genişliğini tüketmemesi beklenmektedir. Bu nedenle, trafik hızının mevcut bant genişliğinin üzerine çıkması nedeniyle kaynak hızı modülasyonunun etkisi olası değildir. Ağ politikaları (ör. TD) tarafından kasıtlı olarak değiştirilmediği sürece, orijinal ve kontrol tekrarlarının benzer trafik performansları göstermesini sağlar.  Ancak Wehe testleri yapılırken trafik veri hızı kullanıcı cihazındaki ağ yükü tarafından modüle edildiğinden bu beklenti her zaman karşılanmamaktadır. Bu tür karışıklıklar, zamanla değişen mevcut ağ yükünün araştırma trafiği üzerindeki etkisi de zamanla değiştiğinden ve her zaman aynı olmayabileceğinden tutarsızlık yaratır. Wehe'nin arka arkaya tekrar oynatma stratejisi, hem (orijinal hem de kontrol tekrarının) incelenen trafik akışlarının mevcut ağ yükünden farklı şekilde etkilenmesini sağlar. Cihaz tarafında bu tür bir ağ yükü altında, mevcut bant genişliğini tüketmeyen hizmetler kavramı, TD tespitine yönelik faydalarıyla birlikte ortadan kalkmaktadır. TD tespitinden önce bu tür kafa karıştırıcı faktörlerin normalleştirilmesi gerekir (bkz. Bölüm III-B).  Bu makale   . arxiv'de CC 4.0 lisansı altında mevcuttur

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

Read My Stories

NetNeutrality

Bu ses hikayenin orijinal dilinde üretilmiştir!

Wehe'nin HTTPS Trafik Algılama Konusunda Eksikliklerini Anlamak

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps