Rozeznávají se adresy URL během transakcí HTTPS na jednom nebo více webech z jediné adresy IP?
Řekněme například, že jsou to HTTPS URL na dva weby pomocí jedné IP po dobu 5 minut: „A.com/1“, „A.com/2“, „A.com/3“, „B.com/1“ , „B.com/2“.
Zjistilo by monitorování paketů:
- nic,
- odhalit pouze IP, které navštívilo „A.com“ a „B.com“ (což znamená pouze DNS),
- odhalit pouze IP, které navštívilo „A.com/1“ a „B.com/1“ (první požadavek HTTPS pro každý web),
- odhalit úplný seznam všech navštívených adres URL HTTPS,
- odhalí pouze adresy IP „A.com“ a „B.com“,
- nebo něco jiného?
Související otázka: Může moje společnost vidět, na které stránky HTTPS jsem šel?
I když tato otázka obsahuje další informace, pokud je mi to možné říct, neřeší konkrétně scénář „odhalit pouze IP navštívenou“ A.com/1 “a„ B.com/1 “(první Požadavek HTTPS pro každý web) “- i když je možné, že se o tom bude mýlit, je vysoká, a pokud je duplikát, rádi ji odstraníme.
POZNÁMKA: Toto je odpověď na otázku odpověď , která byla zaúčtována jako: Proč HTTPS není výchozí protokol?
TLS odhalí odposlouchávači následující informace:
- web, který kontaktujete
- (možná přibližná) délka zbývající adresy URL
- (možná přibližná) délka HTML stránky, kterou jste navštívili (za předpokladu, že není v mezipaměti)
- (možná přibližný) počet dalších zdrojů (např. obrázků, prvků iframe, stylů CSS atd.) na navštívené stránce (za předpokladu, že nejsou v mezipaměti)
- čas odeslání každého paketu a zahájení každého spojení. (@nealmcb poukazuje na to, že odposlouchávač se učí šarži o časování: přesný čas, kdy bylo každé připojení iniciováno, doba trvání připojení, čas každého paketu byl odeslán a čas odeslání odpovědi, čas na odpověď serveru na každý paket atd.)
Pokud interagujete s webovým serverem kliknutím na odkazy v sérii, může odposlouchávač vidět každý z nich pro každé kliknutí na webové stránce. Tyto informace lze zkombinovat a pokusit se odvodit, které stránky navštěvujete.
Proto ve vašem příkladu TLS odhaluje pouze A.com vs B.com, protože ve vašem příkladu je zbytek URL ve všech případech stejně dlouhý. Váš příklad však byl vybrán špatně: není to typická praxe na webu. Délka URL se obvykle na konkrétním webu liší, a tak odhalují informace o adrese URL, ke které přistupujete. Kromě toho se liší také délka stránky a počet zdrojů, což odhaluje ještě více informací.
Výzkum naznačil, že tyto úniky mohou odhalit podstatné informace o tom, které stránky navštěvujete, odposlouchávačům. Proto byste neměli předpokládat, že TLS skrývá stránky, které navštěvujete před odposlouchávačem. (Uvědomuji si, že je to kontraintuitivní.)
Přidáno: Zde jsou citace k některému výzkumu v literatuře týkající se analýzy provozu HTTPS:
Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Únik vedlejších kanálů ve webových aplikacích: Realita dnes, výzva zítra , IEEE Security & Privacy 2010. Tento dokument je docela ohromující; například ukazuje, jak návrhy vyhledávání založené na AJAX mohou odhalit, jaké znaky zadáváte, a to i přes SSL. Zde je přehled příspěvku na vysoké úrovni .
Kehuan Zhang, Zhou Li, Rui Wang, XiaoFeng Wang, Shuo Chen. Sidebuster: Automatická detekce a kvantifikace úniků postranních kanálů ve vývoji webových aplikací . CCS 2010.
Marc Liberatore, Brian Neil Levine. Odvození zdroje šifrovaných připojení HTTPS . CCS 2006.
George Danezis. Analýza provozu protokolu HTTP přes TLS , nepublikováno.
George Dean Bissias, Marc Liberatore, Brian Neil Levine. Chyby zabezpečení v šifrovaných proudech HTTPS . PET 2005.
Qixiang Sun, Daniel R. Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, Lili Qiu. Statistická identifikace šifrovaného provozu na web . IEEE Security & Privacy 2002.
Andrew Hintz. Otisky prstů na webových stránkách pomocí analýzy provoz . PET2002.
Heyning Cheng, Ron Avnur. Analýza provozu SSL šifrovaného prohlížení web . Projekt třídy, 1998.
Shailen Mistry, Bhaskaran Raman. Kvantifikace analýzy provozu šifrovaného webového prohlížení . Projekt třídy, 1998.
Druhá volba. Většinou.
Když prohlížeč navštíví web HTTPS, vytvoří TLS tunel, který zahrnuje asymetrickou výměnu klíčů (klient a server se dohodnou na sdíleném tajemství). Tento mechanismus výměny klíčů používá veřejný klíč serveru, který server zobrazuje jako součást svého certifikátu. Certifikát serveru obsahuje název serveru (např. A.com) a klient ověří, že název odpovídá názvu, které očekává (tj. název serveru v adrese URL). Certifikát serveru je zaslán smrtelně před před výměnou klíčů, tedy v prostém pohledu.
Zbytek adresy URL je odeslán jako součást požadavku HTTP, ke kterému dochází v šifrovaném tunelu, a proto je třetím stranám neviditelný. Daný tunel může být znovu použit pro několik dalších požadavků HTTP, ale (podle konstrukce) jsou všechny pro stejný server (stejný název domény).