Provided by: stunnel4_4.29-1_i386 bug

NOM

       stunnel - tunnel SSL universel

SYNOPSIS

       Unix:
           stunnel [fichier] | -fd [n] | -help | -version | -sockets

       WIN32:
           stunnel [fichier] | -install | -uninstall | -help | -version |
           -sockets

DESCRIPTION

       Le programme stunnel est conçu pour fonctionner comme une couche de
       chiffrement SSL entre des clients distants et des serveurs locaux
       (inetd-démarrables) ou distants. Le concept est qu’à partir de daemons
       non-SSL présents sur le système, on peut facilement les configurer pour
       communiquer avec des clients sur des liens sécurisés SSL.

       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)

OPTIONS

       [fichier]
           Utilisation du fichier de configuration spécifié.

       -fd [n] (Unix seulement)
           Lecture du fichier de configuration depuis le descripteur de
           fichier indiqué.

       -help
           Affiche le menu d’aide de stunnel.

       -version
           Affiche la version de stunnel et les options de compilation.

       -sockets
           Affiche les options socket par défaut.

       -install (NT/2000/XP seulement)
           Installe un service NT.

       -uninstall (NT/2000/XP only)
           Désinstalle un service NT.

FICHIER DE CONFIGURATION

       Chaque ligne du fichier de configuration peut être soit :

       ·   une ligne vide (ignorée) ;

       ·   un commentaire commençant par « # » (ignoré) ;

       ·   une paire « option = valeur » ;

       ·   « [service_name] » indiquant le début de la définition d’un
           service ;

       OPTIONS GLOBALES

       CApath = répertoire
           Répertoire des autorités de certification (CA)

           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.

       CAfile = fichier
           Fichier d’autorités de certification

           Ce fichier, utilisé avec verify, contient plusieurs certificats de
           CA.

       cert = fichier
           Fichier de chaîne de certificats PEM

           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 = répertoire (Unix seulement)
           Répertoire de chroot du processus stunnel

           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).

       ciphers = listes de chiffre
           Sélection des chiffres SSL autorisés

           Liste délimitée par deux-points (« : ») des chiffres autorisés pour
           la connexion SSL.  Exemple :  DES-CBC3-SHA:IDEA-CBC-MD5

       client = yes | no
           Mode client (Le service distant utilise SSL)

           Par défaut : no (mode server)

       CRLpath = répertoire
           Répertoire des listes de révocation de certificats (CRL)

           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.

       CRLfile = fichier
           Fichier de listes de révocation de certificats (CRL)

           Ce fichier, utilisé avec verify, contient plusieurs CRL.

       debug = [facilité.]niveau
           niveau de déverminage

           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.

       EGD = chemin (Unix seulement)
           Emplacement du socket du daemon de recueil d’entropie (EGD -
           Entropy Gathering Daemon)

           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).

       foreground = yes | no (Unix seulement)
           Mode avant-plan

           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.

       key = fichier
           Fichier de clef privée pour le certificat spécifié par cert

           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

       options = Options_SSL
           Options de la bibliothèque OpenSSL

           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

       output = fichier
           Ajoute la trace à la fin d’un fichier au lieu d’utiliser syslog.

           /dev/stdout peut être utilisé pour afficher les traces sur la
           sortie standard (par exemple pour les traiter avec les outils
           splogger).

       pid = fichier (Unix seulement)
           Emplacement du fichier pid

           Si l’argument est vide, aucun fichier ne sera créé.

           Le cas échéant, le chemin pid est relatif au répertoire chroot.

       RNDbytes = nombre
           Nombre d’octets à lire depuis les fichiers de « sel » aléatoire

           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.

       RNDfile = fichier
           chemin du fichier de données de « sel » aléatoire

           La bibliothèque SSL utilise prioritairement les données de ce
           fichier pour « saler » le générateur d’aléatoire.

       RNDoverwrite = yes | no
           Recouvre les fichiers de « sel » avec de nouvelles données
           aléatoires.

           Par défaut : yes

       service = nom
           Définit le nom de service à utiliser

           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

       session = timeout
           Timeout du cache de session

       setgid = nom (Unix seulement)
           Nom de groupe utilisé en mode daemon (les éventuels autres noms de
           groupe attribués sont supprimés)

       setuid = nom (Unix seulement)
           Nom d’utilisateur utilisé en mode daemon

       socket = a|l|r:option=valeur[:valeur]
           Configure une option de socket accept (a), locale (l) ou distante
           (r)

           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

       taskbar = yes | no (WIN32 seulement)
           active l’icône de la barre de tâches

           Par défaut : yes

       verify = niveau
           Vérifie le certificat du correspondant

               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

       OPTIONS DE SERVICE

       Chaque section de configuration commence par le nom du service entre
       crochets.  Celui-ci est utilisé par le contrôle d’accès de libwrap (TCP
       Wrappers) et sert à distinguer les services stunnel dans les fichiers
       de traces.

       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.

       accept = [hôte:]port
           Accepte des connexions sur le port spécifié

           Si l’hôte n’est pas indiqué, le port est ouvert pour toutes les
           adresses IP de la machine locale.

       connect = [hôte:]port
           Se connecte au port distant indiqué

           Par défaut, l’hôte est localhost.

       delay = yes | no
           Retarde la recherche DNS pour l’option « connect »

       exec = chemin_exécutable (Unix seulement)
           Exécute un programme local de type inetd

           Le cas échéant, le chemin exec est relatif au répertoire chroot.

       execargs = $0 $1 $2 ... (Unix seulement)
           Arguments pour exec, y compris le nom du programme ($0)

           Les quotes ne peuvent actuellement pas être utilisées.  Les
           arguments sont séparés par un nombre quelconque d’espaces.

       ident = nom
           Applique le contrôle d’identité d’utilisateur IDENT (RFC 1413)

       local = hôte
           Adresse IP de l’interface de sortie utilisée pour les connexions
           distantes.  Cette option permet de relier une adresse statique
           locale.

       protocol = protocole
           Négocie avec SSL selon le protocole indiqué

           Actuellement gérés : cifs, nntp, pop3, smtp

       pty = yes | no (Unix seulement)
           Alloue un pseudo-terminal pour l’option « exec »

       TIMEOUTbusy = secondes
           Durée d’attente de données

       TIMEOUTclose = secondes
           Durée d’attente du close_notify (mis à 0 pour MSIE qui est bogué)

       TIMEOUTidle = secondes
           Durée d’attente sur une connexion inactive

       transparent = yes | no (Unix seulement)
           Mode mandataire transparent

           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.

VALEUR DE RETOUR

       stunnel renvoie zéro en cas de succès, une autre valeur en cas
       d’erreur.

EXEMPLES

       Pour encapsuler votre service imapd local avec SSL :

           [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

FICHIERS

       stunnel.conf
           Fichier de configuration de stunnel

       stunnel.pem
           Certificat et clef privée de stunnel

BOGUES

       L’option execargs n’admet pas les quotes.

RESTRICTIONS

       stunnel ne peut être utilisé pour le daemon FTP en raison de la nature
       du protocole FTP qui utilise des ports multiples pour les transferts de
       données.  Il existe cependant des versions SSL de FTP et de telnet.

NOTES

       MODE INETD

       L’utilisation la plus commune de stunnel consiste à écouter un port
       réseau et à établir une communication, soit avec un nouveau port avec
       l’option connect, soit avec un programme avec l’option exec.  On peut
       parfois cependant souhaiter qu’un autre programme reçoive les
       connexions entrantes et lance stunnel, par exemple avec inetd, xinetd
       ou tcpserver.

       Si, par exemple, la ligne suivante se trouve dans inetd.conf :

           imaps stream tcp nowait root /usr/bin/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.

       CERTIFICATS

       Chaque daemon à propriétés SSL doit présenter un certificat X.509
       valide à son interlocuteur. Il a aussi besoin d’une clef privé pour
       déchiffrer les données entrantes. La méthode la plus simple pour
       obtenir un certificat et une clef est d’engendrer celles-ci avec le
       paquetage libre OpenSSL. Plus d’informations sur la génération de
       certificats se trouvent dans les pages indiquées plus bas.

       Deux choses importantes lors de la génération de paires certificat-clef
       pour stunnel :

       ·   la clef privée ne peut être chiffrée puisque le serveur n’a aucun
           moyen d’obtenir le mot de passe de l’utilisateur ; pour produire
           une clef non chiffrée, ajouter l’option -nodes à la commande req de
           OpenSSL ;

       ·   l’ordre du contenu du fichier .pem est significatif : il doit
           contenir d’abord une clef privée non chiffrée, puis un certificat
           signé (et non une demande de certificat).  Il doit aussi y avoir
           des lignes vides après le certificat et après la clef privée.
           L’information textuelle ajoutée au début d’un certificat doit être
           supprimée afin que le fichier ait l’allure suivante :

               -----BEGIN RSA PRIVATE KEY-----
               [clef encodée]
               -----END RSA PRIVATE KEY-----
               [ligne vide]
               -----BEGIN CERTIFICATE-----
               [certificat encodé]
               -----END CERTIFICATE-----
               [ligne vide]

       ALEATOIRE

       stunnel doit « saler » le générateur de pseudo-aléatoires PRNG (pseudo
       random number generator) afin que SSL utilise un aléatoire de qualité.
       Les sources suivantes sont chargées dans l’ordre jusqu’à ce qu’une
       quantité suffisante de données soit lue :

       ·   le fichier spécifié par RNDfile ;

       ·   le fichier spécifié par la variable d’environnement RANDFILE, à
           défaut le fichier .rnd du répertoire $HOME de l’utilisateur ;

       ·   le fichier spécifié par « --with-random » lors de la compilation ;

       ·   le contenu de l’écran (MS-Windows seulement) ;

       ·   le socket EGD spécifié par EGD ;

       ·   le socket EGD spécifié par « --with-egd-sock » lors de la
           compilation ;

       ·   le périphérique /dev/urandom.

       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.

VOIR AUSSI

       tcpd(8)
           Service de contrôle d’accès pour les services internet

       inetd(8)
           « super-serveur » internet

       http://stunnel.mirt.net/
           Page de référence de stunnel

       http://www.stunnel.org/
           Foire aux questions stunnel

       http://www.openssl.org/
           Site web du projet OpenSSL

AUTEUR

       Michal Trojnara
           <Michal.Trojnara@mirt.net>

ADAPTATION FRANÇAISE

       Bernard Choppy
           <choppy AT free POINT fr>