HTTPS işlemleri sırasında tek bir IP'den bir veya daha fazla web sitesine görünen URL'ler ayırt edilebilir mi?
Örneğin, aşağıdakilerin 5 dakika boyunca bir IP tarafından iki web sitesine HTTPS URL'si olduğunu söyleyin: "A.com/1", "A.com/2", "A.com/3", "B.com/1" , "B.com/2".
Paketlerin izlenmesi aşağıdakileri ortaya çıkarır:
- hiçbir şey değil,
- yalnızca IP'nin "A.com" ve "B.com" adresini ziyaret ettiğini (yalnızca DNS anlamına gelir),
- yalnızca IP'nin "A.com/1" ve "B.com/1" (her site için ilk HTTPS isteği) sayfasını ziyaret ettiğini,
- ziyaret edilen tüm HTTPS URL'lerinin tam listesini göstermek,
- yalnızca "A.com" ve "B.com" IP'lerini gösterir,
- veya başka bir şey?
İlgili Soru: şirketim hangi HTTPS sitelerine gittiğimi görebilir mi?
Bu soruda ek bilgiler olsa da, söyleyebildiğim kadarıyla "yalnızca IP'nin" A.com/1 "ve" B.com/1 "(ilk Her site için HTTPS isteği) "- bununla ilgili yanlış olma olasılığı yüksektir ve yineleniyorsa soruyu silmekten mutluluk duyarız.
NOT: Bu, --- olarak gönderilen bir yanıt için takip eden bir soru: Neden HTTPS değil varsayılan protokol?
TLS bir kulak misafiri için aşağıdaki bilgileri açıklar:
- iletişim kurduğunuz site
- uRL'nin geri kalanının (muhtemelen yaklaşık) uzunluğu
- ziyaret ettiğiniz sayfanın HTML'sinin (muhtemelen yaklaşık) uzunluğu (önbelleğe alınmadığı varsayılarak)
- ziyaret ettiğiniz sayfadaki (muhtemelen yaklaşık) diğer kaynakların (ör. resimler, iframe'ler, CSS stil sayfaları vb.) sayısı (önbelleğe alınmadıkları varsayılarak)
- her paketin gönderildiği ve her bağlantının başlatıldığı saat. (@nealmcb, kulak misafiri zamanlama hakkında bir lot öğrenir: her bağlantının tam olarak başlatıldığı zaman, bağlantının süresi, her paketin zamanı gönderildi ve yanıtın gönderildiği saat, sunucunun her pakete yanıt vereceği süre, vb.)
Bir web sitesiyle seri bağlantılara tıklayarak etkileşimde bulunursanız, kulak misafiri web sayfasındaki her tıklama için bunların her birini görebilir. Bu bilgiler, ziyaret ettiğiniz sayfaları çıkarmak için birleştirilebilir.
Bu nedenle, örneğinizde, TLS yalnızca A.com ve B.com'u gösterir, çünkü örneğinizde URL'nin geri kalanı her durumda aynı uzunluktadır. Ancak, örneğiniz kötü seçilmişti: Web'deki tipik uygulamaları temsil etmiyor. Genellikle, belirli bir sitedeki URL uzunlukları değişiklik gösterir ve bu nedenle erişmekte olduğunuz URL hakkında bilgi verir. Dahası, sayfa uzunlukları ve kaynak sayısı da değişir, bu da daha fazla bilgi ortaya koyar.
Bu sızıntıların ziyaretçileri ziyaret ettiğiniz sayfalar hakkında önemli bilgiler verebileceğini gösteren araştırmalar yapılmıştır. Bu nedenle, TLS'nin bir kulak misafiri tarafından ziyaret ettiğiniz sayfaları gizlediğini varsaymamalısınız. (Bunun mantık dışı olduğunu anlıyorum.)
Eklendi: HTTPS'nin trafik analizi ile ilgili literatürdeki bazı araştırmalara atıflar:
Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Web Uygulamalarında Yan Kanal Sızıntıları: Bugün Gerçeklik, Yarın Zorluk , IEEE Güvenlik ve Gizlilik 2010. Bu makale oldukça dikkat çekici; örneğin, AJAX tabanlı arama önerilerinin SSL üzerinden bile yazdığınız karakterleri nasıl açığa çıkarabileceğini gösterir. İşte makalenin üst düzey genel görünümü .
Kehuan Zhang, Zhou Li, Rui Wang, XiaoFeng Wang, Shuo Chen. Sidebuster: Web Uygulaması Geliştirmede Yan Kanal Sızıntılarının Otomatik Tespiti ve Miktarının Belirlenmesi . CCS 2010.
Marc Liberatore, Brian Neil Levine. Şifreli HTTPS Bağlantılarının Kaynağını Çıkarma . CCS 2006.
George Danezis. HTTP Protokolünün TLS üzerinden Trafik Analizi , yayınlanmamış.
George Dean Bissias, Marc Liberatore, Brian Neil Levine. Şifreli HTTPS akışlarındaki gizlilik açıkları . PET 2005.
Qixiang Sun, Daniel R.Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, Lili Qiu. Şifrelenmiş web tarama trafiğinin istatistiksel tanımlaması . IEEE Güvenlik ve Gizlilik 2002.
Andrew Hintz. Trafik analizini kullanarak web sitelerini parmak izi ile yazmak . PET2002.
Heyning Cheng, Ron Avnur. SSL şifreli web'de gezinmenin trafik analizi . Sınıf projesi, 1998.
Shailen Mistry, Bhaskaran Raman. Şifrelenmiş Web Gezinmesinin Trafik Analizinin Nicelleştirilmesi . Sınıf projesi, 1998.
İkinci seçenek. Çoğunlukla.
Bir tarayıcı bir HTTPS web sitesini ziyaret ettiğinde, asimetrik bir anahtar değişimini içeren bir TLS tüneli oluşturur (istemci ve sunucu paylaşılan bir sırrı kabul eder). Bu anahtar değişim mekanizması, sunucunun sertifikasının bir parçası olarak gösterdiği sunucu ortak anahtarını kullanır. Sunucu sertifikası, sunucu adını içerir (örneğin A.com) ve istemci adın beklediği adla eşleştiğini doğrular (yani URL'deki sunucu adı). Sunucu sertifikası ölümcül olarak anahtar değişiminden önce gönderilir, dolayısıyla düz görünümde.
URL'nin geri kalanı, şifrelenmiş tünelde gerçekleşen HTTP isteğinin bir parçası olarak gönderilir, bu nedenle üçüncü taraflara görünmez. Belirli bir tünel diğer birkaç HTTP isteği için tekrar kullanılabilir, ancak (yapım gereği) hepsi aynı sunucu (aynı etki alanı adı) içindir.