Il arrive souvent que l'on souhaite mettre en place une communication automatique entre un client et un serveur, communication devant passer par un réseau non sécurisé (typiquement Internet), mais aucun des deux communicants ne sachant parler SSL. Un exemple typique est une connexion vers une base de données (nous supposons que les risques associés à l'accessibilité d'une base de données depuis Internet sont limités par des filtres de paquets ou tout autre mécanisme; ne mettez jamais en ligne une base de données sans la protéger !).

Stunnel, développé par Michal Trojnara, est un outil qui permet de répondre à ce besoin. Il s'agit d'un programme permettant de SSL-iser un couple client/serveur, sans la moindre modification du code des clients et serveurs en question. Le résultat est une communication transparente entre le client et le serveur, avec SSL grâce à Stunnel (qui s'interpose entre le client et le serveur) :

1. le client dialogue en clair et en local (généralement) avec un processus Stunnel,
2. configuré pour dialoguer de manière chiffrée avec un second processus Stunnel,
3. lequel dialogue en clair et en local avec le serveur.

La figure 1 présente le schéma général des échanges.

Il est à noter que rien n'oblige à ce que STunnel fonctionne aux deux extrémités de l'échange réseau. STunnel peut être utilisé

• uniquement sur le client, pour que des programmes non SSL-isés puissent dialoguer avec un serveur SSL (lynx sans SSL avec un serveur Web SSL par exemple), ou
• uniquement sur le serveur, pour que des programmes ne faisant que du SSL puissent dialoguer avec un serveur incapable d'accepter une connexion chiffrée.

Installation de Stunnel

Les sources de Stunnel sont disponibles sous licence GPL. La compilation et l'installation ne posent pas de difficultés particulières :

$ ./configure
$ make
# make install

L'utilitaire configure propose diverses options pour la gestion de l'installation. La commande

$ ./configure --help

vous permettra d'examiner toutes les options possibless la majeure partie concernant les répertoires d'installation

L'installation doit être exécutée par l'utilisateur root. L'exécutable (stunnel) est, par défaut, placé dans le répertoire /usr/local/sbin. Le fichier de configuration d'exemple (stunnel.conf-sample) et un certificat SSL autosigné (mail.pem) sont normalement placés dans /usr/local/etc/stunnel.

Configuration de Stunnel

La configuration de stunnel ne se fait plus par des options sur la ligne de commande, mais par l'intermédiaire d'un fichier (/usr/local/etc/stunnel/stunnel.conf par défaut).

Stunnel peut fonctionner dans deux modes :

• en mode serveur, il reçoit des connexions (SSL), procède au décodage et renvoie le résultat vers un port local. Il s'agit, comme le nom l'indique, de l'extrémité donnant accès au service protégé.
• en mode client, il reçoit des données en clair sur un port déterminé et met en place une connexion vers un service SSL.

Un même fichier de configuration peut mélanger des services de type "serveur" et des services de type "client".

Configuration simple

Un service est défini par une chaîne placée entre crochets. Les principales directives sont :

• accept : port (forcément local) sur lequel STunnel attendra des connexions. Obligatoire.
• connect : port (ou machine:port) sur lequel STunnel renverra les données reçues sur le port précédent. Obligatoire.
• client : définition du type de fonctionnement de STunnel pour ce service.

Si client = yes, STunnel fonctionne en mode client. STunnel mettra alors en place une connexion SSL vers le port (la machine/le port) indiqué(e) par la directive connect. A l'inverse, si client = no (ou en l'absence de la directive client), STunnel fonctionnera en mode serveur. Les connexions reçue sur le port défini par accept doivent alors être des connexions SSL, qui seront décodées et transmises vers le port (ou vers la machine:port) indiqué(e) par la directive connect.

Une remarque : si tous les ports définis par des directives accept sont supérieurs à 1024, STunnel pourra être lancé par un utilisateur non privilégié. Sinon, il faudra que STunnel soit lancé par le super-utilisateur.

Par exemple :

[6543]
accept = 6543
connect = une.machine.tld:443
client = yes

définit un service écoutant sur le port 6543, en mode client, et routant ensuite les données vers le port 443 de une.machine.tld. Cet exemple correspond à l'utilisation d'un client incapable de dialoguer en SSL, afin d'accéder à un serveur SSL. Le client est configuré pour dialoguer, en local, avec STunnel sur le port 6543 (dialogue en clair, donc), et SSL est géré par STunnel.

La définition d'un service de type serveur est identique, à l'exception de la directive client :

[443]
accept = 443
connect = 4433

Dans le cas précédent, STunnel écoute sur le port 443, décodera les connexions SSL qu'il reçoit sur ce port et transmettra les données (en clair) sur le port local 4433.

Nous soulignerons que rien n'oblige les connexions en clair à être strictement locales, de même que les connexions SSL n'ont aucune obligation à être faites vers un système distant (mais l'utilisation de SSL pour une connexion purement locale à la machine ne présente qu'un intérêt limité). Il est donc tout à fait possible de configurer un service comme

[1234]
accept = 1234
connect = un.systeme.ailleurs:4321

Les données reçues sur le port 1234 (terminaison d'une connexion SSL, puisqu'il s'agit ici d'un service de type serveur) sont, après déchiffrement, renvoyées vers le port 4321 sur un.systeme.ailleurs. Il est évident, toutefois, qu'avec une telle configuration les données reçues vont ensuite transiter en clair entre la machine sur laquelle s'exécute STunnel et la véritable destination (un.systeme.ailleurs). Cela ne peut être envisagé que si le chemin réseau entre ces deux systèmes est totalement sous votre contrôle et bien sécurisé.