Le blog de Genma
Vous êtes ici : Accueil » Informatique & Internet » GNU/Linux, Logiciels Libres » Cryptpad, tutoriel et critiques

Cryptpad, tutoriel et critiques

D 1er septembre 2017     H 09:17     A Genma     C 0 messages   Logo Tipee

TAGS : Planet Libre

Présentation de Cryptpad

Pour en savoir plus sur Cryptpad et son fonctionnement, ses caractéristiques et spécificités, je vous invite à lire le très bon article de NextInpact : CryptPad v1.10.0 est disponible, à la découverte du service collaboratif chiffré de bout en bout

En résumé, c’est un système de pad chiffré zeroknowledge le service ne détient pas les clefs de chiffrement utilisées par les utilisateurs en local et ne peut donc pas consulter le contenu. On parle en général de solution de bout en bout, ou E2E (End-to-end) pour les intimes. Il est donc possible de partager un document, de l’éditer à plusieurs, sans que celui-ci soit stocké en clair sur le serveur. L’usage est ainsi considéré comme privé, mais pas anonyme, prévient l’équipe qui renvoie vers l’utilisation de Tor ou d’un VPN pour ajouter un telle couche de protection.

Les fonctions apportées par Cryptpad :
 CryptPad - Pad
 CryptCode - Éditeur de code collaboratif
 CryptSlide - Présentation en markdown
 CryptPoll - Sondage

Installation de Cryptpad sur CentOS - pourquoi cette documentation ?

Le site officiel https://cryptpad.fr/ ne détaille pas assez l’installation et j’ai un peu galéré à avoir un système fonctionnel et plus abouti que de simplement suivre ce qui est indiqué sur la page de documentation par défaut qui permet de cloner le dépôt Git, de lancer l’application sur un port exotique depuis la ligne de commande...

Voir https://github.com/xwiki-labs/cryptpad/wiki/Installation-guide

Exemple de souci rencontré

On a donc des dossiers qui créés par défaut depuis l’endroit où on lance le server Cryptpad... La preuve :

[root@cryptpad tmp]# mkdir /tmp/test
[root@cryptpad tmp]# cd /tmp/test/
[root@cryptpad test]# /usr/bin/node /home/cryptpad/server.js
loading rpc module...

[2017-07-26T08:35:04.802Z] server available http://[::]:3000
Cryptpad is customizable, see customize.dist/readme.md for details
^C
[root@cryptpad test]# ls
blob  blobstage  datastore  pins

Cryptpad vient de créer des dossiers (nécessaires à son fonctionnement) depuis l’endroit où je le lance... Oui je suis en root donc il a les droit, mais quand même...

De plus, je connais mal "Node", lancer un serveur en Javascript, j’ai encore un peu de mal avec ça (je suis de la vielle école), c’est lancé sur un port exotique (3000), directement exposé, sans proxy ou autre.

Pour réussir à trouver une configuration de Nginx qui marche, j’ai du testé les différentes solutions proposées dans des issues Github du projet, car là encore, il n’y a rien dans la documentation.

Le fait que le projet propose la fourniture d’un espace de stockage aux utilisateurs enregistrés contre rémunération (cela semble être le business model) me fait penser que la documentation est volontairement pauvre pour que l’on ait à passer par eux en tant que prestataire...

De même, dans le fichier de configuration l.156 et suivante semble confirmer cette hypothèse (source du fichier

   /*
     *  If you are using CryptPad internally and you want to increase the per-user storage limit,
     *  change the following value.
     *
     *  Please note: This limit is what makes people subscribe and what pays for CryptPad
     *    development. Running a public instance that provides a "better deal" than cryptpad.fr
     *    is effectively using the project against itself.
     */
    defaultStorageLimit: 50 * 1024 * 1024,

Mais le plus gênant pour moi - je vous laisse juger - toujours dans ce même fichier :

    /*
     *  By default, CryptPad also contacts our accounts server once a day to check for changes in
     *  the people who have accounts. This check-in will also send the version of your CryptPad
     *  instance and your email so we can reach you if we are aware of a serious problem. We will
     *  never sell it or send you marketing mail. If you want to block this check-in and remain
     *  completely invisible, set this and allowSubscriptions both to false.
     */
adminEmail: 'i.did.not.read.my.config@cryptpad.fr',

J’aime beaucoup l’humour (i.did.not.read.my.config = je ne lis pas mon fichier de configuration : moi, je le lis...) mais est-ce normal que le logiciel que j’installe contacte l’éditeur. Et ce n’est pas indiqué ailleurs, bien en évidence...

Bref, voici mon tutoriel, plus complet ci-dessous.

Installation de Cryptpad

Je suis parti sur un serveur sur lequel était installé CentOS.

Installation de Cryptpad

# yum install epel-release
# yum install -y nodejs git
//Ajout d'un user cryptpad
# adduser cryptpad
# su cryptpad
// Dans /home/cryptpad on clone le depot github
$ cd /home/cryptpad
$ git clone https://github.com/xwiki-labs/cryptpad
// on deplace le contenu un cran au-dessus
$ cd /home/cryptpad/cryptpad
$ mv * ../
$ mv .* ../
$ cd ..
//Installation de cryptpad via la commande npm
$ npm install
//retour en root
# npm install -g bower
//Retour en utilisateur cryptpad
# su cryptpad
$ bower install --allow-root
$ cd /home/cryptpad/
//Copie du fichier de configuration par defaut
$ cp config.example.js config.js
//Changement des droits
chmod -R 755 /home/cryptpad/
//Il faut créer / copier le dossier customize pour que les pads anonymes soient actifs et sauvegardés
cp -r customize.dist/ customize/

Ouverture du port sur le firewall

Pour activer l’ouverture du port 3000 :

#  firewall-cmd --zone=public --add-port=3000/tcp  --permanent
success
# firewall-cmd --reload
success
# firewall-cmd --zone=public --list-ports
3000/tcp

Lancement de cryptpad

Depuis la ligne de commande, permet de lancer cryptad pour faire de tests temporaires :

$ node ./server.js

Installation en tant que service (Systemd)

Création d’un fichier /etc/systemd/system/cryptpad.service qui contient :

[Unit]
Description=cryptpad
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/node /home/cryptpad/server.js
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=cryptpad-app
User=cryptpad
Group=cryptpad
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/home/cryptpad

[Install]
WantedBy=multi-user.target

Installation de Nginx comme proxy

Comme indiqué dans mes critiques, j’ai passé du temps à tester différents configurations pour finir par trouver celle qui marche

Exemple de fichier de configuration nginx :
https://github.com/xwiki-labs/cryptpad/blob/master/docs/example.nginx.conf

Fichier de configuration nginx qui marche :

[root@cryptpad cryptpad]# cat /etc/nginx/conf.d/cryptpad.conf
map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
}

upstream wscrypt {
        server 127.0.0.1:3000;
}

server {
    listen       80;
    server_name cryptpad.monserveur.com;
    return 301 https://cryptpadpad.monserveur.com$request_uri;
}

server {
    listen 443 ssl;

    server_name cryptpad.monserveur.com;
    ssl_certificate         /etc/moncertificat.crt;
    ssl_certificate_key     /etc/moncertificat.key;
    ssl_trusted_certificate /etc/gandi_SSLCA2.pem;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE
    # ECDHE better than DHE (faster)  ECDHE & DHE GCM better than CBC (attacks on AES)  Everything better than SHA1 (deprecated)
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA';
    ssl_prefer_server_ciphers on;

  location / {
        proxy_pass http://wscrypt;
  }

  location /cryptpad_websocket {
        proxy_pass http://wscrypt/cryptpad_websocket;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
  }

}

Configuration du firewall

# firewall-cmd --add-service=http
# firewall-cmd --add-service=https
# firewall-cmd --runtime-to-permanent
# firewall-cmd --reload

Pour vérifier :

# firewall-cmd --list-services

Sauvegarde des pads et des utilisateurs

Le dossier contenant toutes les données (pad et comptes utilisateurs) se situe dans le dossier datastore. Le transfert de de dossier permet de migrer d’une instance Cryptpad à une autre. (Il suffit de réinstaller une instance CryptPad et de copier coller le contenu du dossier datastore sauvegardé).

Cryptpad et Yunohost

Pour celles et ceux qui ont une instance Yunohost, et qui seraient intéressées par l’application Cryptpad, celle-ci est packagée et disponible ici : https://github.com/YunoHost-Apps/cryptpad_ynh et il y a un sujet de discussion sur le forum.

Soucis à la mise à jour...

Une nouvelle version est sortie corrigeant une faille de sécurité étant sortie, j’ai donc fait la mise à jour / migration vers la nouvelle version.

Reprend le guide officiel https://github.com/xwiki-labs/cryptpad/wiki/Installation-guide avec des compléments :

Faire une sauvegarde avant

# cp -rv /home/cryptpad /Backup/cryptpad_avant_migration

cd /home/cryptpad
git pull
npm update
bower update

# Manquant dans la documentation
# Sinon, on a toujours les anciens skins/design pour l'interface.
# yes |cp -rv ./customize.dist/ ./customize/

Et surtout IL FAUT PURGER / VIDER LE CACHE DU NAVIGATEUR pour éviter tout conflit / soucis de rafraîchissement.

Reste à faire

Pour moi, il me reste à faire une intégratin de LDAP, l’ajout éventuel d’une base de données pour le stockage des pads, la charge en fonction du nombre d’utilisateurs... vu que le serveur sera utilisé au quotidien par les équipes de l’entreprise où je travaille.

Et comprendre où / comment on a des logs... Car là ça utilise "node".