Échanger des secrets entre serveurs (peering) #23

Open
opened 2020-04-14 19:53:46 +00:00 by southerntofu · 3 comments
Owner

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:

  • pouvoir itérer sur l'ensemble des pairs depuis un script shell, donc virer le compte peer du dossier des pairs
  • s'échanger nos adresses IP avec les pairs comme Proof Of Concept
  • potentiellement, supporter plus de types de clés?
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: - [ ] pouvoir itérer sur l'ensemble des pairs depuis un script shell, donc virer le compte peer du dossier des pairs - [ ] s'échanger nos adresses IP avec les pairs comme Proof Of Concept - potentiellement, supporter plus de types de clés?
southerntofu added the
fonctionnalité
dur
labels 2020-04-14 19:53:46 +00:00
southerntofu self-assigned this 2020-04-14 19:53:47 +00:00
Author
Owner

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 :

peers:
  - name: tilde.netlib.re 
    client_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEHsVZvvVX3VPj2sWxrb8LJrn3650aoLAZgbY7+CB+NU"
    server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG"

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:

  • découvrir les adresses IPv4/IPv6 des pairs sans faire confiance au DNS
  • échanger les clés TSIG (symétriques) de façon sécurisée entre serveurs de noms, pour sécuriser les échanges de zones par la suite

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.

# 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 : ``` peers: - name: tilde.netlib.re client_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEHsVZvvVX3VPj2sWxrb8LJrn3650aoLAZgbY7+CB+NU" server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG" ``` 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](#peering) 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: - découvrir les adresses IPv4/IPv6 des pairs sans faire confiance au DNS - échanger les clés TSIG (symétriques) de façon sécurisée entre serveurs de noms, pour sécuriser les échanges de zones par la suite 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.
southerntofu changed title from Échanger des secrets entre serveurs to Échanger des secrets entre serveurs (peering) 2020-04-14 20:08:26 +00:00
Author
Owner

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:

peers:
  - name: tilde.netlib.re 
    client_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEHsVZvvVX3VPj2sWxrb8LJrn3650aoLAZgbY7+CB+NU"
    server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG"

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/:

  • fr.tild3.org -> /home/peers/self/
  • self/
    • shared/ (shared info about localhost)
      • tilde.netlib.re/ (shared secrets)
    • .ssh/
      • id_ed25519[.pub] (local SSH key for peering)
      • known_hosts (known public keys for peer SSH servers)
  • tilde.netlib.re/
    • host -> /home/peers/self/shared/
    • .ssh/
      • authorized_keys (known public keys for peer SSH client)

Applications

nameserver

The nameserver role uses the peering system for:

  • discovering IPv4/IPv6 addresses of peers without trusting the DNS (so that we can interop with hosts that don't support DNSSEC)
  • exchange TSIG (symmetric) keys in a secure manner between name servers, so that further zone exchanges are secure

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:

  • if ~peer/shared/PEER/dns/tsig.key exists, we already have a key.
  • if ~PEER/dns/tsig.key exists, it is moved to ~peer/shared/PEER/dns/tsig.key and we have found the key
  • otherwise, we generate a TSIG key, send it to the PEER server in ~/dns/tsig.key, then copy it to ~/peer/shared/PEER/dns/tsig.key

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.

# 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: ``` peers: - name: tilde.netlib.re client_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEHsVZvvVX3VPj2sWxrb8LJrn3650aoLAZgbY7+CB+NU" server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG" ``` 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](#peering) 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/: - fr.tild3.org -> /home/peers/self/ - self/ - shared/ (shared info about localhost) - tilde.netlib.re/ (shared secrets) - .ssh/ - id_ed25519[.pub] (local SSH key for peering) - known_hosts (known public keys for peer SSH servers) - tilde.netlib.re/ - host -> /home/peers/self/shared/ - .ssh/ - authorized_keys (known public keys for peer SSH client) ### Applications #### nameserver The nameserver role uses the peering system for: - discovering IPv4/IPv6 addresses of peers without trusting the DNS (so that we can interop with hosts that don't support DNSSEC) - exchange TSIG (symmetric) keys in a secure manner between name servers, so that further zone exchanges are secure 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: - if ~peer/shared/PEER/dns/tsig.key exists, we already have a key. - if ~PEER/dns/tsig.key exists, it is moved to ~peer/shared/PEER/dns/tsig.key and we have found the key - otherwise, we generate a TSIG key, send it to the PEER server in ~/dns/tsig.key, then copy it to ~/peer/shared/PEER/dns/tsig.key ### 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.
Author
Owner

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.

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.
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tilde-fr/infra#23
No description provided.