Forum général.général SSL et Man-In-The-Middle

Posté par  .
Étiquettes : aucune
0
17
juil.
2006
Sans rappeler le principe d'une attaque du type MITD et son application au protocole SSL, on peut lire partout que les certificats d'autorités reconnues sures permettent de détecter ce type de d'attaque.

Dans le cas d'une connexion HTTPS, si on contrôle un équipement réseau intermédiaire indispensable au client pour toute communication vers l'extérieur, que c'est bien sur sur cet équipement qu'est implémenté le MITD, il nous faudra générer un faux certificat qui ne pourra bien sur pas être vérifié.

Pourquoi ne pas aussi se faire passer pour l'autorité de confiance et assurer que le certificat est valable ? Ou plutôt pourquoi ne peut-on pas (je suppose) le faire ?

Cordialement.

  • # Fournis par défaut

    Posté par  (site web personnel) . Évalué à 6.

    Parce que es autorités de confiances sont fournies par défaut avec le logiciel acheté. Tu peux toi-meme en ajouter par la suite.
    C'est pour cette raison que verisign se permet de faire payer très cher ses certificats, ils étaient là parmis les premiers et sont donc dans tous les navigateurs.

    • [^] # Re: Fournis par défaut

      Posté par  . Évalué à 2.

      Ce que je suggérais, c'est que si au niveau de l'équipement réseau, je détecte une demande de verification de certificats à verisign.com, plutôt que de la laisser faire et donc voir verisign retourner une invalidité, me faire passer pour verisign et lui dire que le certificat est valide ?

      Qu'est-ce qui m'en empeche vu que toutes les communications passent par moi ? Qu'est-ce que ca change que l'autorité soit considérée comme sure par default ou rajoutée apres ?

      • [^] # Re: Fournis par défaut

        Posté par  . Évalué à 4.

        Sauf que tu ne pourra pas de faire passer pour verisign puisque tu ne connais pas leur cléf privé, et donc, tu seras incapable d'imiter verisign.

        Donc pas de man in a middle.

        C'est pour ca que le https de DLFP pu très fort du cul. Il n'a été signé par aucune autorité reconnue. Mais, ca c'est une autre histoire :-)

      • [^] # Re: Fournis par défaut

        Posté par  . Évalué à 2.

        ben tu oublies juste un detail : tu n'as pas les cles privees de Verisign qui permettent de lire le challenge du client.

        • [^] # Re: Fournis par défaut

          Posté par  . Évalué à 2.

          Donc la clé publique de verisign utilisé par le client était déjà de base dans le logiciel ? A aucun moment elle ne circule sur le réseau (car sinon il me suffirai de fournir la mienne) ?

          Et donc à moins de compromettre directement le logiciel au moment ou celui-ci est récupéré par le réseau ( faut compromettre aussi son MD5 ^^), on évite le MITD ?

          Et donc aussi une autorité qui n'est pas par default dans un logiciel et dont on récupère la clé puplique par le réseau c'est un peu bof comme sécu et faut supposer que cette première connexion à l'autorité était sure ?


          En tous cas merci pour ces précisions ^^.

      • [^] # Re: Fournis par défaut

        Posté par  . Évalué à 5.

        Ce n'est pas comme cela fonctionne.

        Tu dois importer sur ton système (un équipement réseau, un pc, etc.) la clé publique de l'autorité de certification une fois pour toute (cette opération en revanche doit être faite avec précautions en termes de sécurité).

        Ensuite, lorsqu'un certificat se proclamera signé par une autorité de certif donnée, le système confrontera la signature du certificat avec la clé publique de l'autorité installée sur le système

        La vérification s'effectue localement, et non pas à distance par un serveur verisign.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.