Monkeysphere, « enlever l'homme du milieu »

Posté par  (site web personnel) . Modéré par Xavier Teyssier.
Étiquettes :
28
6
oct.
2010
Sécurité
Monkeysphere est un projet permettant d'utiliser la « toile de confiance » OpenPGP pour de nouveaux usages, comme l'identification dans les protocoles SSH et HTTPS.

Sur SSH (avec OpenSSH), Monkeysphere permet d'utiliser des clefs OpenPGP pour identifier aussi bien les clients que les serveurs. On peut ainsi récupérer, valider et tenir à jour :
  • Les clefs publiques de serveur (known_hosts) ;
  • Les autorisations de connexion par clef personnelle.

Par rapport au système natif d'OpenSSH, cela permet de bénéficier des fonctionnalités de mise à jour, d'ajout de nouvelles clefs ou sous-clefs et de révocation du système OpenPGP.

Sur HTTPS avec n'importe quel serveur et avec le navigateur Firefox au moyen d'une extension, Monkeysphere permet d'utiliser OpenPGP comme moyen alternatif d'identification du serveur par son certificat SSL. Cela permet d'introduire un modèle de sécurité qui répond aux inconvénients de la centralisation qu'encourage le modèle SSL, tels que la concentration de pouvoir et les vérifications faibles. Tout comme OpenPGP, SSH et SSL sont basés sur des systèmes cryptographiques asymétriques, qui utilisent une clef privée et une clef publique, en particulier pour l'identification. Le principe de base de Monkeysphere est donc de permettre d'importer ou d'exporter une clef ou sous-clef OpenPGP vers une clef privée SSH ou SSL, pour pouvoir l'utiliser avec ces protocoles.

Identification des serveurs SSH

L'administrateur du serveur génère une paire de clefs d'authentification (une clef OpenPGP peut avoir plusieurs rôles : authentification, chiffrement et signature ; seule la fonctionnalité d'authentification est requise ici), aux formats OpenSSH et OpenPGP :
  • Il utilise la version OpenSSH comme clef privée de serveur (/etc/ssh/host_rsa_key et /etc/ssh/host_rsa_key.pub) ;
  • Il publie la version OpenPGP dans le réseau de serveurs de clefs synchronisées — ou la distribue par d'autres moyens — sous le nom « ssh://serveur.example.com » et la signe avec sa clef personnelle.

Lorsqu'un utilisateur se connecte pour la première fois à ce serveur, Monkeysphere récupère la clef publique correspondant au nom du serveur à l'aide de GnuPG. Si elle est valide selon la base de confiance de l'utilisateur, il l'ajoute à son fichier d'hôtes connus (~/.ssh/known_hosts).

Identification des utilisateurs SSH

Chez lui, l'utilisateur génère une paire de clefs ou de sous-clefs d'authentification, au format OpenPGP, à son nom, qu'il distribue.

Sur le serveur, l'utilisateur indique dans un fichier de configuration de Monkeysphere (~/.monkeysphere/authorized_user_ids) la liste des utilisateurs (Prénom Nom ) qui doivent être autorisés à se connecter avec leurs clefs OpenPGP.

Sur le serveur toujours, l'administrateur utilise Monkeysphere pour générer pour chaque utilisateur la liste des clefs SSH autorisées à se connecter (~/.ssh/authorized_keys, déplacé par Monkeysphere en /var/lib/monkeysphere/authorized_keys/%u).

Pour se connecter sur le serveur, l'utilisateur commence par exporter sa clef d'authentification OpenPGP dans son agent SSH. Son client SSH propose alors cette clef au serveur lors de la connexion, pour que celui-ci accepte la connexion selon le mécanisme habituel du protocole SSH.

Identification des serveurs HTTPS

Comme pour SSH, l'administrateur génère une paire de clefs d'authentifications aux deux formats SSL et OpenPGP. Il utilise la version SSL pour construire son certificat SSL, et publie la version OpenPGP.

Lorsqu'un utilisateur se connecte avec un Firefox muni de l'extension Monkeysphere, si le mécanisme normal de validation du certificat échoue, Monkeysphere recherche la clef du serveur à l'aide de GnuPG. Si elle est valide, il ajoute une exception SSL pour valider la connexion.

Aller plus loin

  • # Diffusion

    Posté par  . Évalué à 6.

    Ça semble intéressant mais ont-ils prévu de distribuer leur solution, dans le sens la faire adopter globalement ? De faire une RFC pour l'IETF ?
    Et si oui, comment comptent-t-ils s'y prendre ? Parce que la solution extension Firefox n'en est pas vraiment une selon moi.

    (Non, je n'ai pas regardé le site, le proxy le bloque)
    • [^] # Re: Diffusion

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

      Il existe déjà une RFC, très peu prise en charge, sur l'utilisation de certificats OpenPGP dans le cadre de TLS.

      Là, c'est différent, ça reste du SSL classique, avec certificat SSL… mais moyen de se ramener à OpenPGP.
    • [^] # Re: Diffusion

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

      >Ça semble intéressant mais ont-ils prévu de distribuer leur solution, dans le sens la faire adopter globalement ?

      A mon avis les plus gros frein à une adoption globale s'appellerait Verisign. Tu veux les priver du racket marché des certificats ! Et quand bien même il y aurait une rcf, je ne vois pas ce qui déclencherai l'adoption massive (hors entreprises peut-être).

      Ce n'est pas nouveau. PGP ROX. PGP aurait pu nous sauver du spam. PGP est depuis longtemps le meilleur mécanisme se reconnaître mutuellement à coup sûr.

      PGP ne nécessite pas de tiers de confiance grassement rémunéré.

      Je pense que le fond est là.
      • [^] # Re: Diffusion

        Posté par  . Évalué à 1.

        PGP aurait pu nous sauver du spam.
        Ah bon? Tu gères comment le cas de la personne qui cherche à prendre contact avec toi par mail?

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Diffusion

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Via les serveurs de clé ?
        • [^] # Re: Diffusion

          Posté par  . Évalué à 6.

          GPG ne règle pas tout, mais il règle certains problèmes. Typiquement tous les spams du genre hameçonnage. C'est plus compliqué de se faire passer pour paypal si tous les mails émis par paypal sont signés (de même et plus récemment, pour Hadopi).
        • [^] # Re: Diffusion

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

          >Ah bon? Tu gères comment le cas de la personne qui cherche à prendre contact avec toi par mail?

          Je ne vois pas la difficulté. Elle signe son mail, je récupère sa clé sur un serveur de clé. Je lui répond en en signant mon mail et elle récupère ma clé sur un serveur de clé ...
          • [^] # Re: Diffusion

            Posté par  . Évalué à 7.

            Qu'est ce qui empêche le spammeur de signer ses emails ?
            Et même autant que clés qu'il le souhaite, afin qu'on ne puisse pas mettre ses clefs en liste noire.

            Bon, forcément ça augmente le niveau de connaissance nécessaire. Mais ça l'augemente pour le monde entier, pas uniquement les spammeurs. Donc tu es obligé d'accepter les emails non signés (sinon tu te coupes de 99,123456% des emails valides) alors les spams non signés passerons pareil.
            • [^] # Re: Diffusion

              Posté par  . Évalué à 1.

              Qu'est ce qui empêche le spammeur de signer ses emails ?

              Peut-être les ressources de calcul ?
              Tout ce qui est cryptographie asymétrique (signature, chiffrement asymétrique même hybride) nécessite des ressources de calcul difficilement compatibles avec une approche "envoi de mails en masse" si chacun doit être chiffré pour le destinataire et signé.
              • [^] # Re: Diffusion

                Posté par  . Évalué à 1.

                Tu veux tuer les listes de diffusion avec inscription volontaire?

                THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                • [^] # Re: Diffusion

                  Posté par  . Évalué à 4.

                  Il suffira qu'elles se mettent au spam, comme ça avec l'argent gagné elles pourront s'acheter plus de matériel, donc faire plus de spam, donc gagner plus d'argent, donc s'acheter encore plus de matériel, etc. En plus c'est pratique pour se lancer, tu as déjà une liste d'email confirmés :)

                  En plus, ça va permettre de relancer l'achats de machines neuves pour pouvoir supporter tous ces traitements !
              • [^] # Re: Diffusion

                Posté par  . Évalué à 7.

                Si le spam est envoyé (comme souvent actuellement) par un botnet c'est l'ordinateur zombi qui va se taper la crypto donc coût plutôt faible pour le spammeur (par contre l'ordi de Mme Michu va ramer un peu plus .... [vendredi] elle dira que c'est de la faute de Windows de toute façon [/vendredi])
            • [^] # Re: Diffusion

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

              >Qu'est ce qui empêche le spammeur de signer ses emails ?

              Je pense que "aurait pu" t'a échappé dans mon propos.

              Imaginons quatre règles simples et universellement adoptées (puisqu'on est dans le conditionnel passé qui n'aura jamais lieu) :
              - tout possesseur de domaine est identifié par une clé
              - tout utilisateur d'adresses @ledomaines est identifiée par une sous-clé de celle du domaine
              - tout domaine ne peut révoquer sa clé que tous les 5 ans
              - tout mail non signé est rejeté.

              les clé des spammeurs sont blacklistées en trois jours chrono. Chacun prends ses responsabilités. Tous le monde (imagine la clé de orange.fr blacklisté) demande un minimum de garantie avant d'ouvrir son smtp. Même yahoo finirait par faire du ménage dans ses groupes de discussion.
              Fin du spam.

              Mes deux cents
              Joris
              • [^] # Re: Diffusion

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

                C'est plutôt DKIM que tu décris là.
              • [^] # Re: Diffusion

                Posté par  . Évalué à 3.

                Tu proposes de changer _totalement_ la manière de fonctionner des emails (signature obligatoire pour le monde entier) et des authentifications. C'est juste un détail, mais il ne te reste plus qu'un milliard de personnes à convaincre :-)
  • # Homme au milieu

    Posté par  . Évalué à 2.

    Je n'ai pas compris comment cela supprime le problème de l'homme au milieu. Le seul indice que je trouve est Il publie la version OpenPGP dans le réseau de serveurs de clefs synchronisées — ou la distribue par d'autres moyens mais cela n'explique pas comment la magie s'opère.
    • [^] # Re: Homme au milieu

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

      Normalement avec OpenSSH à la première connexion on est censé vérifier l'emprunte de la clef du serveur, et c'est parce qu'on ne le fait pas que l'homme au milieu est possible (enfin si je me souviens bien).
      Ici cette vérification est automatisée en vérifiant la clef OpenPGP correspondant au serveur SSH. Et c'est la « toile de confiance » (Web of Trust) qui fait le reste: si la clef OpenPGP du serveur a un niveau de confiance suffisant alors la clef OpenSSH correspondante sera acceptée.

      En tous cas, c'est ainsi que je le comprend.
      • [^] # Re: Homme au milieu

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

        Et pareil pour SSL avec des certificats non signés par un des membres de la mafia SSL.

        Bon, en fait c'est surtout le sujet de leur canal IRC, « taking the man out of the middle ». :-)
      • [^] # Re: Homme au milieu

        Posté par  . Évalué à 3.

        Je pense la même chose que toi. Cependant cela ne fait qu'ajouter une entité de certification supplémentaire (ce qui est très bien, car compromettre 2 autorités, il faut y aller). Mais en quoi cela supprime l'homme au milieu ?

        Si mon certificat SSL est chez Verisign, je ne suis pas sensé avoir de problème d'homme au milieu (sauf si Verisign est compromis, ce dont je ne doute pas).

        Si mon certificat est autosigné, le déclarer chez OpenPGP n'apporte pas plus que de la générer chez une autorité de confiance gratuite: dans les deux cas il faut installer un certificat supplémentaire (et dans le cas d'OpenPGP la machinerie qui va avec).

        Alors certes, vérifier un certificat auprès de deux sources de confiance c'est très mieux. Mais je n'y vois toujours rien qui supprime l'attaque de l'homme au milieu puisqu'elle n'est déjà pas possible (sauf compromission de l'autorité, d'où l'intérêt de la double vérification).

        Je ne suis pas certain d'être clair :-)
        • [^] # Re: Homme au milieu

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

          Avec OpenPGP, la vérification peut être double, triple, quadruple…

          Non, ça supprime les risques d'attaques de l'homme du milieu dans le cas de certificats non certifiés par la mafia SSL.
  • # Vivre sans AC (autorité de certification)

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

    Hello,

    Monkeysphere me rapelle un article des membres du projet Tor que vous trouverez ici: https://blog.torproject.org/blog/life-without-ca . L'approche du rédacteur de l'article est assez percutante: il supprime les AC par défaut et empêche firefox/iceweasel de valider les certificats automatiquement.

    Toute sa navigation "chiffrée" se fait en acceptant les certificats individuellement qu'il vérifie lui-même en trouvant une autre preuve de la validité d'un certificat que le simple fait qu'il soit "validé" par une AC. Par exemple, il appelle l'organisme pour que celui-ci certifie l'empreinte. Ou bien, il utilise Tor pour se connecter "d'ailleurs" sur le site à vérifier, pour voir si tous les certificats sont identiques.

    La question qui se pose est: faîtes-vous confiance aux AC fournies par défaut ? L'auteur ne le fait pas et quand on voit les pratiques de certaines entreprises sur le sujet (une boîte qui s'amuse à faire des DNS menteurs cf http://en.wikipedia.org/wiki/Site_Finder ), on peut penser que le modèle du "Web of Trust" (Toile de confiance: http://en.wikipedia.org/wiki/Web_of_trust ) de GPG a toute sa place.

    Et puis, le décentralisé, c'est à la mode en ce moment (swarmplayer, diaspora, Tor, l'auto-hébergement, Seeks, etc...) et c'est bien ! MonkeySphere est le bienvenu et j'espère qu'il percera sur le sujet de la confiance.
    • [^] # Re: Vivre sans AC (autorité de certification)

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

      >La question qui se pose est: faîtes-vous confiance aux AC fournies par défaut
      Je ne fais plus confiance à Verisign depuis le jour ou il ont essayé de coller de la pub à la terre entière.
    • [^] # Re: Vivre sans AC (autorité de certification)

      Posté par  . Évalué à 3.

      > La question qui se pose est: faîtes-vous confiance aux AC fournies par défaut ?


      dedans il y en a des russes, des turques, des chinoises. je passe sous silence les ricaines, évidemment.

      donc euh non.

      il y a aussi diverses grosses boites sans trop de rapport avec des AC (AOL, Visa) dont on aimerait qu'elles restent bien gentiment dans leur domaine de compétence au lieu de faire des conneries ailleurs.
      • [^] # Re: Vivre sans AC (autorité de certification)

        Posté par  . Évalué à 3.

        dedans il y en a des russes, des turques, des chinoises. je passe sous silence les ricaines, évidemment. donc euh non.
        S'il y avait une boîte française, tu aurais plus confiance ? :-)
        Pour ma part, pas spécialement.

        En fait l'idée d'avoir plusieurs sources simultanées pour les certificats, ça me plaît bien. Tel site web ou telle connexion ssh serait vérifiée avec plusieurs certificats. L'un est chez les ricains, un autre est chez CACert, et un troisième est en Chine. Le navigateur web ou le client ssh est sensé vérifier auprès de tous.
        Ca diminue trèèèèèès fortement la possibilité de bricolage.
        • [^] # Re: Vivre sans AC (autorité de certification)

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

          Et ça, c'est exactement la différence technique fondamentale entre les certificats SSL et PGP. Un certificat SSL c'est une clef publique signée par une autorité. Un certificat PGP c'est une clef publique signée par zéro, une ou plusieurs autorité.

          C'est cette différence technique qui impose un modèle de confiance pyramidal pour SSL, et qui permet un modèle de confiance en réseau pour PGP. Notez toutefois que PGP permet, à ce niveau, tout ce que SSL permet : on peut implémenter le modèle de confiance pyramidal de SSL avec PGP, il suffit de définir une mafia d'autorité et de lui faire signer les clefs des gens.
  • # Débranchez tout

    Posté par  . Évalué à -6.

    débranchez votre wifi, votre bluetooth, vos prises réseaux, vos ports usb, vos câbles d'alimentation et allez faire une petite promenade, respirez le bon air.
    j'avoue que je suis quand même surpris par [3], les messages que l'auteur essaye de faire passer, qui ne sont pas en rapport avec le sujet traité. êut-on lui faire confiance ? à mon avis non...

Suivre le flux des commentaires

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