Description
Note : merci de ne pas confondre le protocol Gemini avec l’assistant IA de G*** !
Vger et gmid sont tous deux principalement des serveurs pour le protocol Gemini, sous OpenBSD, utilisant tous les deux les mécanismes sécurisés systèmes.
Vger
Pendant plusieurs années, j’ai utilisé Vger, parce que je “cotoyais” Solene Rapenne, dans le petit monde de la communauté francophone autour d’OpenBSD. Elle est la créatrice de ce logiciel, qui utilise les verroux de sécurité système d’OpenBSD, pour publier sur le protocol Gemini.
Vger fonctionne très bien, sans soucis particulier, mais il nécessite deux, trois configurations qui personnellement me déplaisent :
- l’utilisation du service inetd.
- l’utilisation d’un proxy, que ce soit relayd ou nginx
- la gestion du multi-hosting que je trouve bizarre.
inetd
En effet, Vger nécessite l’utilisation du démon inetd ; il faut veiller à ce qu’inetd n’écoute que localhost.
Pour rappel, le service inetd est configuré ainsi :
127.0.0.1:1965 stream tcp nowait _vger /usr/local/bin/vger vger -d /var/gemini -v
[::1]:1965 stream tcp6 nowait _vger /usr/local/bin/vger vger -d /var/gemini -v
L’option -v est l’option de vger qui permet de cibler les domaines selon les noms de répertoires dédiés, qui doivent absolument être correspondants.
proxy
Dans le contexte de proxy avec nginx, cela nécessite d’utiliser la directive stream pour “encapsuler” le flux à destination du serveur Gemini et le relayer vers le service d’écoute locale.
La problèmatique à laquelle j’ai été confronté dans le contexte de multi-hébergements de domaine, c’est la gestion des certificats TLS. Même en utilisant les directives proxy_ssl* pour cibler les certificats, le nom de serveur, etc, les domaines interrogés sur le protocole répondaient avec le certificat lié au premier nom de domaine trouvé dans la configuration.
Ainsi la configuration des directives server suivantes :
server {
listen addresse_ipv4:1965 ssl;
listen [addresse_ipv6]:1965 ssl;
server_name domaine1.net;
access_log logs/domaine1.net/access.gemini.log basic;
ssl_certificate /etc/letsencrypt/live/domaine1.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domaine1.net/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/domaine1.net/chain.pem;
ssl_ciphers TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_ecdh_curve X25519:P-521:P-384:P-256;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.3 TLSv1.2;
proxy_pass $backend;
proxy_ssl on;
proxy_ssl_certificate /etc/letsencrypt/live/domaine1.net/fullchain.pem;
proxy_ssl_certificate_key /etc/letsencrypt/live/domaine1.net/privkey.pem;
proxy_ssl_ciphers TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_server_name on;
proxy_ssl_trusted_certificate /etc/letsencrypt/live/domaine1.net/chain.pem;
proxy_ssl_verify on;
}
server {
listen addresse_ipv4:1965 ssl;
listen [addresse_ipv6]:1965 ssl;
server_name domaine2.com;
access_log logs/domaine2.com/access.gemini.log basic;
ssl_certificate /etc/letsencrypt/live/domaine2.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domaine2.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/domaine2.com/chain.pem;
ssl_ciphers TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_ecdh_curve X25519:P-521:P-384:P-256;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.3 TLSv1.2;
proxy_pass $backend;
proxy_ssl on;
proxy_ssl_certificate /etc/letsencrypt/live/domaine2.com/fullchain.pem;
proxy_ssl_certificate_key /etc/letsencrypt/live/domaine2.com/privkey.pem;
proxy_ssl_ciphers TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_server_name on;
proxy_ssl_trusted_certificate /etc/letsencrypt/live/domaine2.com/chain.pem;
proxy_ssl_verify on;
}
Ne fonctionne pas comme attendu :
- les logs ne sont écrits que selon la directive écrite dans le premier domaine, jamais relativement à celle liée au domaine
- le certificat retourné est celui du premier domaine.
Du fait de la configuration de vger, quand un domaine est appelé, c’est bien les fichiers déposés dans le répertoire au nom du domaine, qui sont envoyés.
J’ai certainement loupé quelque chose dans la configuration de nginx, en tant que proxy…
J’aurais pu m’attarder plus sur celle de relayd, qui aurait certainement été fonctionnelle “dès le premier coup”.
J’imagine qu’une configuration de relayd pourrait fonctionner, tel que :
log connection
table <localhost> { 127.0.0.1, ::1 }
tcp protocol "gemini4dom1" {
tls keypair domain1.tld
}
tcp protocol "gemini4dom2" {
tls keypair domaine2.com
}
relay "gem4dom1" {
listen on domain1.tld port 1965 tls
protocol "gemini4dom1"
forward to <localhost> port 1965
}
relay "gem4dom2" {
listen on domaine2.com port 1965 tls
protocol "gemini4dom2"
forward to <localhost> port 1965
}
ou pas.
Bref, Vger est fonctionnel… mais compliqué à gérer !
De plus, 3 services/démons exécutés pour un serveur ; même si ces services consomment peu de ressources systèmes, je trouve que ça en fait… deux de trop !
Gmid
Et puis, j’ai découvert gmid et ses fonctionnalités natives dont la configuration est aussi aisé que relayd ou httpd sous OpenBSD, et l’usage du démon aussi simple.
Donc, j’ai créé une configuration pour les différents domaines (et sous-domaines que je gère) qui m’a pris moins de 5 minutes à faire, et à être fonctionnel, tout en restant aussi sécurisé que vger.
Et au moins avec gmid, je n’ai qu’un seul service à l’écoute, et une facilité accrue de configuration.
Si vous voulez en savoir plus sur la configuration et l’utilisation de gmid, merci de lire l’article dédié : gmid ;-)
Voilà !