La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: corrector le 29 août 2013 à 17:25:36
-
À votre avis, quand vous vous connectez à un site en HTTPS, quelles informations quelqu'un qui espionne votre ligne peut récupérer?
EDIT : espionner = écoute passive indétectable seulement; pas d'altération des données (même celles non protégées)
Ne lisez pas les autres réponses!
-
l'ip source / l'ip de destination (tout le header du paquet)
peut ètre l'url...
après le reste doit ètre chiffré? (mais si tu pose la question c'est qu'il doit y à avoir autre chose^^)
-
Cela ne dépend t'il pas du chiffrement utilisé ?
Exemple : Information trouvée sur WIKI :
As of March 2013, an estimated 65.4% of web sites were supporting protocol variants vulnerable to the BEAST attack, 26.5% vulnerable to the CRIME attack (see below), and 33.8% with insecure ciphers.
Du coup en fonction de l'attaque utilisée et à laquelle le protocole du chiffrement est faillible (TLS1.0), on peut par exemple déchiffrer cookie donc session stealing. Correct ?
Je crois que le sujet a déjà été évoqué mais cela ne dépent-il pas du fait que le certificat utilisé est bien l'original et officiel ?
Sinon si la communication est correctement chiffrée, je confirme après test ne voir que ip source, ip destination mais pas le header. Après pour le header c'est peut-être une erreur de ma part.
Désolé si inepsies mais je suis avant tout la pour apprendre aussi :)
-
- Nom du site web visité (via le DNS)
- IP du site web visité
- IP publique du client
- Ping entre le point de capture et le serveur
- Ping entre le point de capture et le client
- Qualité du lien (pertes de paquets)
- Nombre de visites vers le site web (si capture longue)
- Durée des visites
- Taille échangée
- Type de trafic (consultation web / téléchargement de fichiers / streaming audio / streaming vidéo) en fonction de la taille des paquets, du débit et de sa distribution dans le temps.
- D'èmettre des hypothèses sur le système d'exploitation coté client et coté serveur en fonction du comportement IP et des options activées (la norme est large et chaque système a un fonctionnement IP un peu différent ce qui permet de faire des hypothèses)
Par contre, il me semble qu'il n'est pas possible d'avoir les url des pages à moins d'avoir un script en http sur le site web https.
-
peut ètre l'url...
Est-ce que tu réalises que sur la console de gestion Free (sur https://subscribe.free.fr/login/login.pl ) la connaissance de URL permet de récupérer la session?
Tu postes une URL d'une page de la console de gestion Free dans un forum, et paf, quelqu'un d'autre peut voir ton RIB, commander des options, etc.
L'URL est souvent une donnée sensible! (pas toujours évidemment)
-
Cela ne dépend t'il pas du chiffrement utilisé ?
Exemple : Information trouvée sur WIKI :
As of March 2013, an estimated 65.4% of web sites were supporting protocol variants vulnerable to the BEAST attack, 26.5% vulnerable to the CRIME attack (see below), and 33.8% with insecure ciphers.
Du coup en fonction de l'attaque utilisée et à laquelle le protocole du chiffrement est faillible (TLS1.0), on peut par exemple déchiffrer cookie donc session stealing. Correct ?
Attention, la question (sans doute pas assez claire) portait sur une simple écoute passive indétectable.
J'ai modifié le message pour éviter toute ambiguïté.
Je reviendrais sur ces attaques.
-
Dans ce cas je n'ai rien dit :) .
Pour ton exemple chez free, c'est tout aussi valable en étant chez orange. Une visite sur l'espace client orange nous auto-logue en tant que proprio de la ligne.
Néanmoins, le RIB est en parti masqué dans les infos clients ;D Merci Orange pour cet effort :P
-
- Nom du site web visité (via le DNS)
Peux-tu préciser?
- Nombre de visites vers le site web (si capture longue)
- Durée des visites
- Taille échangée
- Type de trafic (consultation web / téléchargement de fichiers / streaming audio / streaming vidéo) en fonction de la taille des paquets, du débit et de sa distribution dans le temps.
Bien vu : la quantité de données, le rapport up/down et surtout la répartition des données up et down renseigne sur le type d'usage.
-
Pour ton exemple chez free, c'est tout aussi valable en étant chez orange.
Attention, il faut s'authentifier pour accéder à la console de compte Freebox.
Une visite sur l'espace client orange nous auto-logue en tant que proprio de la ligne.
Ah oui, c'est violent.
C'est pour punir les clients qui hébergent un nœud de sortie Tor?
-
En https on fait quand même des requêtes DNS vers chacune des domaines et donc en écoutant le trafic DNS on arrive à savoir quels sites tu vas voir facilement (plus simple que l'IP)
-
En https on fait quand même des requêtes DNS vers chacune des domaines et donc en écoutant le trafic DNS on arrive à savoir quels sites tu vas voir facilement (plus simple que l'IP)
Bien vu : il faut considérer tout ce qui passe sur la ligne et non le seul flux HTTPS. La sécurité d'un système, ce n'est pas juste des morceaux sûr les uns à coté des autres, c'est un ensemble sûr.
Le client doit trouver l'adresse du serveur, en passant par le DNS, et un espion peut observer le flux DNS.
Question subsidiaire : si maintenant on suppose que le client utilise DNSSEC (intégré dans le navigateur ou dans l'OS), qu'est-ce que ça change par rapport à ce problème?
Ne regardez pas tout de suite les réponses.
-
pas faux pour l'url
de toutes façon c'était con comme réponse parce que le contenu des requête est sensé être chiffré....
bref
très instructif comme sujet!
sinon pour dnssec
le principe ce n'est pas juste de garantir la provenance des enregistrements dns?
pour éviter la modification par un pirate (justement).
après aucune idée si le pirate peut voir le contenu ou pas
-
Dans ce cas je n'ai rien dit :) .
Pour ton exemple chez free, c'est tout aussi valable en étant chez orange. Une visite sur l'espace client orange nous auto-logue en tant que proprio de la ligne.
Néanmoins, le RIB est en parti masqué dans les infos clients ;D Merci Orange pour cet effort :P
Une simple création d'une adresse mail supplèmentaire et le "problème" est résolu :)
Cordialement
Bensay
-
Une simple création d'une adresse mail supplèmentaire et le "problème" est résolu :)
Oui, c'est pas trop difficile, mais encore faut-il le savoir.
Je m'étais renseigné dans les agences Orange pour savoir s'ils avaient une offre adaptée (forfait bloqué si possible) à un appartement loué en état (avec connexion Internet fournie, donc). J'ai demandé plusieurs fois, à plusieurs vendeurs, et aucun ne m'a parlé de ce problème facile à régler.
Les vendeurs de SFR étaient encore plus nuls : ils ne semblait pas comprendre ma question, pourtant pas très compliquée : une offre avec une facture fixée à l'avance, sans que le locataire puisse prendre des options ou faire des frais supplèmentaires; pas possible, après plusieurs explications les deux vendeurs de SFR me regardaient avec un air ahuri.
Je ne leur demandais pas la lune IPv6 pourtant...
-
C'est vrai qu'ils y aura toujours de commerciaux/commerciaux , et des Techniciens/Techniciens :)
Bien que l'on essaye de faire changer les choses a nos niveaux Locaux :)
Cdt
Bensay
-
peut ètre l'url...
après le reste doit ètre chiffré? (mais si tu pose la question c'est qu'il doit y à avoir autre chose^^)
Tous les messages envoyés ou reçus via TLS sont censés être chiffrés et donc confidentiels!
HTTPS = HTTP sur TLS
donc tout l'échange est chiffré : requête + réponse
Le piège, c'est qu'il y a des informations qui peuvent quand même être révélées : vivien a mentionné la recherche DNS qui divulgue une certaine information, que la connexion se fasse par la suite en HTTP ou en HTTPS.