j'ai complété un peu l'article pour la partie Hubzilla. La vraie particularité de ce réseau est la gestion des authentifications et des droits d'accès, qui est complètement décentralisée. J'ai essayé de mettre un exemple pour qu'on puisse bien comprendre. A mon sens ce modèle d'authentification mériterait d'être généralisé car il est extrêmement puissant.
Je n'ai pas voulu trop charger le projet de dépêche, mais pour les curieux voici le principe en plus détaillé :
Alice a un profil sur le serveur A. L'identité de son profil est liée à une clé publique associée à une clé privée stockées toutes les deux sur le serveur A. La clé publique est accessible via finger depuis l'internet publique, en envoyant une requête sur le profil "Alice@A" sur le serveur A.
Si elle le souhaite, Alice peut cloner son profil sur le serveur A-prime. Ce profil cloné aura pour adresse Alice@A-prime, et aura le même identifiant cryptographique (clé privée/clé publique). Alice peut aussi choisir de synchroniser ses données (photos, messages, fichiers) entre les deux serveurs.
Il en va de même pour Bob qui a un profil sur son propre serveur "B", cloné sur B-prime.
Si Alice veut donner accès à ses photos intimes à Bob, le serveur qu'elle utilise (A ou A-prime) récupère la clé publique de Bob à partir interrogeant via finger le serveur B ou le serveur B-prime. Elle stocke cette clé dans la liste de contrôle d'accès de ses photos sur les serveurs A et A-prime.
Quand Bob essaie de se connecter au serveur A ou A-prime pour voir les photos d'Alice, il se présente en tant que Bob@B ou Bob@B-prime, en fonction du serveur sur lequel il est connecté à l'instant t. A ou A-prime interroge alors B ou B-prime en demandant sur finger la clé publique de Bob@B ou Bob@B-prime, et en demandant de prouver que le serveur B ou B-prime possède bien la clé privée de Bob en résolvant un petit challenge cryptographique, afin d'éviter les usurpations de clé publique.
Si tout est OK, A ou A-prime donne l'accès aux photos d'Alice à Bob.
Si demain Bob crashe ses 2 serveurs et perd son nom de domaine, mais a fait une sauvegarde de son profil dans un fichier json, il pourra charger son profil sur un autre serveur C en conservant ses fameux identifiants cryptographiques. Il pourra alors se présenter au serveur A d'Alice en tant que Bob@C. Le serveur A retrouvera bien la clé publique de Bob sur le serveur C. Le serveur C pourra prouver sa légitimité en résolvant le challenge à l'aide de la clé privée que Bob lui a fournie, et Bob pourra accéder aux photos d'Alice sans qu'Alice n'ait besoin de modifier quoi que ce soit.
# Hubzilla
Posté par Papey . En réponse au journal Besoin d'aide pour finir la dépêche sur les alternatives pour un réseau social familial. Évalué à 4.
Salut à tous,
j'ai complété un peu l'article pour la partie Hubzilla. La vraie particularité de ce réseau est la gestion des authentifications et des droits d'accès, qui est complètement décentralisée. J'ai essayé de mettre un exemple pour qu'on puisse bien comprendre. A mon sens ce modèle d'authentification mériterait d'être généralisé car il est extrêmement puissant.
Je n'ai pas voulu trop charger le projet de dépêche, mais pour les curieux voici le principe en plus détaillé :
Alice a un profil sur le serveur A. L'identité de son profil est liée à une clé publique associée à une clé privée stockées toutes les deux sur le serveur A. La clé publique est accessible via finger depuis l'internet publique, en envoyant une requête sur le profil "Alice@A" sur le serveur A.
Si elle le souhaite, Alice peut cloner son profil sur le serveur A-prime. Ce profil cloné aura pour adresse Alice@A-prime, et aura le même identifiant cryptographique (clé privée/clé publique). Alice peut aussi choisir de synchroniser ses données (photos, messages, fichiers) entre les deux serveurs.
Il en va de même pour Bob qui a un profil sur son propre serveur "B", cloné sur B-prime.
Si Alice veut donner accès à ses photos intimes à Bob, le serveur qu'elle utilise (A ou A-prime) récupère la clé publique de Bob à partir interrogeant via finger le serveur B ou le serveur B-prime. Elle stocke cette clé dans la liste de contrôle d'accès de ses photos sur les serveurs A et A-prime.
Quand Bob essaie de se connecter au serveur A ou A-prime pour voir les photos d'Alice, il se présente en tant que Bob@B ou Bob@B-prime, en fonction du serveur sur lequel il est connecté à l'instant t. A ou A-prime interroge alors B ou B-prime en demandant sur finger la clé publique de Bob@B ou Bob@B-prime, et en demandant de prouver que le serveur B ou B-prime possède bien la clé privée de Bob en résolvant un petit challenge cryptographique, afin d'éviter les usurpations de clé publique.
Si tout est OK, A ou A-prime donne l'accès aux photos d'Alice à Bob.
Si demain Bob crashe ses 2 serveurs et perd son nom de domaine, mais a fait une sauvegarde de son profil dans un fichier json, il pourra charger son profil sur un autre serveur C en conservant ses fameux identifiants cryptographiques. Il pourra alors se présenter au serveur A d'Alice en tant que Bob@C. Le serveur A retrouvera bien la clé publique de Bob sur le serveur C. Le serveur C pourra prouver sa légitimité en résolvant le challenge à l'aide de la clé privée que Bob lui a fournie, et Bob pourra accéder aux photos d'Alice sans qu'Alice n'ait besoin de modifier quoi que ce soit.