Le trafic https sur un réseau sans fil non chiffré est-il sécurisé?

21

C'est quelque chose que je me demande depuis longtemps. Si, par exemple, j'utilise Gmail sur https, quelqu'un peut-il lire mes conversations et mes e-mails de messagerie instantanée si j'utilise un réseau sans fil non sécurisé? Je suppose que les données seraient sécurisées, car elles utilisent une connexion cryptée. Y a-t-il autre chose à considérer?

wireless-networking security encryption

— davidscolgan
source

3

Article à lire absolument

— Sathyajith Bhat

1

Je pense que c'était l'article qui l' a poussé / elle de poser une telle question à ce sujet.

— JFW

21

Je penserais que quelqu'un pourrait toujours effectuer une attaque d'homme au milieu si vous utilisez un wifi non sécurisé (ou même un wifi sécurisé, s'il arrive à trouver un moyen d'être autorisé à continuer). C'est pourquoi vous devez toujours vérifier que la connexion SSL apparaît en vert dans votre barre d'adresse et / ou vérifier manuellement que le certificat est valide lorsque vous utilisez le wifi non sécurisé. En supposant que le certificat est correct, le SSL devrait protéger vos données.

— Dark Android
source

7

si vraiment SSL crypté avec des certificats SSL non compromis correctement vérifiés, alors l'attaque MITM est impossible.

— ewanm89

@ ewanm89 C'est pourquoi je répète qu'il faut vérifier le certificat lors de transactions bancaires / e-mail / tout ce qui est sensible sur les réseaux non sécurisés. Si vous ne remarquez pas que le certificat ne parvient pas à valider, MITM est possible. Heureusement, les navigateurs Web de nos jours font qu'il est très difficile de ne pas le remarquer.

— Dark Android

1

Pour ajouter à @ ewanm89, il n'est pas impossible d'être un MITM et de renifler des paquets - tout simplement impossible de les lire car ils sont cryptés.

D'accord, ça divise les cheveux. MITM et avoir un paquet qui ressemble à des données aléatoires est aussi inutile que de ne pas le faire en premier lieu dans la plupart des cas. Mais oui, on pourrait également suivre le domaine auquel un ordinateur se connecte, mais ne pas connaître les données réelles envoyées / reçues. De plus, si nous voulons être parfaitement honnêtes, je pourrais théoriquement forcer les clés AES avec une puissance de calcul suffisante (indice que cela prend beaucoup).

— ewanm89

De plus, je suppose que l'autorité de certification n'est pas compromise, on vérifie que l'autorité de certification les administrateurs du site sont effectivement allés à cette autorité de certification et a demandé aux administrateurs quelle devrait être l'empreinte digitale du certificat par un autre canal. Comme on peut le voir, vérifier correctement un certificat SSL est rare (bien que cela se fasse dans des applications comme openvpn où l'administrateur distribue les certificats avant la connexion, le client aussi pour le vérifier totalement).

— ewanm89

2

Je pense que votre raisonnement est correct; pour lire vos informations, ils devraient déchiffrer le SSL. Il y aurait juste un niveau de cryptage en moins à briser pour accéder aux données cryptées.

— PeterT
source

2

Tant que votre DNS et les serveurs de clés racines SSL de votre navigateur sont valides, un attaquant sur le même réseau sans fil non sécurisé que vous ne pouvez pas accéder à votre canal SSL avec un serveur.

Le DNS est la grande vulnérabilité dans ce domaine - si votre chaîne DNS de serveurs est infectée par un attaquant, cela peut rendre toutes sortes de choses sécurisées mais en fait peu sûres.

Mais si votre question est de savoir si un pirate au hasard dans un aéroport ou un café va pouvoir pirater votre pipe SSL vers votre banque, la réponse est presque certainement non.

— stevemidgley
source

1

Quoi qu'il en soit, gardez à l'esprit que seules les données à l'intérieur du flux http sont cryptées, mais les URL ne le sont pas, alors peut-être que quelqu'un peut vous imiter.

— Ignacio Soler Garcia
source

2

Ce n'est tout simplement pas vrai. Tout dans l'URL demandée, à l'exception du nom de domaine, est crypté avant d'être envoyé via la connexion sécurisée. Cela inclut la demande GET elle-même.

— Andrew

1

Vous devez également tenir compte du fait que les premières pages non SSL ne sont pas protégées.

La plupart des sites sécurisés que vous visitez vous redirigent d'une URL http vers une URL https lorsque vous accédez à la page de connexion, mais sur un réseau non fiable, vous pourriez être envoyé ailleurs par un homme au milieu.

Considérez que vous pouvez visiter http://firstoverflowbank.com , qui vous redirige généralement vers https://login.firstoverflowbank.com mais sur le réseau non sécurisé est configuré à la place pour vous envoyer à https://login.flrstoverflowbank.com à la place . Vous ne le remarquerez probablement pas, même si vous prenez le temps de vérifier et que le navigateur affichera tout comme étant sécurisé.

Pour éviter ce genre de chose, créez un signet ou tapez directement l'URL https: //, ne vous fiez jamais à cette redirection.

— Andrew
source