Les URL sont-elles affichées lors des transactions HTTPS vers un ou plusieurs sites Web à partir d'une seule adresse IP?
Par exemple, supposons que les URL HTTPS vers deux sites Web par une IP sur 5 minutes soient les suivantes: "A.com/1", "A.com/2", "A.com/3", "B.com/1" , "B.com/2".
La surveillance des paquets révélerait-elle:
- rien,
- révéler que seule l'IP a visité "A.com" et "B.com" (c'est-à-dire le DNS uniquement),
- révéler que seule l'IP a visité "A.com/1" et "B.com/1" (la première requête HTTPS pour chaque site),
- révéler une liste complète de toutes les URL HTTPS visitées,
- ne révèlent que les IP de "A.com" et "B.com",
- ou autre chose?
Question connexe: mon entreprise peut-elle voir sur quels sites HTTPS je suis allé?
Bien que cette question contienne des informations supplémentaires, pour autant que je sache, elle ne traite pas spécifiquement du scénario "révéler que l'IP a visité" A.com/1 "et" B.com/1 "(le premier Demande HTTPS pour chaque site) "- bien que la possibilité de se tromper soit élevée et heureux de supprimer la question s'il s'agit d'un doublon.
REMARQUE: Ceci est une question de suivi à un réponse qui a été posté comme: Pourquoi HTTPS n'est-il pas le protocole par défaut?
TLS révèle à un espion les informations suivantes:
- le site que vous contactez
- la longueur (éventuellement approximative) du reste de l'URL
- la longueur (éventuellement approximative) du code HTML de la page que vous avez visitée (en supposant qu'elle ne soit pas mise en cache)
- le nombre (éventuellement approximatif) d'autres ressources (par exemple, images, iframes, feuilles de style CSS, etc.) sur la page que vous avez visitée (en supposant qu'elles ne sont pas mises en cache)
- l'heure à laquelle chaque paquet est envoyé et chaque connexion est établie. (@nealmcb souligne que l'écoute clandestine apprend beaucoup sur le timing: l'heure exacte à laquelle chaque connexion a été initiée, la durée de la connexion, l'heure à laquelle chaque paquet a été envoyée et l'heure à laquelle la réponse a été envoyée, l'heure à laquelle le serveur doit répondre à chaque paquet, etc.)
Si vous interagissez avec un site Web en cliquant sur des liens en série, l'écouteur peut voir chacun d'eux pour chaque clic sur la page Web. Ces informations peuvent être combinées pour essayer de déduire quelles pages vous visitez.
Par conséquent, dans votre exemple, TLS ne révèle que A.com vs B.com, car dans votre exemple, le reste de l'URL a la même longueur dans tous les cas. Cependant, votre exemple a été mal choisi: il n'est pas représentatif d'une pratique typique sur le web. Habituellement, la longueur des URL sur un site particulier varie et révèle ainsi des informations sur l'URL à laquelle vous accédez. De plus, la longueur des pages et le nombre de ressources varient également, ce qui révèle encore plus d'informations.
Des recherches suggèrent que ces fuites peuvent révéler des informations substantielles aux écoutes sur les pages que vous visitez. Par conséquent, vous ne devez pas supposer que TLS masque les pages que vous visitez dans une écoute indiscrète. (Je me rends compte que c'est contre-intuitif.)
Ajouté: Voici des citations de certaines recherches dans la littérature sur l'analyse du trafic de HTTPS:
Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow , IEEE Security & Privacy 2010. Ce document est assez époustouflant; par exemple, il montre comment les suggestions de recherche basées sur AJAX peuvent révéler quels caractères vous tapez, même via SSL. Voici un aperçu de haut niveau de l'article .
Kehuan Zhang, Zhou Li, Rui Wang, XiaoFeng Wang, Shuo Chen. Sidebuster: Détection et quantification automatisées des fuites latérales dans le développement d'applications Web . CCS 2010.
Marc Liberatore, Brian Neil Levine. déduction de la source des connexions HTTPS cryptées . CCS 2006.
George Danezis. Analyse du trafic du protocole HTTP sur TLS , non publié.
George Dean Bissias, Marc Liberatore, Brian Neil Levine. Vulnérabilités de confidentialité dans les flux HTTPS chiffrés . PET 2005.
Qixiang Sun, Daniel R. Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, Lili Qiu. Identification statistique du trafic de navigation Web crypté . Sécurité et confidentialité IEEE 2002.
Andrew Hintz. sites Web d'empreintes digitales utilisant l'analyse du trafic . PET2002.
Heyning Cheng, Ron Avnur. Analyse du trafic de la navigation Web cryptée SSL . Projet de classe, 1998.
Shailen Mistry, Bhaskaran Raman. Quantifier l'analyse du trafic de la navigation Web cryptée . Projet de classe, 1998.
Le deuxième choix. La plupart.
Lorsqu'un navigateur visite un site Web HTTPS, il établit un tunnel TLS , ce qui implique un échange de clés asymétrique (le client et le serveur conviennent d'un secret partagé). Ce mécanisme d'échange de clés utilise la clé publique du serveur, que le serveur affiche dans le cadre de son certificat. Le certificat de serveur contient le nom du serveur (par exemple A.com) et le client vérifie que le nom correspond à celui qu'il attend (c'est-à-dire le nom du serveur dans l'URL). Le certificat de serveur est envoyé, fatalement, avant l'échange de clés, donc en clair.
Le reste de l'URL est envoyé dans le cadre de la requête HTTP qui se produit dans le tunnel crypté, donc invisible pour les tiers. Un tunnel donné peut être réutilisé pour plusieurs autres requêtes HTTP, mais (par construction) ils sont tous pour le même serveur (le même nom de domaine).