stunnel - tunnel SSL universel
stunnel [filename] | -help | -version | -sockets
Le programme stunnel est conçu pour agir en tant que wrapper de chiffrement SSL entre des clients distants et des serveurs locaux (activables par inetd) ou distants. Le concept est qu'ayant des daemons non-SSL sur votre système, il est possible de les configurer aisément pour communiquer avec des clients sur des canaux SSL sécurisés.
stunnel peut être utilisé pour ajouter une fonctionnalité SSL à des daemons Inetd communs, tels que les serveurs POP-2, POP-3 et IMAP, à des daemons autonomes tels que NNTP, SMTP et HTTP et pour tunneliser PPP sur des sockets réseaux sans modification du code source.
Ce produit contient du code de chiffrement écrit par Eric Young (eay@cryptsoft.com)
Chaque ligne du fichier de configuration peut être soit :
C'est le répertoire dans lequel stunnel cherche les certificats avec verify. Les certificats doivent être nommés XXXXXXXX.0 où XXXXXXXX est la valeur de hachage du certificat.
Ce fichier contients plusieurs certificats utilisés avec verify.
Une PEM est toujours nécessaire en mode serveur. En mode client, cette option utilise cette chaîne comme chaîne de certificat client. L'utilisation de certificats clients est optionnelle. Les certificats doivent être au format PEM et triés par ordre de niveau décroissant (à partir de l'autorité racine).
chroot enferme stunnel dans une cellule d'arborescence. CApath, pid et exec sont disposés à l'intérieur de la cellule et les chemins doivent être relatifs au répertoire chroot.
Pour que le contrôle libwrap (TCP wrappers) soit effectif en environnement chroot, il faut y copier ses fichiers de configuration (/etc/hosts.allow et /etc/hosts.deny).
Liste délimitée des codages à autoriser dans une connexion SSL. Par exemple : DES-CBC3-SHA:IDEA-CBC-MD5
défaut: no (mpde serveur)
Le niveau est en phase avec ceux de syslog : emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6), ou debug (7). Toutes les traces de niveau inférieur ou égal numériquement seront affichées. debug = debug ou debug = 7 donne le niveau de détail maximal. La valeur par défaut est notice (5).
La facilité syslog 'daemon' sera utilisée par défaut (les facilités ne sont pas supportées par Win32).
La casse des caractères est sans signification.
Socket d'EGD à utiliser pour alimenter le générateur d'aléatoires d'OpenSSL (disponible seulement à partir d'OpenSSL 0.9.5a).
Maintien en avant-plan (sans fork) et trace sur stderr au lieu de syslog (sauf si output est spécifié).
défaut : arrière-plan en mode daemon.
La clef privée est nécessaire pour l'authentification du propriétaire du certificat. Puisque ce fichier doit rester secret, il ne doit être lisible que par son propriétaire. Sous Unix on peut utiliser :
chmod 600 fichier
défaut : valeur de cert
Ce paramètre est le nome de l'option OpenSSL ainsi que décrite dans le manuel SSL_CTX_set_options(3ssl), mais sans le préfixe SSL_OP_. Plusieurs options peuvent être utilisées.
Par exemple, la compatibilité avec l'implantation défectueuse de SSL dans Eudora peut être assurée par :
options = DONT_INSERT_EMPTY_FRAGMENTS
Si l'argument est vide, aucun fichier pid ne sera créé.
Avec SSL de version inférieure à 0.9.5a, détermine aussi le nombre d'octets suffisants pour saler le PRNG. Les versions plus récentes d'OpenSSM ont une fonction intégrée qui détermine lorsque le niveau d'aléatoire est suffisant.
La bibliothèque SSL utilisera en priorité les données de ce fichier pour alimenter le générateur d'aléatoires.
défaut : yes
Sur Unix : nom de service de mode inetd pour TCP Wrapper ;
Sur NT/2000/XP : nom de service NT dans le panneau de configuration.
défaut : stunnel
setgid() vers le groupe spécifié et désactivation de
tous les autres groupes de rattachement.
setuid() vers l'utilisateur spécifié.
Les valeurs de l'option linger sont l_onof:l_linger. Les valeurs de l'option time sont tv_sec:tv_usec.
Exemples :
socket = l:SO_LINGER=1:60
positionne un timeout d'une minute pour la clôture d'un socket local.
socket = r:TCP_NODELAY=1
désactive l'algorithme Nagle pour les sockets distants.
socket = r:SO_OOBINLINE=1
place les données out-of-band directement dans le flux de réception
pour les sockets distants.
socket = a:SO_REUSEADDR=0
désactive la réutilisation d'adresses (activée par défaut).
socket = a:SO_BINDTODEVICE=lo
n'accepte les connexions que sur l'interface de rebouclage.
niveau 1 - vérification du certificat s'il est présent ;
niveau 2 - vérification du certificat ;
niveau 3 - contrôle de l'interlocuteur avec le certificat installé en local ;
défaut - pas de vérification.
Chaque section de configuration débute par le nom du service entre crochets. Celui-ci est utiliser pour le contrôle d'accès libwrap (TCP Wrappers) et permet de distinguer les services stunnel dans les fichiers de trace.
Si l'on veut utiliser stunnel en monde inetd (dans lequel un socket réseau est fourni par un serveur comme inetd, xinetd, ou tcpserver), il faut lire la section MODE INETD ci-après.
Si aucun hôte n'est spécifié, toutes les adresses IP par défaut pour l'hôte local.
Si aucun hôte n'est spécifié, connexion sur localhost.
Les guillemets ne sont pas supportés actuellement. Les arguments sont séparés par un nombre quelconque d'espaces.
Réécriture de l'adresse afin que la connexion apparaisse comme provenant de la machine client SSL plutôt que de celle exécutant stunnel. Cette option n'est disponible en mode local (option exec) qu'avec l'option LD_PRELOAD de la bibliothèque partagée env.so ou en mode distant (option connect) sur un noyau Linux 2.2 compilé avec l'option transparent proxy puis seulement en mode serveur. Cette option est incompatible avec le mode mandataire (connect) sauf si la route par défaut vers la machine cible passe par l'hôte stunnel, qui ne peut être localhost.
stunnel renvoie zéro en cas de succès, une autre valeur en cas d'erreur.
Pour encapsuler un service local imapd dans SSL :
[imapd]
accept = 993
exec = /usr/sbin/imapd
execargs = imapd
Pour tunnelliser le daemon pppd sur le port 2020 :
[vpn]
accept = 2020
exec = /usr/sbin/pppd
execargs = pppd local
pty = yes
Pour que stunnel lance le processus imapd en mode inetd, le fichier stunnel.conf sera ainsi (il ne doit y avoir aucune section [service]):
exec = /usr/sbin/imapd
execargs = imapd
L'option execargs ne supporte pas les guillemets.
stunnel ne peut être utilisé pour le daemon FTP en raison de la nature de ce protocole qui ouvre de multiples ports pour les transferts de données. Il existe cependant des versions de FTP et de telnet qui permettent l'utilisation de SSL.
L'utilisation la plus courante de stunnel est l'écoute sur un port réseau pour établir des communications, soit sur un nouveau port avec l'option connect, soit avec un programme avec l'option exec. Dans certains cas, il est souhaitable qu'un autre programme accepte les connexions entrantes puis passe la main à stunnel (par exemple avec inetd, xinetd, ou tcpserver).
Imaginons la ligne suivante dans inetd.conf :
imaps stream tcp nowait root /usr/sbin/stunnel stunnel /etc/stunnel/imaps.conf
Dans ce cas, le programme de style inetd est en charge de la connexion du socket réseau (imaps ci-dessus) et du passage à stunnel une fois la connexion reçue. Ainsi, stunnel ne doit pas avoir d'option accept/ Toutes les options de niveau service doivent être dans la section des options globales et il ne doit pas y avoir de section [service]. Se reporter à la section EXEMPLES.
Chasue daemon SSL-isé doit présenter un certificat X.509 valide à son interlocuteur. Il nécessite aussi une clef privée pour déchiffrer les données entrantes. La méthode la plus simple d'obtention d'un certificat et d'une clef est de les engendrer à l'aide du paquetage lible OpenSSL. Plus d'informations sur la génération de certificats est disponible sur les pages indiquées plus bas.
Deux points importants lors de la génération de paires certificat-clef pour stunnel : la clef privée ne peut être chiffrée car le serveur n'a aucun moyen d'accéder au mot de passe de l'utilisateur ; l'option -nodes de la commande req du kit OpenSSL permet de produire une clef non chiffrée.
L'ordre du contenu du fichier .pem est important aussi : il doit contenir la clef privée non chiffrée en premier, puis un certificat signé (pas de requête de certificat). Il doit y avoir aussi des lignes vides après le certificat et la clef privée. L'information en texte simple ajoutée sur le certificat engendré doit être supprimée. Ainsi, le fichier doit se présenter comme suit :
-----BEGIN RSA PRIVATE KEY-----
[clef encodée]
-----END RSA PRIVATE KEY-----
[ligne vide]
-----BEGIN CERTIFICATE-----
[certificat encodé]
-----END CERTIFICATE-----
[ligne vide]
stunnel doit alimenter le générateur d'aléatoires (PRNG - pseudo random number generator) pour fournir à SSL un bon niveau d'aléatoires. Les sources suivantes sont chargées dans l'ordre jusqu'à ce qu'une quantité suffisante d'informations aléatoires ait été rassemblée :
Si les versions récentes (>=OpenSSL 0.9.5a) de SSL cessent le chargement automatiquement lorsqu'une entropie suffisante a été rassemblée, ce n'est pas le cas des versions précédentes qui ne disposent pas d'une fonction permettant de déterminer cela.
Sur les machines Windows sans interaction utilisateur (mouvements de souris, création de fenêtres, etc.), le contenu de l'écran n'est pas suffisamment variable et il faut fournir un fichier d'aléatoires à l'aide de RNDfile.
Le fichier spécifié par RNDfile doit contenir des données aléatoires -- donc des données différentes pour chaque lancement de stunnel. Cela est réalisé automatiquement sauf si RNDoverwrite est utilisé. Pour la mise à jour manuelle de ce fichier, la commande openssl rand des versions récentes d'OpenSSL peut être utile.
Note importante -- si /dev/urandom est disponible, OpenSSL a pour habitude de l'utiliser, quel que soit l'état d'aléatoire, donc il sera vraisemblablement utilisé même s'il est indiqué en dernière position de la liste ci-dessus. C'est un comportement de OpenSSL, pas de stunnel.