Échanger des secrets entre serveurs (peering) #23
Labels
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tilde-fr/infra#23
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Il est très pratique de pouvoir s'échanger des données de façon sécurisée entre serveurs, par exemple pour s'échanger des clés publiques ou des secrets.
L'approche standard pour se connecter à un serveur est le protocole SSH. Le problème est qu'il faut pouvoir connaître la clé publique du serveur, et le serveur doit connaître la clé publique de notre client (et vice-versa pour une connexion de l'autre serveur chez nous).
Un premier jet pour mettre ça en place a été implémenté. Toutefois, pour pouvoir clore ce ticket, il faut:
Brouillon de manuel
Ce message sera mis à jour de nombreuses fois. La version francophone est la plus à jour sauf si le contraire est spécifié.
Configuration
peers
Définit les serveurs pairs (amis), et nous permet d'échanger de façon sécurisée des données avec eux. Chaque peer est un dictionnaire contenant les clés suivantes :
Les clés publiques définies ci-dessus (transmise par unE admin de l'autre serveur) nous permet à la fois d'identifier le serveur quand on s'y connecte (grâce à la server_key), et le client qui se connecte chez nous de là-bas (la client_key).
Le mécanisme de peering est décrit plus loin dans le manuel.
Plus loin
Peering
Le peering est un mécanisme de communication de serveur à serveur sécurisé par SSH. En utilisant des noms d'utilisateurices bien connus (well-known), on peut établir un échange bidirectionnel sécurisé avec un serveur en conaissant simplement son nom de domaine, la clé publique de son serveur SSH, et la clé publique de son client SSH.
En effet, chaque serveur crée un compte dédié
peer
et une clé SSH correspondante qui lui permet de s'authentifier auprès des autres serveurs. Pour se faire, le serveur se connecte (c'est donc un client) avec pour nom de compte son propre hostname, sur le serveur distant.Par exemple, quand fr.tild3.org veut partager un secret avec tilde.netlib.re, peer@fr.tild3.org se connecte en SSH à fr.tild3.org@tilde.netlib.re.
Fonctionnement
Le dossier
host
dans les comptes des pairs est un lien symbolique vers /home/peers/self/shared, qui est un dossier accessible uniquement en lecture par les pairs se connectant au serveur.Ce dossier host permet au serveur de renseigner un pair qui chercherait des informations à son propos (pull). Le reste du dossier peut être librement utilisé par le pair pour transmettre des informations au serveur (push).
Additionnellement, le dossier host contient un dossier au nom de chaque pair, qui est accessible en lecture seule et à ce serveur pair seulement, et qui contient une copie des secrets envoyés au pair depuis cette machine.
A priori, et sauf si le contraire est spécifié, les fichiers bien connus (well-known) suivent le même adressage dans le dossier host/ (pull) que dans le dossier ~ (push), à ceci près qu'un fichier secret sera placé dans le sous-dossier dédié au pair dans le dossier host.
Ce mécanisme permet de vérifier si un secret correspondant a déjà été généré par un serveur pair PEER, et de le générer sinon. S'apercevant qu'un secret vient d'être partagé avec lui par un pair, un serveur le copie automatiquement au dossier /home/peers/self/shared/PEER avec les permissions confiées à PEER (770). Ainsi, même si PEER perd connaissance de ce secret, il peut le retrouver.
Applications
nameserver
Le rôle nameserver utilise le système de peering pour:
La découverte des adresses IPv4 se fait dans le dossier host/ip. Ce dossier contient un fichier v4 où chaque ligne est une adresse IPv4 valide pour le serveur, et un fichier v6 où chaque ligne est une adresse IPv6 valide pour le serveur.
La découverte de la clé TSIG partagée avec un pair (c'est un clé symétrique donc on en a une pour chaque paire de serveurs) se fait d'abord en local, pour s'assurer qu'un pair ne nous a pas transmis son secret.
On va vérifier dans le fichier /home/peers/PEER/dns/tsig.key. Si le fichier existe, mais que /home/peers/self/shared/PEER/dns/tsig.key n'existe pas, alors le fichier est copié et on a trouvé notre clé TSIG.
Sinon, on génère une clé TSIG et on se connecte au serveur PEER. On envoie la clé dans le fichier nameserver/tsig.key, et on attend que le serveur en prenne connaissance. D'ici là, on a trouvé (enfin généré) notre clé.
Sécurité
À terme le serveur devrait restreindre les serveurs pairs à leur dossier personnel (chroot), et permettre seulement l'échange de fichier par scp/sftp/rsync. Ce n'est pas encore le cas. De même, la lecture du dossier /home/peers devrait être interdite à toute personne, sauf /home/peers/self qui est public, mais dont les sous-dossiers de shared pour chaque pair sont privés.
Le processus de peering est plutôt sécurisé, mais nécessite de s'échanger au préalable des clés publiques. Cet échange doit être fait sur un canal de confiance.
Échanger des secrets entre serveursto Échanger des secrets entre serveurs (peering)Draft manual
This message may be updated many times. The french-speaking version is the most updated unless otherwise is said. Right now, how it works is more updated in english.
Configuration
peers
Defines a list of friendly peer servers, and allows us to securely exchange data with them through SSH. Each peer is a dictionary holding those keys:
The public keys defined above (as given by an admin of the server) allows us to identify the server when we connect to it (thanks to server_key) and when it connects to us (client_key).
The peering mechanism is described later in the manual.
Later
Peering
Peering is a server-to-server communication mecanism, secured by SSH. By using well-known usernames, we can establish bidirectionnal secure connection with a server, by knowing the public keys of its SSH server and SSH client.
Each server creates a dedicated
peer
account and an associated SSH key which allows it to identify to other servers. To this end, the server connects to another peer with its own hostname.For example, when fr.tild3.org wants to share something with tilde.netlib.re, peer@fr.tild3.org connects to fr@tild3.org@tild3.netli.re via SSH.
How it works
For each peer server PEER it knows of, the server will create a local account with a home directory pointing to /home/peers/PEER. The folder
host
in this home directory is a symbolic link to /home/peers/self/shared, which is read-only for peers and writable by the local peer account.This folder allows the server to share informations with peers (pull). The rest of the /home/peer/PEER/ folder is freely used by PEER to share information with our server (push).
Additionally, the host directory contains directories named after each peer, which are read-only to the corresponding peer only. This folder contains a copy of secrets sent to or received from this peer.
Unless specified otherwise, well-known files follow the same structure in the ~/host/PEER folder (pull) than in the ~/ folder (push). Only secrets are handled differently, being placed in the folder mentioned previously.
This mechanism allows us to verify if a secret for a peer has already been generated by them, and to generate it otherwise. Upon encountering a secret shared by peer server PEER, the server automatically moves it to /home/peers/self/shared/PEER with read-only permissions for PEER (user: peer, group: PEER, mode: 740). Thus, even if PEER loses knowledge of this secret, it can retrieve it.
Here's the layout of /home/peers/:
Applications
nameserver
The nameserver role uses the peering system for:
Discovering IP addresses is done in the ~PEER/ip/ folder. If this folder does not exist, we connect to the PEER server and look for ~/host/ip/ folder. The ip/ folder contains a v4 file where each line is a valid IPv4 for PEER, and a v6 file where each line is a valid IPv6 for PEER.
Address updates are propagated by updating your own ~/ip/ folder on peer servers.
Discovering the TSIG key shared with a peer (it's symmetric so we generate one for each pair of servers) is done in the same manner:
Security
Each server should restrain remote peers to their personal folder via chrooting, and only permit file exchange through scp/sftp/rsync. This is not the case yet.
Reading /home/peers folder should be forbidden to other users on the machine, except /home/peers/self which is public, but for which peer subfolders in
shared
folder are private.The peering process in itself is rather secure, but requires to exchange public keys in advance. This exchange must take place on a secure channel.
Note: c'est assez dérangeant tout cet ensemble de fichiers. Ça mérite d'y reréfléchir et de voir si tout ne peut pas tenir dans un dossier /peers qui serait $HOME pour le compte peer.