stunnel peut être utilisé pour ajouter des fonctionnalités SSL à des daemons classiques Inetd tels que les serveurs POP-2, POP-3 et IMAP, à d'autres autonomes tels que NNTP, SMTP et HTTP, ainsi que pour tunneliser PPP sur des sockets réseau sans modification du code source.
Ce produit inclut du code de chiffrement écrit par Eric Young (eay@cryptsoft.com)
C'est le répertoire dans lequel stunnel cherche les certificats si l'on utilise verify. Les certificats doivent être dénommés selon la forme XXXXXXXX.0, où XXXXXXXX est la valeur de hachage du certificat.
Le cas échéant, le répertoire CApath est relatif au répertoire chroot.
Ce fichier, utilisé avec verify, contient plusieurs certificats de CA.
Une PEM est toujours nécessaire en mode serveur. En mode client, cette option utilise cette PEM comme une chaîne côté client. L'utilisation de certificats côté client est optionnelle. Les certificats doivent être au format PEM et triés par ordre de niveau décroissant (CA racine en premier).
chroot enferme stunnel dans une cellule chroot. CApath, CRLpath, pid et exec sont situés à l'intérieur de la cellule et les répertoires doivent être relatifs au répertoire correspondant.
Pour que le contrôle de libwrap (wrappeur TCP) soit effectif dans un environnement chroot, il faut aussi y recopier leurs fichiers de configuration (/etc/hosts.allow et /etc/hosts.deny).
Liste délimitée par deux-points (« : ») des chiffres autorisés pour la connexion SSL. Exemple : DES-CBC3-SHA:IDEA-CBC-MD5
Par défaut : no (mode server)
C'est le répertoire dans lequel stunnel recherche les CRL avec l'option verify. Les CRL doivent être dénommés selon la forme XXXXXXXX.0 où XXXXXXXX est la valeur de hachage de la CRL.
Le cas échéant, le répertoire CRLpath est relatif au répertoire chroot.
Ce fichier, utilisé avec verify, contient plusieurs CRL.
Le niveau est un nom ou un numéro conforme à ceux de syslog : emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6) ou debug (7). Toutes les traces du niveau indiqué et des niveaux numériquement inférieurs seront affichées. debug = debug ou debug = 7 donneront le maximum d'informations. La valeur par défaut est notice (5).
La facilité syslog « daemon » est utilisée, sauf si un autre nom est spécifié (Win32 ne permet pas l'usage des facilités.)
La casse est ignorée, aussi bien pour la facilité que pour le niveau.
Socket EGD à utiliser pour alimenter le générateur d'aléatoires de OpenSSL (disponible seulement si la compilation a été effectuée avec OpenSSL 0.9.5a ou supérieur).
Reste en avant-plan (sans fork) et dirige la trace sur stderr au lieu de syslog (sauf si output est spécifié).
Par défault : arrière-plan en mode daemon.
La clef privée est nécessaire pour authentifier le titulaire du certificat. Puisque ce fichier doit rester secret, il ne doit être lisible que par son propriétaire. Sur les systèmes Unix, on peut utiliser la commande suivante :
chmod 600 fichier
Par défault : Valeur de cert
Le paramètre est l'option OpenSSL décrite dans la page de man SSL_CTX_set_options(3ssl), débarassée du préfixe SSL_OP_. Plusieurs options peuvent être spécifiées.
Par exemple, pour la compatibilité avec l'implantation SSL défaillante d'Eudora, on peut utiliser :
options = DONT_INSERT_EMPTY_FRAGMENTS
/dev/stdout peut être utilisé pour afficher les traces sur la sortie standard (par exemple pour les traiter avec les outils splogger).
Si l'argument est vide, aucun fichier ne sera créé.
Le cas échéant, le chemin pid est relatif au répertoire chroot.
Avec les SSL de version inférieure à 0.9.5a, détermine aussi le nombre d'octets considérés comme suffisants pour « saler » le PRNG. Les versions plus récentes d'OpenSSL ont une fonction intégrée qui détermine lorsque l'aléatoire est suffisant.
La bibliothèque SSL utilise prioritairement les données de ce fichier pour « saler » le générateur d'aléatoire.
Par défaut : yes
Sous Unix : nom de service du mode inetd pour la bibliothèque TCP Wrapper.
Sous NT/2000/XP : nom de service NT dans le gestionnaire de tâches.
Par défaut : stunnel
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
définit un délai d'une minute pour la clôture des sockets locaux
socket = r:TCP_NODELAY=1
désactive l'algorithme Nagle pour les sockets distants
socket = r:SO_OOBINLINE=1
Place directement les données hors-bande dans le flux de réception
des sockets distants
socket = a:SO_REUSEADDR=0
désactive la réutilisation d'adresses (activée par défaut)
socket = a:SO_BINDTODEVICE=lo
limite l'acceptation des connexions sur la seule interface de bouclage
Par défaut : yes
niveau 1 - vérifie le certificat s'il est présent
niveau 2 - vérifie le certificat
niveau 3 - contrôle le correspondant avec le certificat local
Par défaut - pas de vérification
Si l'on souhaite utiliser stunnel en mode inetd (lorsqu'un socket lui est fourni par un serveur comme inetd, xinetd ou tcpserver), il faut se reporter à la section MODE INETD plus bas.
Si l'hôte n'est pas indiqué, le port est ouvert pour toutes les adresses IP de la machine locale.
Par défaut, l'hôte est localhost.
Le cas échéant, le chemin exec est relatif au répertoire chroot.
Les quotes ne peuvent actuellement pas être utilisées. Les arguments sont séparés par un nombre quelconque d'espaces.
Actuellement gérés : cifs, nntp, pop3, smtp
Ré-écrit les adresses pour qu'elles apparaissent provenir de la machine client SSL plutôt que de celle qui exécute stunnel. Cette option n'est disponible en mode local (option exec) qu'avec la bibliothèque partagée LD_PRELOADing env.so shared library et en mode distant (option connect) sur les noyaux Linux 2.2 compilés avec l'option transparent proxy et seulement en mode serveur. Cette option ne se combine pas au mode mandataire (connect) sauf si la route par défaut du client vers la cible passe par l'hôte qui fait tourner stunnel, qui ne peut être localhost.
[imapd]
accept = 993
exec = /usr/sbin/imapd
execargs = imapd
Pour tunneliser un daemon pppd sur le port 2020 :
[vpn]
accept = 2020
exec = /usr/sbin/pppd
execargs = pppd local
pty = yes
Configuration de stunnel.conf pour utiliser stunnel en mode inetd qui lance imapd à son tour (il ne doit pas y avoir de section [service_name]) :
exec = /usr/sbin/imapd
execargs = imapd
Si, par exemple, la ligne suivante se trouve dans inetd.conf :
imaps stream tcp nowait root /usr/sbin/stunnel stunnel /etc/stunnel/imaps.conf
Dans ces cas, c'est le programme du genre inetd-style qui est responsable de l'établissement de la connexion (imaps ci-dessus) et de passer celle-ci à stunnel. Ainsi, stunnel ne doit alors avoir aucune option accept. Toutes les options de niveau service doivent être placées dans la section des options globales et aucune section [service_name] ne doit être présente. Voir la section EXEMPLES pour des exemples de configurations.
Deux choses importantes lors de la génération de paires certificat-clef pour stunnel :
-----BEGIN RSA PRIVATE KEY-----
[clef encodée]
-----END RSA PRIVATE KEY-----
[ligne vide]
-----BEGIN CERTIFICATE-----
[certificat encodé]
-----END CERTIFICATE-----
[ligne vide]
Avec un OpenSSL récent (>=OpenSSL 0.9.5a) le chargement de données s'arrête automatiquement lorsqu'un niveau d'entropie suffisant est atteint. Les versions précédentes continuent à lire toutes les sources puisqu'aucune fonction SSL ne leur permet de savoir que suffisamment de données sont disponibles.
Sur les machines MS-Windows qui n'ont pas d'interaction utilisateur sur la console, (mouvements de souris, création de fenêtres, etc.), le contenu de l'écran n'est pas suffisamment changeant et il est nécessaire de fournir un fichier d'aléatoire par le biais de RNDfile.
Le fichier spécifié par RNDfile doit contenir des informations aléatoires --- c'est-à-dire des informations différentes à chaque lancement de stunnel. Cela est géré automatiquement sauf si l'option RNDoverwrite est utilisée. Si l'on souhaite procéder manuellement à la mise à jour de ce fichier, la commande openssl rand des versions récentes d'OpenSSL sera sans doute utile.
Note importante : si /dev/urandom est disponible, OpenSSL a l'habitude d'utiliser celui-ci pour « saler » le PRNG même lorsqu'il contrôle l'état de l'aléatoire ; ainsi, même si /dev/urandom est dernier de la liste ci-dessus, il est vraisemblable qu'il soit utilisé s'il est présent. Ce n'est pas le comportement de stunnel, c'est celui d'OpenSSL.