Sorry, you need to enable JavaScript to visit this website.

les 5 minutes du professeur Audenard - épisode 8 : l'attaque de l'homme du milieu

les 5 minutes du professeur Audenard - épisode 8 : l'attaque de l'homme du milieu
2011-09-182013-03-28sériesfr
La vidéo qui vous sera présentée explique de manière simple et efficace une attaque sur internet en prenant un cas concret, quelque chose qui vous arrive tous les jours: se connecter à sa boîte gmail...
Publié le 18 Septembre, 2011 par Virginie Tran dans séries
les 5 minutes du professeur audenard

Après des vacances bien méritées et une cure de vitamine C, le professeur Audenard  (Jeff pour les intimes) est de retour pour une rentrée explosive !

La vidéo suivante explique de manière simple et efficace une attaque sur internet en prenant un cas concret, quelque chose qui vous arrive tous les jours: se connecter à sa boîte gmail !

Jusque là tout va bien, je pense, personne n'est perdu... ;-)

Le reste des explications se focalise sur un éclaircissement schématisé de l'attaque: 
https pcp 443, adresse IP, SSL, certificat, faux serveur, connexion, chiffrage, cadenas...

Interessé, captivé... intrigué ? Alors cliquez !

Le principe de l'attaque du man in the middle n'aura plus de secrets pour vous !


[FR] les 5 minutes du professeur Audenard... par orange_business

Vous pouvez également visualiser la vidéo via youtube.

Et vous, que pensez-vous de ce type d'attaque ? Avez-vous connu des faits similaires ?

謝谢
Virginie

© Maridav - Fotolia.com

6 commentaires

  • 11 Octobre, 2011
    2011-10-11
    par
    Benoit
    Bonjour, dans votre réponse à Cédric, vous dites que le canal TLS est détourné suite à l'authentification TLS du serveur légitime par le client. Si c'est vraiment le cas, comment l'homme au milieu fait-il pour accéder au contenu de cette session TLS ?  Dispose-t-il d'une attaque cryptographique spécifique pour casser le chiffrement et "écouter" le login / password de la session TLS légitime ? Ou doit-il casser la session TCP courante, et reconstruire une session TLS avec un certificat frauduleux ?  Cette description me semble assez étrange, malgré tout: dans ce 2ème cas, le coup du "certificat frauduleux" reste à éclaircir! 
  • 26 Septembre, 2011
    2011-10-11
    par
    Bonjour. Oui le son est faible : On va s'efforcer de corriger ce problème lors des prochaines vidéos. Désolé pour ce désagrément.
    Si je décompose la cinématique :
    1) Le client établi une connexion TCP à la machine MitM.
    2) La machine MitM lui envoie un faux certificat SSL
    3) Le client établi une connexion SSL avec la machine MitM
    4) La machine MitM établi une connexion SSL avec GMail
    5) La machine MitM "aboute" les deux connexions SSL de part et d'autre, comme elle est "au milieu des deux" elle a la possibilité de voir ce qui s'échange.
    6) Une fois la connexion SSL établie "en deux étapes via le serveur MitM", le client soumet ses identifiants de connexion (login/password) à GmaiL. (le serveur MitM pouvant les "capturer").

    Est-ce plus clair ?
    JF.
  • 26 Septembre, 2011
    2011-10-11
    par
    Bonjour Cédric.

    Désolé pour le délai de réponse à votre commentaire ! Oui, votre analyse est bien correcte.

    Pour faire en sorte que les choses soient bien claire pour tous, il faut bien comprendre qu'il y a en fait deux "authentifications" :
    1) Authentification du site Gmail via le certificat SSL
    2) Authentification de l'utilisateur auprès de Gmail en soumettant son login/password

    L'attaque présentée s'appuie sur le détournement du canal créé suit à l'authentification #1 (celle basée sur le certificat SSL). Une fois ce détournement en place, l'attaquant va "capter" les login/password de la phase d'authentification #2 car ceux-ci ne seront plus protégé par la le canal SSL.

    Bonne continuation.
    JF.
  • 19 Septembre, 2011
    2011-10-11
    par
    Cédric
    Bonjour, reprenez moi si je me trompe mais l'authentification dont vous
    parlez correspond aux autorités qui vont garantir que le certificat est "
    valide " et qu'il s'agit donc bien de gmail en face (par rapport à
    l'exemple).

    De cette manière, si notre certificat est enregistré
    auprès de l'une d'elles pour ce domaine, gmail.com (attaque comme il
    s'est vu dernièrement et qui ont permis la génération d'un nombre
    important de faux certificats), le navigateur n'y verra aucune
    objection, du moment qu'il fait confiance à cette autorité. Si il n'est
    pas validé par une de ces autorités, l'utilisateur aura simplement un
    warning qu'il s'empressera, la plupart du temps, de valider pour
    continuer.

    Quand on effectue une attaque de type MITM, c'est
    l'utilisateur qui nous envoi ses identifiants via le "faux canal" que
    l'on a mit en place avec lui. On redirige simplement sa requête vers
    gmail, après avoir récupéré les informations intéressantes bien sur ;)
  • 19 Septembre, 2011
    2011-10-11
    par
    "J'envoie un certificat frauduleux, le navigateur n'y voit que du feu".

    SSL ne sert qu'à chiffrer la communication, surtout pas à authentifier le serveur, c'est bien connu !

Pages

ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.