KRACK casse-t-il TLS?
Excusez-moi si cela est déjà répondu dans le livre blanc, je ne vais pas avoir la chance de le lire pendant quelques jours en raison d'un calendrier chargé, mais je réponds déjà à des questions de non-techniciens en lisant des actualités médiatiques non techniques, ce qui les rend croyons que nous devons tout débrancher et retourner au commerce de l'or.
Ce que je comprends (et corrigez-moi si je me trompe), c'est que cela permet essentiellement aux attaquants de mettre en place une attaque MITM en forçant une nouvelle poignée de main entre les appareils (oui, c'est stupide), et qu'il s'agit d'une faille dans la base mise en œuvre du protocole de chiffrement, il faudra donc une mise à jour du firmware pour corriger (oui pour aider les familles âgées et les voisins à mettre à jour le firmware sur leurs routeurs).
Je ne vois pas comment cela invaliderait également le cryptage utilisé dans le cadre de TLS, mais je suis loin d'être un expert en la matière.
KRACK est sur la couche réseau du modèle OSI , tandis que TLS est sur la couche session. Donc non, ils ne s'influencent pas mutuellement, à condition que le client ne puisse pas être incité à utiliser une connexion non TLS ( SSLstrip ).
La menace de base de KRACK est qu'il permet à un attaquant de déchiffrer tous les packages de la couche réseau que la victime envoie/reçoit. Cela inclut toutes les communications en texte clair (par exemple, celles que de nombreux programmes de messagerie utilisent encore, les connexions aux périphériques du réseau local, etc.).
Cela signifie que si vous affichez la clé réseau et qu'une attaque voit tout votre trafic, ils peuvent simplement établir une connexion complète avec votre réseau et y faire des ravages comme bon leur semble.
S'il y a d'autres vulnérabilités dans l'implémentation (par exemple, ce qui se passe dans Android 6), alors l'attaquant peut même manipuler des paquets en transit vers la victime. (Les textes chiffrés et en texte clair peuvent être manipulés). Cependant, l'attaquant ne peut pas lire son contenu si les paquets eux-mêmes sont chiffrés par un protocole de couche session (par exemple TLS), ce qui ouvre la possibilité de modifier les valeurs de clé ou de rediriger la victime vers un site d'attaquant pour infection.
Ainsi, même s'il s'agit d'une infraction grave qui doit être résolue dès que possible, elle ne doit pas compromettre un trafic correctement sécurisé. Utilisez donc un VPN, HSTS , HPKP et ssh, pour vous protéger et/ou vos utilisateurs.
Non, cela n'affecte pas TLS. En fait, l'utilisation de sites cryptés TLS (HTTPS) est utile si vous vous inquiétez de KRACK - un attaquant ne pourrait voir que le site auquel vous accédez, mais pas les pages du site ou les données que vous envoyez au site.
Il y a d'autres attaques récemment annoncées qui peuvent affecter TLS, et il est possible qu'une certaine couverture médiatique ait fusionné les deux.
La vulnérabilité directe de KRACK n'affecte pas le cryptage TLS/SSL, mais une fois le MITM établi, SSLstrip peut être utilisé pour supprimer HTTPS en HTTP. Ceci est indiqué dans la démonstration vidéo officielle où les informations de connexion pour match.com sont détectés à partir d'un appareil Android.
KRACK n'affecte pas SSL/TLS.
WPA2 fonctionne sur la couche liaison de données tandis que SSL/TLS fonctionne sur la couche session. L'exemple sur https://www.krackattacks.com/ utilise bande SSL pour contourner SSL. Cependant, cela ne fonctionne que sur les sites Web qui ne sont pas configurés pour utiliser HSTS , qu'un bon nombre de sites Web n'utilisent pas: https: // www.ssllabs.com/ssl-Pulse/