C’est presque devenu un réflexe, dès que nous installons un service web : nous le sécurisons avec connexion HTTPS.

En vrai, le bon réflexe, c’est surtout de se poser systématiquement la question : « est-ce pertinent pour ce service ? ». Et si la réponse est oui, installer les certificats et configurer la connexion.

Après avoir installé matomo dans notre réseau privé et avoir configuré la remontée des logs, on pourrait en effet se demander « mais pourquoi tant d’efforts ? Ça n’est accessible qu’en local ! ». La réponse tiens en deux points :

1. Les données personnelles. Les requêtes effectuées par le traceur javascript sont, par définition des données à caractère privé et doivent être protégées contre les modifications et les accès frauduleux. De même, si vous avez oublié d’anonymiser les résultats, ceux-ci aussi doivent être protégés (en attendant d’être anonymisés bien sûr 😉).
2. La défense en profondeur. Même si nous n’utilisons pas le traceur, que vos données sont anonymisées et que le serveur n’est accessible qu’en local et les statistiques seulement après un contrôle d’accès, on est pas à l’abri d’une erreur.

Pour être transparents avec vous, j’apprécie quand les choses sont bien faites et mettre les mains dans le cambouis pour ces détails de certificats, ça me détend…

Déployer le certificat et la clé

Je pars du principe que vous savez déjà comment générer un certificat et sa clé. Sinon, voici comment les générer avec XCA. Par simplicité, je vais considérer aussi que vous avez exporté ces deux fichiers :

• matomo.crt pour le certificat,
• matomo.key pour la clé.

Sans surprise, ces fichiers doivent être téléversés sur votre serveur Matomo. Techniquement, vous pourriez les mettre où bon vous semble, mais la tradition a prévu deux répertoires prévu pour ça :

Comme toutes les traditions, vous pouvez jouer au rebelles, ça marchera très bien mais vous aurez des problèmes de communication avec vos contemporains…

• /etc/ssl/certs/ pour les certificats,
• /etc/ssl/private/ pour les clés.

L’intérêt d’utiliser ces deux répertoires, c’est qu’ils sont déjà configurés pour minimiser les risques de fuites de ces données sensibles.

Mais comme une boulette peut toujours arriver, on va faire de la défense en profondeur (encore et toujours) et changer les droits des deux fichiers (propriétaire root et droits d’accès) :

sudo chown root:root /etc/ssl/certs/matomo.crt
sudo chown root:root /etc/ssl/private/matomo.key
sudo chmod 640 /etc/ssl/private/matomo.key

Pourquoi l’utilisateur root et pas www-data ? Parce que lorsque le serveur d’application démarre, il le fait avec l’identité de root, pour ouvrir les ports réseaux (80 et 443 que seul root peut ouvrir) et lire sa configuration. Ce n’est qu’une fois lancé qu’il délaisse ses privilèges et passe à l’identité www-data. À ce moment là, il n’a plus aucune justification pour lire les fichiers de configuration.

Configurer le serveur web

Comme j’utilise un serveur vierge et sa configuration par défaut, je vais modifier le fichier de configuration par défaut pour les connexions HTTPS : /etc/apache2/site-available/default-ssl.conf.

Modifier la configuration. Comme on reste sur une utilisation tout ce qui a de plus classique, vous n’avez qu’à chercher les deux lignes de configuration SSL/TLS concernant le certificat et la clé et adapter le chemin vers vos fichiers. Quelque chose dans ce goût là :

SSLCertificateFile    /etc/ssl/certs/matomo.crt
SSLCertificateKeyFile /etc/ssl/private/matomo.pem

Activer HTTPS. Par défaut, votre serveur apache2 n’a pas encore activé le module (ssl) et l’hôte virtuel pour les connexions HTTPS. Leur activation se fait en trois commandes toutes bêtes :

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo service apache2 restart

Bonus HSTS

Encore une histoire de défense en profondeur, on peut également configurer le serveur web pour qu’il informe les navigateurs de ne pas le contacter via des canaux non sécurisés. On appelle ça HTTP Strict Transport Security et autrement dit, ça demande aux navigateurs de refuser de charger des ressources ou envoyer des données via HTTP et de n’utiliser que HTTPS.

Rien de compliqué à faire, il faut ajouter une ligne de configuration au vhost SSL/TLS précédent :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Pour que ça marche, il faut également activer le module headers qui gère cette ligne de configuration et qui va insérer cette en-tête aux réponses HTTP. Deux commandes à lancer et vous y serez :

sudo a2enmod headers
sudo service apache2 restart

Forcer la connexion HTTPS

Votre site est maintenant accessible en HTTPS mais certains visiteurs pourraient encore utiliser HTTP.

On pourrait bien sûr configurer apache2 pour rediriger automatiquement toutes les requêtes HTTP vers HTTPS mais comme Matomo a quelque chose de prévu en interne (c’est même expliqué dans la documentation officielle, je préfère passer par lui.

Je suis d’accord : ce n’est pas une bonne pratique de mélanger les couches et de configurer SSL partiellement dans deux systèmes différents. Mais d’expérience, ce genre de truc cache souvent une dette technique et des effets de bords imprévisibles. Alors pour éviter de perdre des heures en débogage improbables, je préfère suivre la documentation.

Pour forcer les connexions HTTPS, il faut alors modifier le fichier de configuration de matomo (depuis le répertoire de Matomo : config/config.ini) et décommenter la ligne force_ssl :

[General]
force_ssl = 1

La redirection ne se fera donc pas par apache2 mais par le PHP de matomo. Et du coup, il n’y a pas besoin d’activer le mod_rewrite sur apache.

Et après ?

Votre application et votre serveur web sont maintenant accessible via HTTPS, les communications sont sécurisées par TLS. Le HSTS permet d’éviter quelques ressources oubliées soient accédées en HTTP et Matomo va de toutes façon rediriger ces accès vers la version HTTPS.

Bien sûr, pour que ça soit vraiment sécurisé, il faut que la CA qui a signé votre certificat soit reconnue par les navigateurs de vos utilisateurs. Si vous avez votre propre PKI, ça implique de déployer votre CA chez vos visiteurs.

C’est le cas des arsouyes. Comme nous n’utilisons pas le javascript mais les fichiers de logs, notre Matomo n’est accédé que par les arsouyes pour lire les rapports. Et comme nous avons d’autres applications internes utilisant TLS avec des certificats signés par notre PKI, nous avions déjà déployé notre CA sur nos navigateurs.

Si votre matomo doit pouvoir être accessible par n’importe qui, il va être difficile de déployer votre CA partout. Dans ce cas, passer par une CA déjà reconnue vous facilitera la tâche (et dans ce cas, vous pourriez utiliser lets encrypt).