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
- Site du projet (42 clics)
- Documentation (20 clics)
- Problèmes de l'architecture SSL (25 clics)
# Diffusion
Posté par Phil Actaire . Évalué à 6.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Là, c'est différent, ça reste du SSL classique, avec certificat SSL… mais moyen de se ramener à OpenPGP.
[^] # Re: Diffusion
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
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 Grunt . Évalué à 1.
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 LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Diffusion
Posté par Florent Fourcot . Évalué à 6.
[^] # Re: Diffusion
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
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 Kerro . Évalué à 7.
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 khivapia . Évalué à 1.
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 Grunt . Évalué à 1.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Diffusion
Posté par Lebas Sébastien . Évalué à 4.
En plus, ça va permettre de relancer l'achats de machines neuves pour pouvoir supporter tous ces traitements !
[^] # Re: Diffusion
Posté par neerd . Évalué à 7.
[^] # Re: Diffusion
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Diffusion
Posté par Kerro . Évalué à 3.
# Homme au milieu
Posté par Kerro . Évalué à 2.
[^] # Re: Homme au milieu
Posté par Julien Viard de Galbert (site web personnel) . Évalué à 4.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
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 Kerro . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 Médéric RIBREUX (site web personnel) . Évalué à 9.
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 Joris Dedieu (site web personnel) . Évalué à 3.
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 Gniarf . Évalué à 3.
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 Kerro . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
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 tyoup . Évalué à -6.
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...
[^] # Re: Débranchez tout
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.