Question:
La visite de sites Web HTTPS sur un hotspot public est-elle sécurisée?
Calmarius
2011-01-09 16:31:42 UTC
view on stackexchange narkive permalink

On dit souvent que les connexions HTTPS SSL / TLS sont cryptées et dites sécurisées parce que la communication entre le serveur et moi est cryptée (fournit également une authentification du serveur) donc si quelqu'un renifle mes paquets, il leur faudra des millions d'années pour les décrypter si vous utilisez la force brute en théorie.

Supposons que je sois sur un wifi public et qu'il y ait un utilisateur malveillant sur le même wifi qui renifle chaque paquet. Supposons maintenant que j'essaie d'accéder à mon compte Gmail en utilisant ce wifi. Mon navigateur effectue une poignée de main SSL / TLS avec le serveur et obtient les clés à utiliser pour le cryptage et le décryptage.

Si cet utilisateur malveillant a reniflé tous mes paquets entrants et sortants. Peut-il calculer les mêmes clés et lire mon trafic chiffré ou même envoyer des messages chiffrés au serveur en mon nom?

Je pense que c'est approprié, car la compréhension des risques d'un tel environnement est du ressort des professionnels de la sécurité. Certains d'entre nous ont dû gérer des points d'accès publics au sein de sites d'entreprise, et d'autres doivent travailler à partir de divers endroits - qui peuvent inclure des points d'accès publics.
Et sslstrip? (http://www.thoughtcrime.org/software/sslstrip/)Voir également [cette vidéo] (http://bit.ly/1BylXv) à propos de sslstrip
Pour ajouter aux réponses ci-dessous [cela dépend de la sécurité du site Web que vous visitez] (http://security.stackexchange.com/a/80363/8340) - [voir également mes conseils ici] (http: // sécurité .stackexchange.com / a / 44976/8340).
Notez que si les sites HTTPS peuvent être sécurisés dans ce scénario, si à un moment quelconque de votre session de navigation un site HTTP est chargé (même dans un iframe ou un onglet séparé), un hotspot malveillant peut en tirer parti pour voler vos cookies sur _all_ populairesites non HTTPS (même ceux que vous ne naviguez pas actuellement), et installez des portes dérobées pour les sites qui persistent même après que vous n'êtes plus connecté au hotspot malveillant: https://samy.pl/poisontap/ Donc voilà.
Onze réponses:
#1
+110
waiwai933
2011-01-09 16:51:24 UTC
view on stackexchange narkive permalink

HTTPS est sécurisé sur les hotspots publics. Seules une clé publique et des messages chiffrés sont transmis (et ceux-ci sont également signés par des certificats racine) lors de la configuration de TLS, la couche de sécurité utilisée par HTTPS. Le client utilise la clé publique pour crypter un secret principal, que le serveur décrypte ensuite avec sa clé privée. Toutes les données sont cryptées avec une fonction qui utilise le secret principal et des nombres pseudo-aléatoires générés par chaque côté.

Ainsi,

  • les données sont sécurisées car elles sont signées par le secret principal et les nombres pseudo-aléatoires
  • le secret principal et les nombres pseudo-aléatoires sont sécurisés car il utilise le cryptage par clé publique-privée lors de la négociation TLS
  • la clé publique-privée le chiffrement est sécurisé car:
    • les clés privées sont gardées secrètes
    • le chiffrement par clé publique-privée est conçu pour être inutile sans la clé privée
    • les clés publiques sont connues pour être légitimes car ils sont signés par des certificats racine, qui soit
    • fournis avec votre ordinateur
    • soit ont été spécifiquement autorisés par vous (faites attention aux avertissements du navigateur!)

Ainsi, vos connexions et données HTTPS sont sécurisées tant que:

  1. vous faites confiance aux certificats fournis avec votre ordinateur,
  2. vous veillez à n'autoriser que les certificats auxquels vous faites confiance.
Oh, j'ai oublié que nous avons des systèmes de cryptage asymétriques.
3. Vous vous assurez que toutes vos données passent réellement par HTTPS (certains sites sont partiellement cryptés et partiellement non)
Mes piscines locales (Hillingdon, Royaume-Uni) renvoient leurs propres certificats, donc ayez une vue complète de ce que vous envoyez, même si le https est affiché.99,9% des utilisateurs ne le remarqueraient pas.
Question: Pouvez-vous clarifier comment toute réponse du serveur HTTPS pourrait être chiffrée de telle sorte que quelqu'un qui écoute au milieu ne puisse pas l'interpréter?La seule clé dont dispose le client est la clé publique qui est également disponible pour l'auditeur / pirate informatique.
@JoshG Le client dispose également d'une clé privée, dont il est le seul à connaître.C'est l'essence du chiffrement asymétrique (paire de clés publique / privée).Pour déchiffrer une réponse du serveur, un homme au milieu aurait besoin de la clé privée du client.
#2
+48
AviD
2011-01-11 12:37:30 UTC
view on stackexchange narkive permalink

Réponse courte: cela dépend.

SSL / TLS lui-même n'est pas plus vulnérable sur une connexion wifi publique que sur Internet "ordinaire". Il a été conçu pour être utilisé dans des canaux ouverts.

Cependant, il y a quelques autres aspects à considérer:

  • Souvent, les utilisateurs ne naviguent pas directement sur le site HTTPS, ils commencent sur le site HTTP et redirigent à partir de là . Par exemple, vous accédez à http://example.org/ et cliquez sur le lien Email , qui vous redirige vers https://mail.example.org/ . Étant donné que la page HTTP d'origine n'est pas chiffrée, cet utilisateur malveillant peut modifier votre trafic, provoquant la redirection du lien Email vers HTTPS, mais peut-être ailleurs. Par exemple, si vous avez cliqué sur le lien E-mail sur la page d'accueil de example.org, remarqueriez-vous que cela vous a amené à http://mail.exxxample.org/ ? (par exemple). Vous pourriez, quelqu'un d'autre pourrait ne pas le faire.
  • Si l'utilisateur détourne votre connexion, mais fournit son propre faux certificat SSL au lieu de celui d'exemple.org, votre navigateur le fera affiche une erreur, que le certificat n'est pas valide. Cependant, la plupart des utilisateurs cliqueront simplement dessus, permettant à l'attaquant de MITM sur votre site sécurisé, via SSL.
  • Un autre aspect à considérer, ne supposez pas que le hotspot public est configuré de manière sécurisée. Comme cette question le montre, les routeurs connectés sont trop courants et peuvent causer beaucoup plus de dommages sans rapport avec votre SSL.
Tous les sites Google sont édités par HSTS. Mieux vaut utiliser «example.org».
@Pacerier ouais, * maintenant *, ne l'était pas :-) Aussi leurs certificats sont principalement épinglés (c'est mon 2ème point), donc ... ouais. Merci!
#3
+22
Alex Howell
2011-01-09 17:11:23 UTC
view on stackexchange narkive permalink

Une session entièrement via HTTPS est assez sûre, car toutes les requêtes du navigateur et les pages transmises par le serveur sont cryptées.

Cependant, lorsqu'ils sont accédés via HTTPS, de nombreux sites n'effectueront que l'étape d'authentification via HTTPS, puis revenez à HTTP pour le reste de la session. Ainsi, votre mot de passe lui-même est sûr, mais l'ID de session utilisé par le serveur pour vous identifier pour cette session est transmis en clair par votre navigateur. Cela réduit la charge sur le serveur Web (car le cryptage / décryptage est gourmand en CPU) mais rend le site beaucoup moins sécurisé. Gmail est sûr car il utilise HTTPS pendant toute la session, mais pas Facebook et de nombreux autres sites.

C'est ainsi que des outils tels que Firesheep peuvent détourner les comptes des utilisateurs lorsque un attaquant partage un réseau sans fil non chiffré.

Vous pouvez vous protéger contre cette attaque soit en utilisant un VPN pour chiffrer toutes les données de session, soit en utilisant uniquement des réseaux dotés d'un chiffrement fort par utilisateur, comme WPA -PSK (WEP utilise la même clé pour chaque utilisateur, et n'offre donc pas de protection contre cette attaque).

Autant que je sache, [WPA-PSK n'est pas une défense efficace contre les attaques de type Firesheep] (http://www.kennynet.co.uk/2010/11/26/ubuntu-firesheep-aircrack-and-wpa/ ). Je crois comprendre que [aircrack-ng peut déchiffrer le cryptage WPA-PSK] (http://www.aircrack-ng.org/doku.php?id=airdecap-ng), si vous capturez la poignée de main initiale, ce qui est facile à faire. WPA-PSK n'est [pas sécurisé contre ce type d'attaques] (http://wifinetnews.com/archives/2003/11/weakness_in_passphrase_choice_in_wpa_interface.html) et [fournit un faux sentiment de sécurité] (http: //wiki.wireshark. org / HowToDecrypt802.11).
De plus, cette réponse ignore le risque d'attaques MITM (attaques actives). Firesheep ne mène actuellement pas d'attaques MITM, mais il le pourrait, et il peut y avoir des risques même si le site utilise exclusivement HTTPS. (par exemple, s'il ne marque pas ses cookies avec l'indicateur SECURE.)
@D.W., Merci - c'est pourquoi j'ai suggéré de déplacer la question originale de superuser.com vers ici - cette question venait de là, pas d'un "gars de la sécurité". Btw, lorsque vous voyez de mauvaises réponses, en particulier des réponses qui sont explicitement FAUX, vous devriez les voter contre. Cela aide à faire flotter les bonnes réponses vers le haut et à couler les mauvaises.
Il vaut probablement la peine de noter que ce n'est plus le cas que le "cryptage / décryptage" soit intensif en CPU. Il est important de ne pas perpétuer le mythe selon lequel la charge du processeur vaut la peine d'être prise en compte lorsque vous envisagez d'utiliser HTTPS sur toutes les parties de votre site Web. voir: https://istlsfastyet.com/
#4
+13
PulpSpy
2011-01-13 05:06:37 UTC
view on stackexchange narkive permalink

Puisque les réponses semblent être partout (oui, non, peut-être, devrait l'être), permettez-moi de répéter d'abord la réponse de @ waiwai933: c'est sécurisé.

Pour être précis, vous avez demandé : "Si cet utilisateur malveillant a reniflé tous mes paquets entrants et sortants. Peut-il calculer les mêmes clés et lire mon trafic chiffré aussi ou même envoyer des messages chiffrés au serveur en mon nom?" La réponse est non et non. Avec une note de bas de page.

La raison pour laquelle il ne peut pas calculer les mêmes clés semble paradoxale, et c'était en fait une percée majeure en cryptographie lors de sa première publication par Diffie et Hellman. TLS utilise un protocole d'échange de clés, comme Diffie-Hellman, mais plus sophistiqué pour se protéger des attaques de type "man-in-the-middle". Le protocole permet à deux personnes qui n'ont jamais échangé d'informations auparavant de calculer une clé secrète que personne ne voyant tous les messages ne peut calculer.

Une fois que vous avez une clé secrète partagée, vous pouvez l'utiliser pour chiffrer votre trafic. Puisque l'utilisateur malveillant ne connaît pas la clé, il ne peut pas chiffrer le trafic qui semble provenir de vous.

Maintenant, ces notes de bas de page.

  • Nous supposons que le protocole SSL / TLS est correct. Avec la plupart des protocoles cryptographiques impliqués, des bogues sont détectés et corrigés de temps en temps. SSL / TLS a eu un bogue récent (mentionné dans quelques réponses comme une raison pour laquelle il n'est pas sécurisé), mais il a été temporairement contourné et maintenant corrigé (RFC 5746) et le correctif est disponible. différentes étapes de déploiement. (Dans votre scénario, le bogue permettait à un utilisateur malveillant d'envoyer des paquets à votre nom mais pas de lire votre trafic.) Il est toujours possible que l'attaquant sache comment interrompre TLS / SSL en raison d'une erreur non publiée dans le protocole.
  • Un point évident mais qui mérite d'être répété: l'utilisateur malveillant pourrait voir votre requête et envoyer sa propre réponse en utilisant son propre certificat. Alors vérifiez le certificat.
  • Peut-être un autre point évident: vous ne pouvez être sûr que SSL / TLS sera utilisé pour les pages futures si la page actuelle est HTTPS. Par exemple, si vous êtes sur une page HTTP qui souhaite que vous vous connectiez, et de l'expérience passée, vous savez que cliquer sur le bouton de connexion vous redirigera vers une connexion HTTPS, cette fonctionnalité pourrait être supprimée par un utilisateur malveillant actif sur votre réseau. Donc, connectez-vous uniquement aux pages qui sont déjà HTTPS (sauf si vous savez comment détecter si la page de connexion a été modifiée).
#5
+2
RedGrittyBrick
2011-01-09 16:51:55 UTC
view on stackexchange narkive permalink

HTTPS est assez résistant au décryptage du reniflage de paquets. Cependant, le côté authentification du serveur dépend d'une méthode quelque peu faible de distribution des certificats d'autorité de certification et les autorités de certification ne font pas grand-chose en termes de vérification des identités. Il y a quelques années, un certificat Microsoft a été délivré à un imposteur. Voir l ' article de Bruce Schneier sur le sujet - en pratique, pour les sites Web grand public, nous n'avons rien de mieux.

Les certificats non valides sont un problème sur tous les types de connexion - pas seulement sur un point d'accès WI-FI public.
Richard a raison, il n'y a rien de spécial dans les points d'accès Wi-Fi publics concernant les certificats. J'ai trouvé que cela valait la peine d'être mentionné car cela s'applique également là-bas. Un opérateur de hotspot non autorisé pourrait vous rediriger vers son propre serveur Web à l'aide d'un certificat frauduleux.
mais les certificats invalides et le MITM présentent beaucoup plus de risques sur le wifi public
#6
+2
Rory Alsop
2011-01-09 20:25:06 UTC
view on stackexchange narkive permalink

En pratique, SSL et TLS ont tous deux des problèmes, mais ils concernent le type d'attaque Man In the Middle. Pour un exemple de problème de renégociation TLS MITM voir ici

Bien sûr, cette attaque nécessite que l'attaquant soit au milieu du chemin de communication, ce qui limite un peu la menace :-)

#7
+2
D.W.
2011-01-12 08:02:56 UTC
view on stackexchange narkive permalink

Si vous craignez de naviguer en toute sécurité vers un site sur un réseau non sécurisé, les meilleures mesures à prendre pour assurer la sécurité sont:

  • Assurez-vous que le site utilise HTTPS , pas HTTP.

  • Assurez-vous que le site dispose d'un certificat valide. Ne cliquez pas sur les avertissements. N'acceptez pas les certificats non valides.

  • Utilisez HTTPS Everywhere ou Force-TLS pour vous assurer que vous utilisez un HTTPS (c'est-à-dire, une connexion cryptée SSL) pour tout ce qui concerne ce site.

#8
+1
tobylane
2011-01-09 16:49:26 UTC
view on stackexchange narkive permalink

Entièrement, dans la pratique. Le cryptage commence avec les personnes root ssl (Verisign, Thawte, etc.) et convient donc aux lignes non sécurisées. AFAIK TLS n'a pas de problème avec les attaques de l'homme au milieu, ses seules poignées de main plus faibles / plus anciennes qui posent ce problème.

TLS est sensible au MITM
#9
+1
IrqJD
2011-01-09 23:44:02 UTC
view on stackexchange narkive permalink

La plupart oublient l'aspect utilisateur et la manière dont ils pourraient également utiliser ce PC sur le hotspot. La plupart des gens utilisent des mots de passe similaires sur d'autres sites, peuvent bloguer, etc. ceux-ci peuvent ne pas être aussi sécurisés que le gmail HTTPS / SSL auquel vous vous connectez. Problème que je vois à partir de la sécurité, la plupart des gens vont sur d'autres sites exposer un programme de reniflage de paquets avec suffisamment d'informations pour accéder à certains de vos comptes. Le mieux est comme mentionné si vous utilisez une connexion sans fil non chiffrée, j'espère que vous aurez un VPN auquel vous pourrez vous connecter après cela, qui ajoutera une couche supplémentaire de sécurité.

#10
  0
Arjun sharma
2016-10-24 16:37:08 UTC
view on stackexchange narkive permalink

La connexion est assez sécurisée en ce qui concerne les connexions sécurisées (ssl). À condition, s'il est utilisé avec conscience:

  • Il ne devrait pas y avoir de redirection de HTTPS vers HTTP
  • Certains sites utilisent également HTTP cmd sur les pages HTTPS, il ne devrait pas y avoir toute information sensible transmise par-dessus
  • Les serveurs https faiblement configurés et les navigateurs obsolètes sont toujours exploitables, même sur des sockets sécurisés
#11
-1
FrostyFire
2017-12-06 07:59:51 UTC
view on stackexchange narkive permalink

La réponse de tri est, pour autant que nous le sachions, si HTTPS est correctement configuré, vous êtes sécurisé 99% du temps. C'est un gros si. Ce n'est pas aussi simple que de simplement voir HTTPS dans votre navigateur. SSL-Strip fonctionne toujours sur certains sites / navigateurs sécurisés.

N'oublions pas qu'avant SSL-Strip, personne ne pensait qu'un tel outil pouvait fonctionner. La cybersécurité est un domaine en constante évolution et un jeu de whak-a-mole pour ainsi dire. Un nouvel exploit sortira à un moment donné qui vous permettra de faire l'attaque que vous mentionnez sur n'importe quel site. Regardez la norme WPA2 "incassable". Pas si incassable après tout. Il sera corrigé mais il ne fait pas grand-chose pour les personnes piratées avant.

Actuellement, il existe un moyen de décrypter le trafic SSL correctement configuré. Cela nécessite d'accéder à une autorité de certification et d'émettre des certificats entièrement fiables. Votre navigateur ne détectera pas une attaque MiTm utilisant cela. La bonne nouvelle est qu'il est extrêmement difficile à réaliser ... pour l'instant. L'utilisation d'un VPN ne garantit pas la sécurité car le VPN lui-même pourrait être l'attaquant de Mitm.

Fondamentalement, tout ce qui est en ligne peut et sera à un moment donné piraté. Il y a des choses que vous pouvez faire (VPN, navigateur mis à jour, etc.) pour minimiser le risque, mais vous n'êtes jamais sûr à 100%. Ne laissez personne vous dire le contraire.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...