Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

SHA alors, quelle hécatombe

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

03/04/2020 18 minutes
17

Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

Dans le numérique et sur Internet, la confidentialité et la sécurité des données vont de pair avec les protocoles de chiffrement. Ces derniers évoluent au fil des années, mais également des découvertes des chercheurs, passant parfois en un certain temps de parfaitement sécurisés à véritables passoires.

Il existe deux grandes familles de protocoles de chiffrement qui ont marqué notre quotidien depuis les années 1990 : WEP et WPA pour les connexions sans fil, SSL et TLS pour la navigation sur Internet. Dans les deux cas, des algorithmes qualifiés de robustes à une certaine époque ne le sont plus du tout aujourd’hui.

Le WEP (Wired Equivalent Privacy) a été mis en place en 1999, en même temps que les premières normes 802.11a et 802.11b du Wi-Fi. Ce protocole ne sera pas resté bien longtemps en place puisqu’il a été possible de retrouver le mot de passe sécurisant la connexion... dès le début de l’année 2000.

Il fallait alors « écouter » une quantité importante de trafic (chiffré) pour ensuite casser la clé WEP, ce qui pouvait facilement prendre plusieurs heures.

En revanche, les attaques se sont grandement améliorées au fil du temps, ne demandant plus que quelques minutes, voire quelques secondes pour décrypter un mot de passe (pour rappel, on parle de déchiffrer lorsque la clé est connue). Bref, du WEP ou rien, c’est désormais presque la même chose. D’où son petit surnom : Weak Encryption Protocol.

Le WPA à la rescousse pour renforcer le WEP...

Une première solution a rapidement été identifiée pour renforcer les connexions sans fil : Wi-Fi Protected Access (WPA). Son développement a commencé en 2000, mais les certifications et sa mise en place obligatoire sur les produits Wi-Fi n’ont débuté qu’en 2003, alors que le WEP était déjà défaillant depuis plusieurs années. On trouve le WPA Personnel pour les particuliers et les PME d’un côté, puis la déclinaison Entreprise de l’autre.

Le premier repose sur l’utilisation d’un mot de passe partagé, ou PSK (Pre-Shared Key), entre tous les utilisateurs pour l’authentification. C’est le plus courant et on le retrouve notamment sur les box des FAI, modems et routeurs grand public. Le second exige un serveur qui identifie chaque utilisateur de manière différente et s’appuie sur le protocole EAP (Extensible Authentication Protocol). Plusieurs variantes sont disponibles : EAP-MD5,LEAP, EAP-TLS, EAP-TTLS, PEAP, etc.

L’ANSSI insiste sur la différence fondamentale entre ces deux approches : « Un abonné à un réseau Wi-Fi protégé par WPA-PSK peut très simplement intercepter les données échangées par un autre abonné de ce même réseau. L’utilisation de WPA-PSK ne permet donc pas de garantir la confidentialité des flux entre terminaux connectés à un même réseau Wi-Fi. En environnement professionnel, EAP reste alors à privilégier. »

L’Agence nationale de la sécurité des systèmes d’information ajoute que le WPA introduit le protocole TKIP (Temporal Key Integrity Protocol) qui intègre un chiffrement par paquet et un renouvellement automatique des clefs de chiffrement. « L’algorithme sous-jacent est toujours le RC4 utilisé avec des clefs de 128 bits, mais contrairement au WEP, il est utilisé plus correctement », précise l’agence.

Wi-Fi Sans fil
Crédits : shutter_m/iStock/Thinkstock

... mais succombe en 2008 : WPA2 prend la relève

En 2008, l’attaque d’Erik Tews et de Martin Beck sur le protocole TKIP fait tomber WPA. Heureusement, une solution existait déjà depuis 2004 : WPA2, devenu obligatoire pour obtenir une certification Wi-Fi en 2006. Cette dernière exploite l’algorithme AES (Advanced Encryption Standard) bien plus robuste.

L’algorithme AES (aussi connu comme Rijndael) est le résultat d’un concours lancé en 1997 par le NIST (National Institute of Standards and Technology). Au total, 16 équipes de cryptologues étaient venues du monde entier pour participer et trouver un remplaçant au DES (Data Encryption Standard).

Le choix d’AES par la Wi-Fi Alliance s’est révélé judicieux puisque cet algorithme n’est toujours pas tombé et reste encore aujourd’hui un standard international réputé et largement utilisé. TKIP est ainsi remplacé par CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) ou WRAP (Wireless Robust Authenticated Protocol), tous deux basés sur AES et résistants aux attaques... du moins pour l’instant. Aujourd’hui encore, les box, routeurs et modems proposent une large panoplie de protocoles pour le Wi-Fi, allant du WEP au WPA2.

Vous l’aurez compris, WEP et WPA doivent être proscrits et il est recommandé de sélectionner WPA2-PSK/AES. WPA2 a vaillamment résisté pendant de nombreuses années, avant de commencer à rendre les armes en 2017 suite à la découverte de la faille KRACK.

Elle concerne aussi bien les protocoles TKIP (avec une gravité accrue) que CCMP, mais des correctifs ont permis de limiter les dégâts– encore faut-il que les fabricants de produits et les éditeurs de systèmes d’exploitation les proposent. Ces derniers ont généralement été rapides à proposer des correctifs, mais dans le cas des smartphones et autres points d’accès, cela dépend du bon vouloir des constructeurs.

Du côté de l’utilisateur, il faut donc vérifier régulièrement la disponibilité des mises à jour de sécurité et les installer autant que possible. Après l’affaire KRACK, l’ANSSI recommandait de « configurer les équipements Wi-Fi pour imposer l’utilisation de WPA2 (et non pas WPA) et AES-CCMP (et non pas TKIP) ; [cela] ne permet pas de se prémunir contre une potentielle écoute d’une communication, mais empêche le vol de la clé de session Wi-Fi ».

Guillaume Poupard, directeur de l’ANSSI, s’alarmait auprès de l’agence AFP : « On va vivre pendant des années avec des Wi-Fi percés[...] On est condamnés à attendre que les mises à jour soient proposées par les différents éditeurs, ce qui laissera la question de tout ce qui ne sera pas mis à jour. »

Cap sur WPA3... non sans mal

Suite à cette brèche béante, la Wi-Fi Alliance a rapidement indiqué qu’une nouvelle version était en préparation. Logiquement baptisée WPA3, elle a officiellement été lancée durant l’été 2018 et est imperméable aux attaques de type KRACK. Le WPA2-PSK laisse ainsi sa place au WPA3-SAE (Simulaneous Authentication of Equals).

« L’authentification SAE permet d’assurer les échanges de clés de manière plus fiable et utilise la confidentialité persistante afin de garantir une protection renforcée contre les attaques de décryptage hors ligne et d’assurer une authentification par mot de passe plus fiable », détaille le constructeur Intel.

Ce n’est pas la seule nouveauté du WPA3. Signalons aussi Easy Connect pour simplifier les connexions d’appareils ne disposant pas d’une interface visuelle, et Enhanced Open pour apporter du chiffrement individualisé sur les réseaux ouverts. Des améliorations qui vont clairement dans le bon sens... Encore faut-il disposer d’appareils compatibles, WPA3 étant encore très peu répandu.

Il n’aura d’ailleurs pas fallu attendre longtemps pour que de premières brèches soient identifiées sur certains produits : un « nombre limité des premières implémentations de WPA3 » sont vulnérables reconnaissait la Wi-Fi Alliance en avril dernier. Attention, il s’agit bien d’implémentations, pas du protocole en lui-même. Comme le veut désormais la coutume, un petit nom a été attribué à cette découverte : DragonBlood.

Heureusement, une mise à jour logicielle permet de boucher ces vulnérabilités. La Wi-Fi Alliance a depuis renforcé sa communication vers les fabricants, mais aussi ses tests en vue de certifier les nouveaux produits Wi-Fi... jusqu’à de nouvelles découvertes, puis WPA4 ?

Dans tous les cas, certains ont un avis bien tranché sur la question, c’est notamment le cas de l’ANSSI qui rappelle que « la simple présence de la technologie Wi-Fi dans un terminal ou un équipement peut suffire à ce qu’il présente des risques de sécurité. Il est donc préférable de se passer de cette technologie lorsqu’elle ne répond à aucun besoin concret ».

Au moins, le message est clair.

De SSL par Netscape à TLS 1.3

Avec l’arrivée d’Internet, il a rapidement fallu faire face à un défi de taille : sécuriser les échanges devant transiter entre un ordinateur et un serveur. Car si certaines données sont anodines, comme le contenu d’une page publique, d’autres le sont beaucoup moins : mots de passe, codes de cartes bancaires, messages privés, etc.

Rapidement, un premier protocole exploitable par le grand public a donc vu le jour : SSL (Secure Sockets Layer). Sa version 1.0 a été développée en interne par Netscape en 1994 ; la première disponible publiquement est la 2.0 en 1995. SSL 3.0 est arrivé dès 1996 afin de combler des lacunes de SSL 2.0, avant de devenir TLS (Transport Layer Security).

L’Agence nationale de la sécurité des systèmes d’information (ANSSI) rappelle qu’il s’agit d’une normalisation par l’IETF (Internet Engineering TaskForce) et que, « fondamentalement, TLS v1.0 peut être considéré comme une version 3.1 de SSL ». Sont ensuite arrivés TLS 1.1 en 2006 et 1.2 en 2008.

Mais il aura fallu attendre dix ans avant d’obtenir la version finale de la norme TLS 1.3 qui peine encore à être déployée. Preuve qu’en matière de sécurité, faire évoluer les normes et protocoles n’est pas suffisant.

Sécurité Cassé Cadenas
Crédits : Павел Игнатов/iStock/Thinkstock

SSL 2.0 et 3.0 sont tombés, TLS résiste

Tout ce petit monde s’est côtoyé pendant des années, avec la recommandation de toujours utiliser la dernière version disponible. Mais nombreux sont encore les services à se reposer sur d’anciennes moutures afin de ne pas mettre de côté des utilisateurs équipés de vieux systèmes d’exploitation et navigateurs. Peu à peu, les règles ont été durcies.

Le premier coup de semonce retentit en 2011 lorsqu’IETF interdit purement et simplement l’utilisation de SSL v2 (lancé en 1995). L’ANSSI explique de son côté que « la vulnérabilité DROWN a révélé que la simple prise en charge de SSLv2 par un serveur était susceptible de compromettre des sessions lancées avec des versions ultérieures du protocole ».

Problème, de nombreux serveurs prenaient toujours en charge SSLv2, en plus de TLS 1.x, pour assurer une rétrocompatibilité, ou plus simplement du fait d’erreurs de configurations (qui sont plus nombreuses qu’on pourrait le croire). Nonobstant, la décision de l’agence française de cybersécurité est sans appel : SSL 2.0 doit bel et bien être banni purement et simplement. Fin 2014, la faille POODLE a fait parler d’elle, signant la mort de SSL 3.0.

Elle est importante puisqu’elle permet de décrypter les informations échangées entre le navigateur et le serveur. L’IETF mettra du temps à réagir officiellement, mais finira par bannir SSL 3.0 en juin 2015. Toutes les versions de TLS résistent pour le moment, même si la plus récente doit au maximum être privilégiée.

L’ANSSI indique que les versions 1.0 et 1.1 « sont tolérées », à condition d’activer la prise en charge de la pseudo-suite cryptographique TLS_FALLBACK_SCSV. Définie pendant l’année 2015 par l’Internet Engineering Task Force (RFC 7507), elle permet de détecter, empêcher et signaler certaines attaques par repli (downgrade attack).

Sur son blog, le spécialiste Stéphane Bortzmeyer explique que « dès qu’un protocole cryptographique a des choix, il y a un risque de sécurité : que l’attaquant tente de perturber la négociation initiale entre les deux parties pour les amener à choisir les variantes les moins sécurisées, en faisant croire à chacun que son partenaire ne peut pas gérer les meilleures variantes ».

Par exemple, un attaquant actif pourrait pousser un client et un serveur à passer en TLS 1.0 alors qu’ils sont tous les deux compatibles avec TLS 1.2. L’objectif de TLS_FALLBACK_SCSV est justement de limiter les ris­ques d’attaque par dégradation de version, « notamment liés aux implémentations tentant d’établir une connexion SSLv3 suite à l’échec des connexions TLS. Suite à un premier échec de connexion, un client qui met en œuvre TLS_FALLBACK_SCSV et souhaite essayer un ClientHello de version dégradée est tenu d’y ajouter la SCSV [Signaling Cipher Suite Value, ndlr] précédente. De cette façon, si un serveur observe la SCSV dans un ClientHello qui annonce une version inférieure à la plus récente version que lui-même prend en charge, il sait qu’un premier échange a échoué », précise l’ANSSI.

Nous avons interrogé l’agence sur ses recommandations concernant TLS 1.3. Pour l’instant, elle « n’a pas encore de position officielle sur la dernière version 1.3 de TLS ». Celles relevant de TLS 1.0, 1.1 et1.2 restent donc inchangées.

SHA-1, RSA-768 : les autres algorithmes tombés au combat

Au-delà des protocoles, ce sont de nombreux algorithmes qui ont été mis à mal au cours de ces vingt dernières années. Un exemple parmi d’autres : SHA-1 dont les attaques se perfectionnent et s’accélèrent régulièrement. La dernière date de début 2017 : des chercheurs annonçaient avoir réussi à produire en un temps « raisonnable » des collisions, c’est-à-dire générer la même empreinte (ou hash) pour deux documents distincts.

Il existe bien sûr des versions plus robustes, SHA-256 ou SHA-3, par exemple. S’il n’existe toujours pas de faille permettant de casser rapidement n’importe quel systèmes AES/RSA, il convient d’utiliser des clés de plus en plus longues pour assurer une bonne robustesse. Effectivement, grâce à la puissance de calcul des ordinateurs/supercalculateurs en perpétuelle augmentation, il est aujourd’hui possible de casser ce chiffrement sur un nombre toujours plus important de bits.

Par exemple, pour le système RSA et les logarithmes discrets, l’ANSSI recommande une taille de clé de 3 072 bits minimum. Au-delà de l’an de grâce 2030, ce ne sera plus une recommandation, mais bel et bien une règle. « La taille des modules RSA est un sujet souvent très polémique », s’empresse d’ajouter l’agence.

Aux dernières nouvelles, RSA-768 est le dernier à être tombé (fin 2009) avec 768 chiffres binaires ou 232 chiffres décimaux. Dans son référentiel général de sécurité 2.0 datant de février 2014, l’ANSSI recommande également une clé de 128 bits pour un chiffrement symétrique.

Néanmoins, elle joue davantage la prudence dans son guide sur TLS : « Concernant le choix entre une clé de 128 bits ou de 256 bits pour AES, il n’existe à ce jour aucune attaque pratique qui remette en cause la confiance accordée à AES-128. Cependant, AES-256 étant jugé plus robuste, son utilisation est préférée à celle de AES-128. »

Il ne s’agit dans tous les cas que de recommandations et chacun est libre de faire comme il veut, d’autant plus qu’il n’existe en France aucune limitation sur la taille d’une clé de chiffrement, au moins pour les particuliers, et ce depuis 2004. Mais attention tout de même à un point : le temps de traitement des données augmente avec la taille de la clé. Utiliser des clés asymétriques de 4 096 bits et symétriques de 256 bits est chose aisée aujourd’hui, autant ne pas s’en priver.

Ordinateurs et chiffrements quantiques en embuscade

L’arrivée des calculateurs quantiques, qui fait régulièrement l’objet de campagnes de communication de la part des géants de l’informatique, soulève de véritables questions concernant la robustesse dans le temps des systèmes de chiffrement actuels. Avec les algorithmes symétriques, l’impact d’un ordinateur quantique est limité « puisqu’il suffit de doubler la taille des clefs en cryptographie symétrique », explique Bernard Ourghanlian, directeur technique de Microsoft France.

Même son de cloche dans les 18e Notes scientifiques (juillet 2019) de l’Office parlementaire d’évaluation des choix scientifiques et technologiques (OPECST) où l’on peut lire : « À l’aide d’un ordinateur quantique, des attaques contre les chiffrements symétriques peuvent également être envisagées, notamment grâce à l’algorithme de Grover. Ce dernier permettrait en effet de réduire considérablement le temps d’une recherche exhaustive de la clef secrète, mais en pratique, cette vulnérabilité peut être compensée par un doublement de la taille des clefs ».

Et ce n’est pas tout : « D’autres formes d’attaques quantiques contre les chiffrements symétriques ont récemment été découvertes, ce qui impose de modifier également ces derniers, mais la menace semble moins critique que pour la cryptographie asymétrique ».

Ainsi, des calculateurs quantiques affublés de suffisamment de qubits pourraient complètement mettre à genoux des algorithmes avec une attaque par force brute sur un chiffrement asymétrique comme le RSA. Nous n’y sommes assurément pas encore, mais les différents acteurs se préparent d’ores et déjà en travaillant à des algorithmes dits « post-quantiques », c’est-à-dire capables de résister théoriquement à la puissance de calcul de tels ordinateurs.

Selon l’OPECST, « il est impossible de prédire si et quand un ordinateur quantique suffisamment puissant sera disponible pour réaliser des attaques. Néanmoins, certains experts estiment qu’il existe 50 % de chances qu’au moins une des méthodes de cryptographie existante soit brisée dans les quinze prochaines années ».

Quantique informatique
Crédits : Devrimb/iStock

L’échange de clé quantique est une réalité, avec « une sécurité absolue »

En attendant, la cryptographie quantique est déjà une réalité, mais contrairement à ce que son nom laisse penser, elle n’a pour l’instant « rien à voir avec l’ordinateur quantique » explique l’ANSSI. « À l’inverse de la cryptographie classique, [elle] ne fait pas reposer la sécurité sur des problèmes mathématiques réputés difficiles, mais sur des lois physiques dont les propriétés sont directement dérivées de la mécanique quantique. Le recours à ces propriétés est utilisé au moment de l’échange de clés : ce n’est pas le chiffrement qui est quantique, mais le partage des clés ».

Imaginons que Marc et Bob souhaitent échanger des informations. Ils doivent commencer par se mettre d’accord sur une clé de chiffrement qui ne doit surtout pas tomber entre de mauvaises mains. Sans entrer dans les détails, les lois de la physique expliquent qu’il est impossible de cloner un objet quantique et que toute tentative de mesure modifie ses propriétés. Bref, la moindre tentative d’espionnage de la part de Marie-Françoise introduirait « des erreurs qui seront repérables grâce à la vérification d’une inégalité mathématique bien choisie, appelée inégalité de Bell ».

Pour Eleni Diamanti du Laboratoire d’informatique de Paris 6 (Sorbonne), « la distribution quantique de clés (en anglais, quantum key distribution, ou QKD) [...] promet, en principe, la sécurité inconditionnelle des communications reposant uniquement sur les lois de la physique. En effet, la QKD est la seule méthode de génération de clé offrant une sécurité absolue dans le sens de la théorie de l’information, et elle a l’avantage d’être sûre face à des attaques futures : il n’est pas possible pour un espion de conserver une copie des signaux quantiques envoyés dans un processus de QKD, en raison du théorème de non-clonage quantique ».

Un chiffrement totalement inviolable à vie existe depuis plus de 100 ans

Pour celles et ceux qui voudraient une solution plus... accessible, sachez que le chiffrement inviolable existe, mais il nécessite que l’on respecte scrupuleusement plusieurs règles et que l’on accepte certaines contraintes qui ne sont pas négligeables. Il s’agit du chiffre de Vernam (ou masque jetable) qui a déjà plus de 100 ans.

Pour faire simple, il s’agit d’une permutation de l’alphabet avec une clé aussi longue que le message à chiffrer. Mais ce n’est pas tout : chaque clé ou masque ne doit être utilisé qu’une seule fois et doit être totalement aléatoire.

Contrairement à ce que l’on pourrait croire, ce dernier point est le plus difficile à mettre en œuvre. La rumeur veut que le fameux téléphone rouge entre les États-Unis et la Russie fût justement chiffré de cette manière. La partie la plus délicate était alors d’échanger les clés/masques sans interception. Les valises diplomatiques circulant entre les deux pays auraient été alors mises à contribution.


Cet article a été publié dans le #1 du magazine papier de Next INpact distribué en janvier dernier. Il est rediffusé ici dans son intégralité et sans modification. Il sera accessible à tous d'ici quelques semaines, comme l'ensemble de nos contenus. D'autres suivront, puis le PDF complet. Pour soutenir cette démarche, précommandez le #2 de notre magazine.

17

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le WPA à la rescousse pour renforcer le WEP...

... mais succombe en 2008 : WPA2 prend la relève

Cap sur WPA3... non sans mal

De SSL par Netscape à TLS 1.3

SSL 2.0 et 3.0 sont tombés, TLS résiste

SHA-1, RSA-768 : les autres algorithmes tombés au combat

Ordinateurs et chiffrements quantiques en embuscade

L’échange de clé quantique est une réalité, avec « une sécurité absolue »

Un chiffrement totalement inviolable à vie existe depuis plus de 100 ans

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (17)


Très instructif, comme toujours&nbsp;<img data-src=" />



Aura t’on une analyse de la la cryptographie quantique bientôt ?&nbsp;<img data-src=" />


Merci pour cet article qui résume très bien la situation.


Article très intéressant! Sympa d’avoir rappelé le chiffrement de Vernam car à chaque fois que je l’évoque dans une discussion, on me demande son fonctionnement…


Pour ceux qui se font chier et qui veulent tester le piratage de (leur) clé wep, sous linux, en live-cd, avoir une clé wifi compatible (il y en a plein), installer aircrack-ng et s’amuser ^^ plein de tutos sur le net, c’est abordable pour les semi-geeks. Ça peut être quelques heures de découvertes


Merci, article des plus intéressants !


Not a troll:





  • Quels sont les protocoles qui restent non chiffrés chez soi (SMB?), et au final quel est l’intérêt de conserver WPA si tout le traffic est SSLisé à terme?

  • Par ailleurs on s’intéresse beaucoup à chiffrer ses communications WIFI et avec internet, qu’en est-il des premiers maillons: les protocoles bluetooth /zigbee avec les multiples capteurs?

  • Quid de la sécurité des chaînes de certificat si on passe sur du DNS HTTPS invérifiable?




Un petit tag [Magazine] dans le titre serait le bienvenue <img data-src=" />


+1 <img data-src=" />








Nicky5 a écrit :



Aura t’on une analyse de la la cryptographie quantique bientôt ?&nbsp;<img data-src=" />



Sans vouloir me mouiller, je pense que l’équipe attends que la production d’efferalgan revienne à un niveau convenable avant de nous niquer les neurones



Ce sous-titre … <img data-src=" />


J’aurais osé “hexatombe”, mais c’est peut-être un peu trop capillotracté…


Bonjour,

Je pense qu’il y a une petite inversion:

Utiliser des clés symétriques de 4 096 bits et asymétriques de 256 bits est chose aisée aujourd’hui

&nbsp;

Les clés 4096 bits sont généralement des clés asymétriques (RSA) et 256 bits symétriques (AES)



Dans les algorithmes asymétriques, on peut parler des courbes elliptiques (EC) qui sont plus robustes que RSA pour les ordinateurs normaux et donc permettent l’utilisation de clés bien plus petites (256-521 bits en EC contre 2048-15360 pour RSA), mais est plus sensible que RSA aux attaques par ordinateurs quantiques.

https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security

https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_atta…



Aujourd’hui, beaucoup de certificats sont en courbes elliptiques (comme celui de NextINpact) ce qui posera sûrement des problèmes quand les ordinateurs quantiques seront plus puissants.

&nbsp;


La majeures partie des protocoles ne doivent pas être chiffrés. Les FTP, HTTP, SMTP en non chiffré doivent être encore beaucoup utilisés, le DLNA, VNC, etc…

L’intérêt du WPA, c’est aussi qu’on peut pas se connecter à ton réseau.

Le BT et les protocoles domotique moderne (zigbee, z-wave…) sont chiffrés, les plus vieux comme le 433 Mhz, je ne pense pas.

Sauf erreur de ma part, le DNS HTTPS n’a aucune incidence sur la chaîne, pas plus que le DNS normal.








brice.wernet a écrit :



Not a troll:

Quels sont les protocoles qui restent non chiffrés chez soi (SMB?), et au final quel est l’intérêt de conserver WPA si tout le traffic est SSLisé à terme?



Pour moi, un des gros intérêts du chiffrement d’un wifi ne réside pas dans le fait d’empêcher un individu externe d’espionner les échanges mais d’authentifier les utilisateurs qui peuvent utiliser ce réseau. Si tu n’appliques pas de couches de crypto, comment limites-tu l’accès à ton acces point ?

&nbsp;

Pour ce qui est du chiffrement des données, il faut savoir que beaucoup de metadata de protocoles utilisant du chiffrement sont encore envoyés en clair. Donc on peut déjà obtenir des informations intéressantes sur les utilisateurs en sniffant les échanges mêmes en TLS. Si tu ne chiffres pas ton wifi, tu laisses ces infos disponibles à n’importe qui à proximité.



Dans les protocoles rarement chiffrés on va trouver les partages de fichiers (SMB, NFS par exemple). Comme le DNS, ils peuvent être chiffrés dans leurs versions récentes. Mais si&nbsp; ils ne le sont pas c’est parce-que la gestion des clés est une plaie à configurer, que la moindre erreur conduit à un déni de service et que c’est pénible à déboguer.

Après il y a tous les protocoles de niveau inférieur DHCP, ARP, Ethernet … ou il n’y pas des masses de solution. La spécificité du sans fil est qu’on ne peut pas en contrôler l’accès physique, ce qui rend le chiffrement plus important. Mais dès qu’un réseau couvre un espace assez vaste le même problème se pose pour les câbles que pour les ondes.

&nbsp;

Bluetooth https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_protocoles_Bluetooth#Modes_… et Zigbee peuvent utiliser du chiffrement très correct. Mais leur mise en oeuvre est rarement bonne chez les implémenteurs. Qui plus est, négocier des clés sur des appareils avec peu ou pas d’interface utilisateur est un vrai problème (essayer de rentrer un code à 10 chiffres sur un casque audio bluetooth). C’est d’ailleurs un problème commun de tout ce qui est “internet des objets”. En général, on a 2 approches: clés fixes (appareils Bluetooth Low Energy qui ont tous ou presque 000000 comme clé), ou désactiver la sécurité temporairement, le temps d’appairer des appareils via une manipulation physique (l’appairage est alors un échange de clés). Ce sont des problèmes intéressants…. donc pas faciles ;-)

&nbsp;

Je n’ai pas compris la question sur DNS HTTPS.

&nbsp;

En espérant que ça réponse un peu à des questions.


Il me semble que sous Windows, une case à cocher par partage suffit à chiffrer le SMB sur les OS serveurs récents, tant que le client est en OS Windows. Mais quid des clients linux et &…


Que à partir de SMB 3.0 donc à minima Win 8 coté client et 2012 coté serveur