Retour sur la vidéo : Explication de KRACK Attacks – A chaud #1

Cela fait une semaine que notre première vidéo Explication de KRACK Attacks – A chaud #1 est sortie. Et pour tout vous dire nous sommes ravis !

Déjà plus plus de 450 vues !

Allez, on prend le temps de faire un premier bilan.

Vos retours

Vous avez été nombreux à nous dire ce que vous avez pensé de notre première vidéo « à chaud ».

MERCIIIII !!! <3

C’est grâce à vous que nous allons progresser.

Nous avons retenu :

« Le son de Tom n’est pas très bon »

Oui, c’est dû au micro et au fait que l’enregistrement se fait via visioconférence sur le PC de Flo.

Pour la prochaine, Tom enregistrera avec son micro cravate le son sur son PC et nous assemblerons le tout au montage.

« Même si je ne m’y connais pas, j’ai tout compris. »

Merci !! <3

Puisque c’est le but de la vulgarisation rien ne peut nous faire plus plaisir !

« C’est vous qui jouez la démo ? »

Non, nous prenons les rôles de l’utilisateur (Tom) et de l’attaquant (Flo) mais nous ne réalisons pas la démonstration. Il s’agît de la vidéo de la démonstration officielle que nous commentons.

« J’aurais aimé un peu plus de détails sur le fonctionnement du truc mais ce serait peut être moins accessible du coup ! »

C’est un peu l’idée 😉

Pour creuser le sujet, l’article publié par le chercheur est à lire : https://www.krackattacks.com

« Il y a beaucoup d’acronymes, serait-il possible d’avoir un glossaire ? »

L’informatique, comme beaucoup de métiers, est bardé d’acronymes. Et les retenir ne se fait effectivement pas du premier coup. Pour pouvoir être « à chaud », nous souhaitons conserver ce format avec le moins de montage possible. Donc pas de glossaire incrusté dans la vidéo. Dans ce format en tout cas, dans les autres vous trouverez beaucoup plus d’aides visuelles (images, schéma, textes, animations etc.).

Qu’est-ce qu’un site « bien configuré » ?

Quelques uns d’entre vous ont pris le temps de nous faire des propositions sur ce que devrait être un site bien configuré pour ne pas laisser la possibilité à l’attaquant de le délivrer en HTTP ou lieu d’HTTPs (<= le s c’est pour secure).

Voici un récap’ :

RewriteHTTPtoHTTPS ?

En somme, la solution proposée est que le serveur force le navigateur de l’utilisateur à utiliser HTTPs même si il lui demande du HTTP.

Comme l’attaquant est en Man in the Middle, SSLStrip permet de détourner le trafic HTTPs en le redirigeant vers du HTTP. Donc du point du vue du serveur, c’est bien du HTTPs et du point de vue du navigateur du HTTP.

Ça ne permet donc pas de parer l’attaque.

HTTP Strict Transport Security ?

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

— Wikipedia FR

Ça c’est une bonne piste ! Bon par contre SSLStrip est capable de passer outre dans deux cas :

1. C’est la première fois que le navigateur accède à ce site,
2. La période indiquée par HSTS est dépassée.

HSTS preload ?

On reprend le concept précédent et on ajoute une autorité qui note les sites qui annoncent être délivrés en HTTPs : https://hstspreload.org/

Les navigateurs récents récupèrent constamment cette liste et ils ont donc la possibilité d’interdire à l’utilisateur un site qui ne devrait pas être en HTTP.

Ça nous semble donc être une bonne parade !

Merci beaucoup à Aurélien Labate pour nous avoir fait découvrir cela. 🙂

Et la suite ?

Et bien, cette vidéo n’étant pas prévue, ça a un peu chamboulé notre planning. Mais rien de grave : on va publier la prochaine plus tôt que prévu. 😉

Alors rendez-vous dans quelques jours pour la vidéo de présentation de notre chaîne !