Maison / Technologie / Pourquoi envoyons-nous (toujours) autant de trafic Web non crypté sur Internet?

Pourquoi envoyons-nous (toujours) autant de trafic Web non crypté sur Internet?

Crédit image: Bernard Hermant de Unsplash

Nous sommes en 2019 et toujours environ 25% des sites Internet sont visités sans cryptage. Voyons pourquoi.

Ceci est la deuxième partie d'une série en trois parties sur l'insécurité du Wi-Fi public. Dans la partie 1, J'ai montré comment facilement, même aujourd’hui, un pirate informatique pourrait victimiser les utilisateurs de réseaux Wi-Fi publics. je créé un outil pour avoir un aperçu de la prévalence d'activités potentiellement peu sûres sur le réseau Wi-Fi public et comparer les résultats à un rapport similaire de Google.

Les résultats ont toujours été sombres: environ un quart des visites sur le site Web se font sans l'utilisation du protocole HTTPS.

J'étais curieux de savoir pourquoi il y avait autant de trafic sur HTTP HTTP non chiffré, mais cela nécessitait en fait d'inspecter les paquets à un niveau plus profond. J’ai décidé que la prison n’avait pas l'air amusante; alors, de retour chez moi, j'ai installé un petit laboratoire de capture de paquets pour capturer, puis inspecter en profondeur mon trafic personnel à l'aide de Wireshark pour voir si cela éclairerait vraiment la situation.

Voici ce que j'ai trouvé.

RÉSUMÉ

  • Une grande partie du trafic Web reste non crypté – sans raison valable
  • Les sites Web populaires, y compris google.com, netflix.com et certaines grandes institutions financières, définissent de manière incorrecte les en-têtes HTTP liés à la sécurité, exposant ainsi potentiellement les utilisateurs à des attaques de type "man-in-the-middle"
  • Le DNS mine encore les tentatives de sécurisation d'Internet
  • La chaîne de confiance d’Internet est très complexe à mettre en œuvre correctement

Les sites Web populaires ne sont pas assez stricts à propos du HTTPS

Avec certains onglets de navigateur Web ouverts et déjà connectés à des services (courrier électronique, médias sociaux, banque), mon trafic semblait plutôt sécurisé, avec seulement un paquet HTTP initial lorsque je me connectais à mon réseau de test (généré par mon système d'exploitation). tester et voir s’il se trouvait ou non derrière un portail captif). Aucun mal à sonder le réseau en utilisant HTTP (autre que de révéler mon système d'exploitation à toute personne espionnant sur ce réseau spécifique).

La prochaine chose à tester était de savoir ce qui se passerait si je fermais un onglet, puis tentais de revenir sur un site Web que j'avais déjà visité via HTTPS. Mon navigateur saurait-il automatiquement envoyer tout le trafic via HTTPS même si je ne l’avais pas spécifié «https: //» au début de l’URL? C’est ce qui devrait se produire si les sites Web appliquent correctement la stratégie HSTS (HTTP Strict Transport Security), qui est aussi simple qu’utiliser une redirection 301 pour passer de HTTP à HTTPS, puis répondre via HTTPS avec un en-tête HTTP spécial Strict-Transport-Security.

Lorsque j'ai ouvert un nouvel onglet et tapé "google.com" (en omettant intentionnellement "https: //"), je m'attendais à ce que la stratégie HSTS s'active et force automatiquement HTTPS avant de lancer même un paquet sur HTTP en texte brut.

Google, l'un des sites Web les plus visités au monde, doit implémenter correctement le HSTS, n'est-ce pas?

Nan.

Je suis entré sur «netflix.com» et je pensais que la politique HSTS entrerait en vigueur.

Nan.

Frénétiquement, j'ai visité un site Web de banque populaire, fermé l'onglet, ouvert un nouvel onglet et essayé. J'ai essayé quelques sites Web populaires supplémentaires.

Nan. Nan. Nan. Nan.

J'ai testé à la fois Firefox et Chrome et obtenu les mêmes résultats, mais j'ai ensuite remarqué «accounts.google.com». fait appliquer la politique HSTS. C’est ce qui m’a frappé: HSTS n’est (parfois) appliqué que pour les sous-domaines et non pour les domaines parents des sites Web populaires.

J'ai confirmé que «www.google.com» et «www.netflix.com» ne passent jamais par HTTP, pas plus que la racine «github.com». (bon travail, Github, d'avoir fait le bon choix!) révélant que les navigateurs appliquent correctement les stratégies HSTS, mais…

… Une majorité de sites Web populaires, y compris Google et Netflix, définissent des stratégies HSTS uniquement pour les sous-domaines et non leurs domaines parents, ou ne définissent pas du tout HSTS.

Cela compromet tout l'intérêt du HSTS, ce qui conduit à un trafic non chiffré et à la création d'un vecteur d'attaque facile sur tout réseau partagé ou public.

Les sites Web populaires qui ne parviennent pas à appliquer la sécurité de transport stricte HTTP pour les domaines racine, exposant potentiellement les visiteurs à des attaques de type intermédiaire (à compter de mars 2019)

Un test simple pour voir si HTTP Strict Transport Security est appliqué:

1. Sélectionnez l'onglet Réseau dans les outils de développement sur Chrome, puis entrez l'URL que vous avez déjà visitée (sans le "https: //").

2. Si vous obtenez le statut 307 avec l'en-tête de réponse «Motif non-faisant autorité: HSTS», la sécurité du transport HTTP strict est appliquée. S'il existe un autre type de redirection en tant que première redirection, il ne l'est pas.

Excellent travail, Github! Vous avez correctement implémenté HTTP Strict Transport Security!

OK, donc, cela ne peut pas expliquer tout le trafic HTTP non sécurisé signalé par mon outil d'analyse, mais il est extrêmement préoccupant de savoir que les sites Web qui doivent uniquement être accessibles via HTTPS, y compris ceux qui tentent de mettre en œuvre des stratégies HTTPS strictes, ne sont pas configurés. correctement. Cela signifie que les utilisateurs qui n’inspectent pas avec soin les certificats HTTPS et les URL risquent de subir des attaques par hameçonnage (MITM). Pas de bueno.

Mais HSTS n’est pas non plus infaillible.

Rappelez-vous le port UDP 123 à partir des statistiques de Partie 1 de cette série? Ce protocole est utilisé par le protocole NTP (Network Time Protocol) et n’est ni chiffré, ni vérifié. HSTS demande aux navigateurs Web de se souvenir des stratégies HSTS jusqu’à l’expiration du délai imparti. Toutefois, il est possible d’altérer les horloges de chacun en effectuant simplement une attaque NTP MITM.

Cela signifie qu’en un simple piratage du temps, il est possible d’effectuer une Attaque par stripping TLS / SSL même pour les sites Web qui implémentent le HSTS.

Sur une note séparée, l’utilisation du HSTS pose également de graves problèmes de confidentialité. Les agences disposant de ressources importantes et souhaitant suivre les comportements en ligne des individus peuvent exploiter le HSTS de la même manière que les supercookies.

DNS signifie «dinosaure»

Ce problème provient du système de noms de domaine (DNS). Le DNS est efficace, mais c’est terriblement peu sûr et tout le monde le sait depuis des décennies. Par exemple:

  • Il n'y a aucune vérification que les réponses d'adresse IP reçues via DNS sont réellement envoyées par nos serveurs DNS souhaités et non par un attaquant intransigeant.
  • Il n'y a pas de cryptage des recherches DNS
  • Il n’existe pas non plus de lien entre les entrées DNS et le chiffrement du serveur Web. (la seule exception étant DomainKeys pour réduire le courrier indésirable spoofé, je suppose)Il est donc possible d'usurper les réponses DNS pour pointer vers des serveurs néfastes et d'exploiter le fait que les stratégies HSTS ne sont pas toujours configurées correctement.

Passons à la technique pendant une seconde: Je ne veux pas que la foule anti-DNSSEC m'épouvante, alors je vais faire mon devoir de diligence et mentionner que je ne dis PAS que je soutiens le protocole actuel de DNSSEC et je suis tout à fait conscient qu'il y a un nombre d'efficacité et de maux de tête administratifs préoccupations avec DNSSEC/DANOIS. J'aime même l'idée de Identification de clé publique HTTP et connaître ses vertus, et encore l'épinglage clé est maintenant mort et la TVH ne suffit pas à protéger le public.

Donc, ce que je suis en train de dire est ceci:

Nous sommes en 2019 et nous utilisons toujours l’ancien système DNS non sécurisé et (malgré des techniques comme HSTS), les personnes sont encore pratiquement vulnérables de manière très évitable.

Je suis un technologue, alors permettez-moi de demander à mes collègues technologistes ceci: Qu'est-ce qui ne va pas avec la technologie et ses praticiens (nous) que nous n’avons pas mis en œuvre de solution à cela, et pourquoi cela pose-t-il toujours un problème? Réparons Internet ensemble! Cela touche une discussion complexe connue sous le nom de problème de sécurité utilisableMais continuons d’avoir cette discussion et donnons la priorité à l’amélioration de l’efficacité de la technologie pour les utilisateurs.

https://medium.com/media/09c31e45cae7ce20fd2317f2c321b0a5/href

Pourquoi n’avons-nous pas encore réparé Internet?

J'aurais besoin de plus d'espace que cet article pour couvrir pleinement la question «Pourquoi?», Mais je dirai que la façon dont nous sommes arrivés ici est (au moins) triple:

  1. Des cauchemars de gestion existent: Le repérage des clés était compliqué par le fait que les clés / certificats de chiffrement devaient être changés de temps en temps et que la gestion de tels problèmes posait un problème considérable (outils peu fiables pour les administrateurs système) avec les outils actuels – à tel point que le repérage des clés est maintenant en cours. obsolète et complètement abandonné
  2. Une connaissance approfondie et une précision sont nécessaires: La sécurité est difficile à toujours mettre en œuvre correctement
  3. Nous sommes paresseux(?): Puisqu'il y a un possible chemin où les gens pourrait surfer sur le Web en toute sécurité (même s’il est difficile pour les gens normaux et les sites Web de le faire systématiquement), nous avons perdu le sens de l’urgence de tout extraire et de recommencer (et / ou nous sommes vraiment stupides)

Il y a aussi d'autres raisons, mais la morale de l'histoire est que c'est totalement évitable, mais on ne peut toujours pas l'éviter, et c'est tout. vraiment foiré si vous y réfléchissez.

Dans Internet nous faisons confiance

Tout cela est encore compliqué par le fait qu’aujourd’hui, le cryptage sur Internet repose toujours sur la précision des autorités centralisées de confiance, les autorités de certification (CA), afin de valider l’authenticité des clés de cryptage utilisées lors de la première poignée de main qui a lieu entre clients / navigateurs et serveurs. Pour aggraver les choses, les algorithmes qui seront utilisés pour établir la confidentialité sont entièrement variables, déterminés lors de la prise de contact initiale, et le Web est jonché de clients et de serveurs avec une combinaison inadéquate d’algorithmes et de versions moins / plus sécurisés (simultanément) ( c'est pourquoi l'article de TLS est peut-être le article le plus long et le plus laid sur toute la Wikipedia).

TLS est tout sauf standard et ne doit pas être approuvé.

Tout d’abord, lors de la première prise de contact, un client «Alice» (un navigateur Web, par exemple) qui souhaite communiquer en toute sécurité avec une autre entité «Bob» (un serveur Web) doit s’entendre avec lui sur la définition des «communications sécurisées». canal "est même. Ensuite, pour qu'Alice établisse ce canal sécurisé avec Bob (appelons-le canal 1), Alice doit d’abord utiliser un autre canal sécurisé avec Bob (canal 2) pour échanger des clés afin de chiffrer le canal 1; mais, pour savoir que le canal 2 est sécurisé, Alice valide d’abord (sur le canal 3) auprès de l’autorité de certification «Val» pour s’assurer qu’une oreille indiscrète «Eve» n’est pas déguisée en Bob.

Donc, pour qu'Alice puisse croire que les communications avec Bob sont sécurisées d'Eve, Alice doit avoir confiance en ce que Bob n'est ni stupide ni fainéant et que Val n'est pas la NSA en plus de faire confiance aux protocoles utilisés pour créer les canaux 1, 2 et 3.

Ceci est connu comme une chaîne de confiance. Mais, qui regarde les observateurs? La solution à Ne fais confiance a personne?

L'absence de confiance est le seul moyen d'avancer.

Nous avons besoin d'un Internet dit «sans confiance», doté d'une confidentialité et d'une sécurité qui fonctionnent fondamentalement différemment de ce qu'il est aujourd'hui. Mais contrairement au paradigme de la sécurité «sans confiance», il ne s’agit pas vraiment d’éliminer complètement la confiance; il s’agit plutôt de minimiser l’ampleur des risques résultant de la confiance: faire confiance aux Moins. C’est parce que notre problème de sécurité et de confidentialité sur Internet n’est-ce pas que nous avons confiance choses / personnes, le problème est que nous ne savons pas qui ne pas faire confiance ou quand, et nous ne savons pas toujours avec quelle information nous leur confions. (Après tout, nous faisons confiance à beaucoup de choses et de personnes chaque jour de notre vie, y compris le fait que la nourriture que nous mangeons ne nous empoisonnera pas et que les avions dans lesquels nous volons ne s’écraseront pas.)

Il existe d'autres paradigmes que la chaîne de confiance utilisée sur Internet aujourd'hui. Par exemple, le web / réseau de confiance Les paradigmes créent un modèle de confiance décentralisé / distribué qui élimine les points de défaillance uniques. (Le problème avec une chaîne de confiance est que chaque lien est un point d'échec unique, de sorte que chaque lien augmente un multiplicateur pour la probabilité d'échec au lieu d'augmenter un diviseur.) Néanmoins, les solutions utilisant ces paradigmes ne sont pas encore prêtes. prime time.

Conclusion

À l'avenir, Internet aura adopté un paradigme de sécurité sans confiance, qui permettra de réduire les risques et d'accroître la transparence, la responsabilité et l'audit. Nous ferons confiance aux systèmes et aux politiques (virtuelles), fondés sur des assurances vérifiables et vérifiables du point de vue mathématique, et la noirceur sera éclairée et exposée. Les institutions seront remplacées par les communautés, alignées sur des algorithmes de consensus. Cela se produit aux niveaux les plus élevés de la pile de protocoles Internet, avec des systèmes conçus pour remplacer notre mode de gouvernance, notre mode de transfert de richesse, etc., mais il reste encore beaucoup à faire aux niveaux inférieur, permettant l'accès et le transport d'applications.

Un cryptage efficace est-il tout ce dont nous avons besoin? Absolument pas. Mais Internet est construit sur des systèmes de confiance et tous les paradigmes de confiance dépendent, d’abord, de l’établissement d’un canal sécurisé via un cryptage infaillible. L'intégrité des chaînes dépend non seulement de leur maillon le plus faible, mais des canaux sûrs et fiables constituent la physique fondamentale qui maintient l'un des liens entre eux en premier lieu. De même, un réseau / réseau de confiance sonore doit être basé sur des mathématiques saines.

Sur mon boulot, la magie, nous travaillons activement à la résolution de ces problèmes en mettant en œuvre par défaut une fonctionnalité de type VPN et une sécurité pour Internet basée sur des fonctionnalités.

Pour en savoir plus et participer à la discussion sur la manière de construire un Internet plus sûr et plus performant, consultez magic.co ou https://github.com/magic-network

Mais, c'est où nous sommes aujourd'hui. Les solutions sont à portée de main et sont même connues, mais elles attendent les développeurs. C'est pourquoi vous devriez avoir peur d'utiliser le Wi-Fi public (ou tout réseau partagé) aujourd'hui. C’est pourquoi vous devez toujours utiliser le plug-in de navigateur HTTPS Everywhere et toujours utiliser un VPN réputé. Dans la troisième partie de cette série, je vais aborder la longue liste de tout ce qui est nécessaire pour surfer sur le Web en toute sécurité à l’heure actuelle.


Pourquoi envoyons-nous (toujours) autant de trafic Web non crypté sur Internet? a été publié à l'origine dans Hacker midi sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.

Source

A propos newstrotteur-fr

Découvrez également

Alex Kurtzman parle de l’avenir de la franchise STAR TREK et de la préservation de la fraîcheur et de la nouveauté – Newstrotteur

Sur le récent épisode du podcast de Deadline Appel d’équipage, Star Trek: Découverte producteur exécutif, …

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *