La visite des sites Web HTTPS sur un hotspot public est-elle sécurisée?

Question

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 l'authentification du serveur) donc si quelqu'un renifle mes paquets, il aura besoin de millions d'années pour décrypter s'il utilise une brute force en théorie.

Supposons que je suis sur un wifi public et qu'un utilisateur malveillant sur le même wifi renifle chaque paquet. Supposons maintenant que j'essaie d'accéder à mon compte Gmail en utilisant ce wifi. Mon navigateur effectue une négociation SSL/TLS avec le serveur et obtient les clés à utiliser pour le chiffrement et le déchiffrement.

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

Answer 1

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 chiffrer un secret principal, que le serveur déchiffre ensuite avec sa clé privée. Toutes les données sont cryptées avec une fonction qui utilise le secret principal et les nombres pseudo-aléatoires générés par chaque côté.

Donc,

• les données sont sécurisées car elles sont signées par le maître secret et les numéros pseudo-aléatoires
• le secret principal et les numéros pseudo-aléatoires sont sécurisés car il utilise le chiffrement par clé publique-privée lorsque la négociation TLS se produit
• le cryptage de la clé publique-privée 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 elles sont signées par des certificats racine, qui
  • est venu avec votre ordinateur
  • ou avez été spécifiquement autorisé 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 prenez soin d'autoriser uniquement les certificats auxquels vous faites confiance.

Answer 2

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 "normal". 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/, puis 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, ce qui empêche le lien Email de rediriger vers HTTPS, mais peut-être ailleurs. Par exemple, si vous cliquez sur le lien Email sur la page d'accueil de example.org, remarquerez-vous que cela vous a amené à http://mail.exxxample.org/? (par exemple). Vous pourriez, quelqu'un d'autre pourrait ne pas.
• Si l'utilisateur détourne votre connexion, mais fournit son propre faux certificat SSL à la place de example.org - votre navigateur va afficher une erreur, que le certificat n'est pas valide. Cependant, la plupart des utilisateurs cliqueront simplement dessus, permettant à l'attaquant de MITM d'accéder à 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 pwned sont trop courants et peuvent causer beaucoup plus de dommages sans rapport avec votre SSL.

Answer 3

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

Cependant, lorsqu'ils sont accessibles via HTTPS, de nombreux sites effectuent uniquement l'étape d'authentification via HTTPS, puis redescendent vers 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 chiffrement/déchiffrement nécessite beaucoup de CPU) mais rend le site beaucoup moins sécurisé. Gmail est sûr car il utilise HTTPS pour toute la session, mais Facebook et de nombreux autres sites ne le font pas.

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

Vous pouvez vous protéger contre cette attaque soit en utilisant un VPN pour crypter toutes les données de session, soit en utilisant uniquement des réseaux qui ont un cryptage fort par utilisateur tel que WPA-PSK (WEP utilise la même clé pour chaque utilisateur, et donc pas offrir une protection contre cette attaque).

Answer 4

Étant donné que les réponses semblent être partout (oui, non, pourraient l'être, devraient l'être), permettez-moi de réitérer d'abord la réponse de @ waiwai933: elle est sécurisée.

Pour être précis, vous avez demandé: "Si cet utilisateur malveillant renifle tous mes paquets entrants et sortants. Peut-il calculer les mêmes clés et lire mon trafic crypté aussi ou même envoyer des messages crypté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 a en fait été une percée majeure dans la 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 l'homme du milieu. Le protocole permet à deux personnes qui n'ont jamais échangé d'informations avant 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 crypter votre trafic. Étant donné que 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 trouvés et corrigés de temps en temps. SSL/TLS avait un bogue récent (mentionné dans quelques réponses comme une raison pour laquelle il n'est pas sécurisé), mais il a été à la fois temporairement résolu et maintenant corrigé (RFC 5746) et le correctif est en différentes étapes de déploiement. (Dans votre scénario, le bogue permettait à un utilisateur malveillant d'envoyer des paquets en votre nom mais pas de lire votre trafic.) Il est toujours possible que l'attaquant sache comment casser 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 demande et envoyer sa propre réponse en utilisant son propre certificat. Vérifiez donc le certificat.
• Peut-être un autre point évident: vous ne pouvez être sûr que SSL/TLS sera utilisé pour les pages futures que si la page actuelle est HTTPS. Par exemple, si vous êtes sur une page HTTP qui veut que vous vous connectiez, et d'après votre 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).

Answer 5

Si vous souhaitez naviguer en toute sécurité sur un site via un réseau non sécurisé, les meilleures mesures à prendre pour garantir la sécurité sont les suivantes:

• 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 invalides.

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

Answer 6

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

Answer 7

Dans la 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 :-)

Answer 8

Entièrement, dans la pratique. Le cryptage commence par les personnes root ssl (Verisign, Thawte, etc.) et est donc adapté 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 ont ce problème.

Answer 9

La plupart oublient également l'aspect utilisateur et la façon 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ûrs que gmail HTTPS/SSL auquel vous vous connectez. Problème que je vois de 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 cryptée, espérons que vous avez un VPN auquel vous pouvez vous connecter après cela, ce qui ajoutera une couche de sécurité supplémentaire.

Answer 10

La connexion est assez sécurisée en ce qui concerne les connexions sécurisées (SSL). Pourvu, 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, aucune information sensible ne devrait y être transmise.
• Les serveurs https configurés faibles et les navigateurs obsolètes sont toujours exploitables même sur des sockets sécurisés