paint-brush
Wehe'nin HTTPS Trafik Algılama Konusunda Eksikliklerini Anlamakile@netneutrality

Wehe'nin HTTPS Trafik Algılama Konusunda Eksikliklerini Anlamak

Çok uzun; Okumak

Bu çalışma, Wehe uygulamasının özellikle HTTPS trafiğinde trafik farklılaşmasını tespit etmede karşılaştığı zorlukları ele alıyor. Ağ yanıtları, trafik oranları, bağlantı noktası kullanımı, ağ yükü etkileri ve NAT cihazlarının kullanımındaki kısıtlamalarla ilgili sorunları tartışıyor ve Wehe'nin çeşitli senaryolarda TD'yi tespit etmedeki sınırlamalarına ışık tutuyor.
featured image - Wehe'nin HTTPS Trafik Algılama Konusunda Eksikliklerini Anlamak
Net Neutrality: Unbiased Internet Access for All!  HackerNoon profile picture
0-item

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ış


(a) İnternet tarayıcısını kullanma


(b) Kullanıcı istemcisini kullanma


Ş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


(a) Yalnızca Wehe


(b) Wehe artı bir hizmet


(c) Wehe artı iki hizmet


Ş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).