OpenSSL

Grégory Colpart Sébastien Dubois

février 2004

Le sujet :

SSL spécifie des outils cryptographiques et des formats de représentation des objets correspondants (clés, signatures, certificats). Open SSL est une implémentation de ces spécifications. En plus d'une librairie C, on dispose d'une commande openssl qui permet de tester à la main quelques fonctionnalités de SSL.

Objectifs du projet :

Lire Network security with OpenSSL, John Viega et al., O'REILLY.
Installer le logiciel.
Préparer une démonstration d'utilisation des fonctionnalités de base du logiciel.
Tester et présenter quelques Travaux Pratiques de la page
http://www.unilim.fr/pages_perso/francois.arnault/

1 Aspects théoriques

1.1 Le protocole SSL

SSL signifie Secure Sockets Layer, en français couche de sockets sécurisée.
Le protocole SSL a été développé par Netscape Communications de façon à améliorer la confidentialité des échanges de tout protocole basé sur TCP/IP.
En 1994, Netscape Communications diffuse le protocole SSL 2.0
Les spécifications de ce protocole sont décrites à l'adresse
http://wp.netscape.com/eng/security/SSL_2.html
En 1996, Netscape Communications diffuse une amélioration: le protocole SSL 3.0
Les spécifications de ce nouveau protocole sont décrites à l'adresse
http://wp.netscape.com/eng/ssl3/
En 2001, le brevet de SSL a été racheté à Netscape Communications par l'IETF (Internet Engineering Task Force) et a été renommé TLS (Transport Layer Security), qui peut-être vu comme la version 3.1 de SSL
Le protocole TLS 1.0 est désormais standard. Il est décrit dans le RFC 2246, voir ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt

1.1.1 Caractéristiques du protocole SSL 2.0

L'un des points forts du protocole SSL est qu'il s'insère entre le protocole applicatif et le protocole TCP. Il est donc transparent pour le protocole applicatif.

Figure 1 : Représentation DODS

SSL assure l'authentification des extrémités du circuit de communication ainsi que la confidentialité et l'intégrité des informations transmises :

le serveur s'identifie auprès du client par un certificat vérifiable par le client. Cette authentification est obligatoire. Le client peut optionnellement s'identifier auprès du serveur par les mêmes mécanismes.
le flux d'informations transmises entre les deux extrémités du circuit est segmenté en enregistrements (cf. SSL Record Protocol Specification). Chaque enregistrement est chiffré par un algorithme négocié au moment de l'ouverture du circuit.
En outre, chaque enregistrement est accompagné d'une signature MAC (Message Authentication Code) garantissant l'intégrité de l'enregistrement.

1.1.2 Caractéristiques du protocole SSL 3.0

Le protocole SSL 3.0 corrige un certain nombre de faiblesses de la version 2 et apporte de nouvelles fonctionnalités. En plus du protocole d'ouverture de session (SSL Handshake Protocol), SSL 3.0 prévoit deux protocoles supplémentaires : le protocole d'échange de spécifications de chiffrement (SSL Change Cipher Spec) et le protocole d'alerte (SSL Alert Protocol).
Tous deux, à l'instar du SSL Handshake Protocol, s'appuient sur le protocole de transfert d'enregistrement (SSL Record Protocol).
Le messages échangés par ces protocoles sont donc chiffrés dès que possible.
Le protocole d'alerte est utilisé pour la transmission de codes d'erreurs entre le client et le serveur.
Les codes d'erreurs sont accompagnés d'un indice de sévérité de l'erreur (avertissement, erreur fatale).
Le protocole SSL 3.0 spécifie que si une erreur fatale est détectée lors d'une session, alors la session doit être immédiatement interrompue et doit être effacée du cache des sessions, à la fois sur le client et sur le serveur.
Ainsi, une erreur dans le protocole SSL force, lors de la prochaine ouverture de session, la renégociation des spécifications de chiffrement et la génération d'une nouvelle clé-maître.
Le protocole d'alerte est également utilisé pour indiquer la fin d'une session entre le client et le serveur.
Cette notion n'existe pas dans SSL 2.0 , où l'une des extrémités indique la fin d'une session SSL en fermant la connexion TCP/IP sous-jacente.
Ce mécanisme rend SSL 2.0 vulnérable aux attaques par "troncature" : en effet, on peut très bien imaginer un homme du milieu provoquant la fin prématurée d'une session SSL en envoyant les paquets ad-hoc au client et au serveur.
Dans le protocole d'ouverture de session, le serveur et le client ont la possibilité de négocier un algorithme de compression des données avant leur chiffrement.
En outre, lorsqu'ils transmettent leur certificat, ils transmettent également la chaîne d'autorités de certification qui valide le certificat en question.
De même, lorsque le serveur demande le certificat du client, il lui transmet également la liste des autorités de certification qu'il accepte.
Le client est donc en mesure de sélectionner le certificat le plus approprié.

1.2 Cas d'utilisation de SSL

1.2.1 Fonctionnalités

SSL utilise les fonctionnalités offertes par TCP/IP pour permettre aux couches supérieures d'accéder à un mode d'accès sécurisé. Les protocoles utilisant le plus couramment ce mode, sont bien sûr HTTP (web) mais aussi LDAP (annuaire), SMTP (mail), NNTP (news) ou encore IMAP (consultation mail), etc.

Les trois fonctionnalités de SSL sont :

Authentification du serveur

Cela permet à un utilisateur d'avoir une confirmation de l'identité d'un serveur. En effet un programme client SSL utilise des méthodes de chiffrement à clé publique pour vérifier si le certificat et l'identité publique fournis par le serveur sont valides et ont été fournis par un fournisseur de certificat présent dans la liste de ceux connus du client. Cette fonctionnalité est importante dans la mesure où le client doit envoyer des données confidentielles comme son numéro de carte bleue par exemple.
Authentification du client

La technique est ici exactement la même que pour l'authentification du serveur. Cela peut servir si le serveur envoie des informations importantes à un client, qui doit, dans ce cas être authentifier.
Chiffrement des données

Toutes les données issues de l'entité émettrice sont chiffrées et déchiffrées par l'entité réceptrice, ce qui permet de garantir la confidentialité des données. Un mécanisme permet également de garantir l'intégrité des données. C'est bien sûr la fonctionnalité de base de ce protocole.

1.2.2 Négociation sous SSL

Une session SSL commence par une phase de négociation (handshake).
Le protocole SSL combine simultanément l'utilisation de clés publiques et de clés symétriques. Les clés publiques privées ou clés asymétriques procurent en effet une très bonne méthode pour l'authentification mais son utilisation est coûteuse en terme de bande passante. A l'opposé, le mécanisme de clé symétrique (identique pour chiffrer et déchiffrer) est extrêmement rapide mais pas réellement adapté à l'authentification d'un tiers. Ainsi SSL va utiliser son protocole de négociation qui va être apte à partir des clés publiques et privées du client et du serveur d'établir une communication entre les deux entités avec une clé secrète (symétrique) de taille nettement inférieure à celle rencontrée pour des clés publiques (souvent 128 bits contre 1024 ou plus).
Mécanisme de la négociation

Le client envoie au serveur sa version du protocole SSL, ses paramètres de chiffrement, des données générées aléatoirement et d'autres informations dont le serveur a besoin.
Le serveur renvoie sa version de SSL, ses paramètres de chiffrement, des données générées aléatoirement et d'autres informations dont le client a besoin. Le point essentiel est l'envoi par le serveur de son propre certificat avec des informations concernant ce certificat. Si le client demande une information nécessitant un certificat, il demande également un certificat client.
Le client utilise les informations envoyées par le serveur pour l'authentifier. Si le serveur ne peut pas être authentifié, la connexion n'a pas lieu.
Avec les données préalablement échangées, le client est en mesure d'envoyer au serveur une clé secrète, qu'il chiffre avec la clé publique du serveur. Si le serveur a requis une authentification du client, ce dernier renvoie également au serveur un bloc de données signé ainsi que son certificat.
Si le serveur a requis une authentification, il authentifie le client. Le serveur utilise alors sa clé privée de façon à pouvoir déchiffrer la pré clé secrète. Le serveur effectue alors une suite d'actions (également effectuées par le client) pour obtenir une clé secrète à partir de la pré clé secrète.
Le client et le serveur utilisent la clé secrète pour générer des clés de session qui seront les clés symétriques utilisées pour le chiffrement, déchiffrement des données et l'intégrité.
Le client envoie alors un avertissement au serveur le prévenant que les prochains messages seront chiffrés avec la clé de session. Puis il envoie un message chiffré indiquant que la phase de négociation est terminée.
Le serveur envoie alors un avertissement au client comme quoi les prochains messages seront chiffrés avec la clé de session. Puis il envoie un message (chiffré cette fois) indiquant que la phase de négociation est terminée.
La phase de négociation est alors terminée.

Dans le cas du SSL il est pour le moment assez rare de rencontrer une authentification du client. En effet, la plupart des applications utilisées sur Internet ne requièrent pas un tel niveau de sécurité.

Toute la sécurité de SSL repose sur l'authentification du serveur par le client et donc la vérification de la validité du certificat par le serveur. Par exemple, lorsque l'on se connecte à un serveur web sécurisé, un navigateur web présente le certificat en faisant apparaître une fenêtre contenant des informations sur le certificat. L'idéal serait de vérifier de façon sûre l'empreinte du certificat du serveur. Mais en pratique, cette méthode est irréalisable. En revanche, pour limiter les risques, le client devra vérifier (souvent visuellement) certaines informations sur le certificat du serveur :

Vérification de la date de validité du certificat du serveur.
Est-ce que l'autorité de certification est une autorité de confiance ? Pour vérifier cela, les navigateurs intègrent une liste de certificats d'autorités de confiance. Mais les certificats ne sont pas toujours validés par des autorités de confiance.
Vérification de la clé publique à partir de la signature. Le client vérifie la validité de la signature (chiffrée avec la clé privée) fournie dans le certificat grâce à la clé publique qui a été fournie elle aussi dans le certificat.
Vérification du nom de domaine du serveur. Cette étape permet de vérifier que le nom de domaine du serveur défini dans le certificat correspond bien à la même adresse Internet. Cette étape n'est pas obligatoire et dépend de l'implémentation du client SSL. Elle permet cependant d'éviter qu'un usurpateur vienne jouer les intermédiaires entre le client et le serveur et se fasse passer pour l'un et l'autre auprès des deux entités. Vérifier la validité du nom de domaine est le seul moyen d'éviter ce genre de faille qui permet, dans ce cas, à la personne malveillante d'intercepter les informations transitant pendant la négociation et donc ultérieurement de prendre la place du client une fois cette phase passée. Pour usurper l'identité du serveur, le pirate devra également se procurer la clé privée du serveur.
Le serveur est maintenant authentifié, la phase de négociation se poursuit.

1.2.3 Utilisation

On a pu voir que SSL permet de chiffrer une communication client/serveur.

HTTPS

Le protocole HTTPS est l'implémentation du protocole HTTP (Hyper Text Transfer Protocol) au dessus de SSL. Du fait que le démarrage d'une session SSL se fait à l'initiative du client, l'utilisation de HTTPS pour le transfert de pages WWW doit être spécifié dans l'URL (Uniform Resource Locator). Le protocole HTTPS est communément utilisé dans les applications de commerce électronique, au moins dans la phase de transfert des coordonnées bancaires (numéros de cartes bancaires, notamment). On peut repérer concrètement cette utilisation par l'apparition d'un cadenas en bas à droite du navigateur, ou d'une notification lors de l'arrivée ou la sortie d'une page sécurisée. Il faut garder à l'esprit que seul le transfert de données est réellement sécurisé. L'utilisation de HTTPS n'augmente en rien la sécurité du serveur lui-même, ni de l'application basée sur HTTPS .
SSL et la messagerie

Les technologies de Webmail, utilisées pour les accès à distance aux boîtes aux lettres, sont souvent sécurisées par HTTPS et permettent de visualiser les courriels avec un protocole chiffré.
Il existe des protocoles spécifiques pour consulter des courriels tels POP ou IMAP. Ces derniers sont encapsulables dans des sessions SSL. L'idée est donc la même que pour HTTPS: le client et le serveur établissent en premier lieu une connexion SSL et déroulent ensuite le protocole classique au dessus de cette connexion.
Les protocoles qui en résultent ont reçu des numéros de ports officiels par l'IANA : il s'agit de 993 pour IMAP sécurisé et 995 pour POP sécurisé.
Le format S/MIME

Le format S/MIME est une extension du format MIME (format spécifique d'extensions multimédias pour les courriels) pour décrire une message chiffré ou signé.
Il définit un certain nombre de types MIME pour décrire un message chiffré ou un message signé.
S/MIME s'appuie sur PKCS7 qui décrit une syntaxe générale pour des données auxquelles on a appliqué des techniques de cryptographie, c'est-à-dire essentiellement, la signature digitale et le chiffrement. Les clients de messagerie sont en mesure de générer et interpréter correctement des messages au format S/MIME.
La signature d'un message S/MIME définit plusieurs formats pour des messages signés. Le plus couramment utilisé correspond au type MIME multipart/signed. Dans ce format, le message transmis est la réunion de deux parties MIME. La première correspond au message à signer. Il a un type MIME et un encodage classique. La deuxième partie est l'empreinte correspondante chiffrée avec la clé privée du signataire. Elle contient également le certificat du signataire et les informations sur les algorithmes utilisés pour calculer l'empreinte du message et chiffrer cette empreinte. Plus précisément, cette partie est un objet PKCS7 de type signedData avec un champ contentInfo vide. On lui attribue le type MIME application/pkcs7-signature.
Le type MIME application/pkcs7-mime est utilisé dans le cas d'un message ou d'une partie de message chiffré. La partie chiffrée du message est un objet PKCS7 de type envelopedData. Il correspond au résultat du chiffrement du message par la clé publique du destinataire.
Dans le cas d'un message à la fois signé et chiffré, il y a deux possibilités. Soit on chiffre le message signé, soit on signe le message chiffré. Les deux solutions ont chacune leur intérêt. Dans le premier cas, la liste des signataires est masquée par le chiffrement. Dans le deuxième cas, on peut vérifier les signataires sans être en mesure de déchiffrer le message. C'est donc l'application de messagerie qui décide quel mécanisme employer.
Pour pouvoir utiliser S/MIME, il est nécessaire d'être titulaire d'un certificat d'authentification. L'autorité signataire de ce certificat doit être connue de tous les correspondants. Dans le cas contraire, le destinataire d'un message ne pourra pas être en mesure de vérifier la signature de l'émetteur du message. En principe, un certificat d'utilisateur ne contient que la clé publique. La manière habituelle de transmettre à l'utilisateur son certificat et sa clé privée est de chiffrer l'ensemble par un algorithme symétrique standard (triple-DES, par exemple) et de communiquer la clé de chiffrement par un moyen sûr (communication téléphonique chiffrée, courrier en main propre, etc.) Le format dans lequel est chiffré le certificat et la clé privée s'appelle PKCS12 . Importer un certificat au format PKCS12 depuis un navigateur standard est trivial.
OpenSSL

OpenSSL est une suite libre d'outils implémentant à la fois les protocoles SSL 2.0 et SSL 3.0 et le protocole TLS 1.0 ainsi que des librairies cryptographiques.
OpenSSL est basé sur l'excellente librairie SSLeay développée par Eric A. Young et Tim J. Hudson.
Voir http://www2.psy.uq.edu.au/~ftp/Crypto/
Le projet est géré par une communauté de développeurs répartis partout dans le monde.
Les outils OpenSSL sont sous une license de style Apache qui en permet une utilisation commerciale ou non.
Dès lors comme on le verra dans la partie pratique toutes les fonctions principales nécessaires pour mettre au point une politique de sécurisation est accessible par la ligne de commande : algorithmes de hashage, algorithmes de chiffrement clé privé ou public, diffie-hellman, signature ...
Voir http://www.openssl.org

1.3 Aperçu des particularités/limites d'utilisation

1.3.1 Compromis nécessaire

Il faut bien comprendre qu'il doit exister un compromis entre la sécurité et la rapidité de transfert (qui contient compte du temps de calcul et de la bande passante). Ainsi en utilisant le protocole SSL il y a concrètement une diminution de la part de données utiles pour un même nombre d'octets échangés. Il existe certes du matériel hardware supportant la cryptographie et les ressources supplémentaires (cartes accélératrices) requises mais une réflexion profonde sur le degré de chiffrement nécessaire et suffisant (longueur des clés...) est obligatoire.

1.3.2 Limites conceptuelles/PRNG

Beaucoup de fonctions au travers de la librairie OpenSSL requièrent la génération de nombres aléatoires. Par exemple, la création de clés de sessions ou générer des pairs de clés public/privé. Si les valeurs choisies ne sont pas aléatoires, alors la sécurité du protocole correspondant peut être gravement altérée. Pour produire des nombres aléatoires, on a besoin de savoir générer des suites de bits qui non seulement possèdent des propriétés statistiques compatibles avec des suites aléatoires, mais aussi ne puissent pas, en un temps raisonnable, être distinguées de suites aléatoires vraies.

Pour répondre à ce besoin, le package RAND propose un générateur de nombres pseudo aléatoire PRNG. Un générateur de nombres pseudo aléatoires (Pseudo Random Number Generator: PRNG) fournit aux applications un flot de nombres qui possèdent certaines propriétés importantes en ce qui concerne la sécurité du système :

Il doit être impossible de prévoir le résultat du générateur de nombres aléatoires même en connaissant le résultat précédent.
Les nombres générés ne doivent pas avoir de caractères qui se répètent ce qui signifie que le générateur doit avoir un cycle très grand.

Un PRNG est normalement un algorithme où les mêmes variables en entrée donneront les mêmes résultats en sortie. Dès lors un PRNG nécessite une donnée initiale ("seed" en anglais). C'est un secret, une donnée imprévisible que l'on utilise pour tout initialiser. La sécurité de ce "seed" est la base de la viabilité d'un PRNG.Idéalement le "seed" doit avoir une entropie forte (c'est à dire proportion forte d'aléatoire). Sur un système multi-utilisateurs, il existe de nombreuses sources qui permettent de fournir des données aléatoires au PRNG. Par exemple le temps entre les interruptions dues à la souris, le temps entre les interruptions dues aux données réseau, le temps entre chaque appui de touches et les informations sur les entrées/sorties des disques pour remplir la réserve d'entropie. Les nombres aléatoires sont accessibles aux routines du noyau et sont exportés aux programmes utilisateurs par l'intermédiaire de périphériques.

Cette fonction de génération de nombres pseudo-aléatoires est centrale au sein d'une librairie cryptographique et constitue un point vraiment critique.

Pour preuve en juillet 2001 l'algorithme PRNG (qui génère des nombres aléatoires) fût vulnérable suite à une erreur de conception. La version 0.9.6b corrigea le problème.

Cette faille est résolue mais l'on voit la nécessité de toujours se tenir à jour et d'une manière générale l'insécurité de créer ses propres outils cryptographiques. En effet même si les algorithmes sont connus, leur implémentation peut à chaque instant présenter une faille de sécurité.

2 Applications

Nous allons nous concentrer sur les fonctionnalités de la commande openssl puis nous allons tester les Travaux pratiques de la page
http://www.unilim.fr/pages_perso/francois.arnault/

2.1 La commande openssl

Nous ne prétendrons pas donner toutes les options utilisables de la commande openssl mais nous en verrons quelques une d'intéressantes. Pour plus d'informations, on se reportera à la manpage de openssl.

2.1.1 Installation

Les sources d'openssl se trouvent sur
http://www.openssl.org/source/
Le logiciel est préinstallé sur la plupart des distributions de type Unix ou Linux.
Si ce n'est pas le cas, on peut recompiler openssl mais le mieux reste d'installer un paquet ou port destiné au système où l'on travaillle. Par exemple sous Debian GNU/Linux :

# apt-get install openssl

2.1.2 Calculs de Hash

Parmi les fonctions de hashage disponibles on retrouve SHA , SHA-1, DSA, MD2, MD4, MD5 et RMD-160.
On calculera le hash d'un fichier par la commande :

$ openssl dgst -algo fichier

où -algo peut être -sha, -sha1, -dss1, -md2, -md4, -md5, -ripemd160

2.1.3 Chiffrement symétrique

De nombreuses fonctions de chiffrement symétrique sont disponibles: DES, triple-DES, RC2, RC4, RC5, Blowfish, CAST, CAST5, IDEA, utilisables en mode ECB, CBC, OFB, EDE, CFB, EDE-OFB, EDE-CBC, EDE-CFB, EDE-OFB

Pour chiffrer le fichier fic.txt en fic.enc :

$ openssl enc -algo -in fic.txt -out fic.enc

où -algo peut être -des-cbc, -des-ecb, -des-cfb, -des-ede, -des-ofb, -des-ede-cbc, -des-ede-cfb, des-ede-ofb, -des3, -bf, -cast, -cast5-cbc, -idea, -rc2, -rc4, -rc5, etc.

On déchiffrera le fichier fic.enc en fic.dec par la commande :

$ openssl enc -d -algo -in fic.enc -out fic.dec

2.1.4 Astuces

Pour convertir un fichier en base 64 :

$ openssl base64 -in fichier

Pour générer un certain nombre d'octets aléatoirement (avec l'option -base 64 pour que cela soit visible), par exemple 128 :

$ openssl rand -base64 128

2.1.5 Diffie-Hellman

On génèrera des paramètres de Diffie-Hellman dans un fichier dhparam.pem (par exemple avec un générateur de 2, et une clé de de taille 1024) :

$ openssl dhparam -2 1024 -out dhparam.pem

2.1.6 DSA

On génèrera des paramètres DSA dans un fichier paramdsa.pem par la commande (par exemple avec un clé de taille 1024) :

$ openssl dsaparam 1024 -out dsaparam.pem

Pour générer une clé privée à partir de paramètres DSA dans un fichier dsa.priv :

$ openssl gendsa dsaparam.pem -out dsa.priv

Puis extraire la clé publique DSA dans un fichier dsa.pub à partir de la clé privée :

$ openssl dsa -in dsa.priv -pubout -out dsa.pub

2.1.7 RSA

Pour générer une clé privée RSA de longueur 1024 dans un fichier rsa.priv :

$ openssl genrsa -out rsa.priv

On peut rajouter du chiffrement avec l'option -algo qui peut être -des, -des3, etc. (voir section 2.1.2 )
Puis extraire la clé publique RSA dans un fichier rsa.pub à partir de la clé privée :

$ openssl rsa -in rsa.priv -pubout -out rsa.pub

Voyons comment chiffrer un fichier fic.txt en un fichier fic.enc :

$ openssl rsautl -encrypt -pubin -inkey rsa.pub -in fic.txt -out fic.enc

Puis comment le déchiffrer dans un fichier fic.dec :

$ openssl rsautl -decrypt -inkey rsa.priv -in fic.enc -out fic.dec

Pour générer une signature fic.sig pour le fichier fic.txt :

$ openssl rsautl -sign -inkey rsa.priv -in fic.txt -out fic.sig

Que l'on déchiffrera par :

$ openssl rsautl -verify -pubin -inkey rsa.pub -in fic.sig

2.1.8 Certificats

La commande openssl permet la génération de certificats. Les paramètres par défaut d'un certificat sont éventuellement contenus dans un fichier openssl.cnf ssl.conf (se trouvant souvent dans le répertoire /etc/ssl/).

Voici par exemple une partie d'un fichier openssl.cnf :

[ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = FR countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Bouches-du-Rhone localityName = Locality Name (eg, city) localityName_default = Marseille 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Evolix commonName = Common Name (eg, YOUR name) commonName_default = COLPART Gregory commonName_max = 64 emailAddress = Email Address emailAddress_default = reg@gcolpart.com emailAddress_max = 64 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20

On peut générer par exemple un certificat x509 en utilisant RSA avec une longueur de clé de 1024 dans un fichier ca.pem et la clé privée étant dans un fichier rsa.priv :

$ openssl req -x509 -newkey rsa:1024 -keyout rsa.priv -out ca.pem

On consultera le contenu d'un certicat x509 par la commande :

$ openssl x509 -text -in ca.pem

2.1.9 S/MIME

Nous supposerons avoir générer un certificat x509 dans un fichier ca.pem
On chiffrera un fichier mess.txt en mess.enc avec S/MIME par :

$ openssl smime -encrypt -in mess.txt -out mess.enc ca.pem

On déchiffera un fichier mess.enc en mess.dec par :

$ openssl smime -decrypt -in mess.enc -out mess.dec -recip ca.pem -inkey rsa.priv

On peut également signer un message d'une façon similaire. On signera un message mess.txt par un fichier mess.sig avec la commande :

$ openssl smime -sign -in mess.txt -out mess.sig -signer ca.pem -inkey rsa.priv

On vérifiera la signature par :

$ openssl smime -verify -CAfile ca.pem -in mess.sig

2.2 stunnel

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.

2.2.1 Installation

Les sources de stunnel se trouvent sur
http://www.stunnel.org/download/source.html
Le logiciel est préinstallé sur la plupart des distributions de type Unix ou Linux.
Si ce n'est pas le cas, on peut recompiler openssl mais le mieux reste d'installer un paquet ou port destiné au système où l'on travaillle. Par exemple sous Debian GNU/Linux :

# apt-get install stunnel

2.2.2 Exemple d'utilisation

Nous allons voir un exemple concret d'utilisation de stunnel.
Nous avons un serveur web tournant sur notre machine sur le port 80. Nous voulons proposer ce service web de façon sécurisé sur le port 443. Pour cela il nous faut tout d'abord créer un certificat x509 grâce à la commande openssl dans un fichier ca.pem (voir 2.1.8).
On peut donc lancer la commande :

# stunnel -d 443 -r 80 tunnel-http -p ca.pem

Nous pouvons donc pointer un navigateur vers l'adresse https://site. Le certificat généré nous est donc présenté et nous accédons ensuite au serveur de façon sécurisée.

2.3 OpenSSH

SSH signifie Secure SHell (Shell sécurisé).
Le protocole SSH est en cours de standardisation par l'IETF.
Voir http://www.ietf.org/html.charters/secsh-charter.html
Les outils du protocole SSH sont utilisés par un nombre croissant de personnes. Ils sont destinés à sécuriser le login à distance, sécuriser les transferts de fichiers et sécuriser les TCP/IP et X11 forwardings. Il peut automatiquement chiffrer, authentifier et compresser des données transmises.

La principale implémentation du protocole est OpenSSH
Voir http://www.openssh.org
OpenSSH est une version libre de la suite d'outils du protocole SSH. De nombreux utilisateurs de telnet, rlogin, ftp et autres programmes identiques ne réalisent pas que leur mot de passe et leurs données sont transmis de façon non chiffrée. OpenSSH chiffre tout le trafic (mots de passe inclus) de façon à déjouer les écoutes réseau, les prises de contrôle de connexion, et autres attaques. De plus, OpenSSH fournit toute une palette de possibilités de tunnel et de méthodes d'authentification.
Pour la plupart de ses fonctionnalités cryptographiques, OpenSSH s'appuie sur la bibliothèque OpenSSL.
La suite logicielle OpenSSH inclus les programmes ssh qui remplace telnet et rlogin, scp qui remplace rcp, et sftp qui remplace ftp. De plus sshd, la partie serveur , est inclus ainsi que d'autres utilitaires tels que ssh-add, ssh-agent, ssh-keygen, ssh-keysign, ssh-keyscan, et sftp-server. OpenSSH supporte les protocoles SSH 1.3, 1.5 et 2.0.

2.3.1 Installation

Il existe une version spécifique pour le système d'exploitation OpenBSD et une version portable pour les autres sytèmes d'exploitation. On pourra recompiler OpenSSH à partir des sources. Mais OpenSSH est fourni sous forme de paquet précompilé sous la plupart des systèmes d'exploitations.
Par exemple, sous Debian :

# apt-get install ssh

Il est raisonnable de choisir de n'utiliser que la version 2 du protocole SSH. Dans ce cas, il sera généré à l'installation une paire de clés RSA et une paire de clés DSA. Les clés sont stockées dans un répertoire, souvent /etc/ssh/ :
- le fichier ssh_host_rsa_key contient la clé privée RSA
- le fichier ssh_host_rsa_key.pub contient la clé publique RSA ainsi que le root@nom_machine
- le fichier ssh_host_dsa_key contient la clé privée DSA
- le fichier ssh_host_dsa_key.pub contient la clé publique DSA ainsi que le root@nom_machine

2.3.2 Configuration

Le fichier de configuration du client se nomme sshd_config.
Mais en pratique les options du client sont plutôt utilisés directement ou spécifiées dans le fichier utilisateur.

Le fichier de configuration du serveur se nomme ssh_config
Voici un fichier ssh_config typique:

Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes RhostsAuthentication no IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no PasswordAuthentication yes PAMAuthenticationViaKbdInt yes PAMAuthenticationViaKbdInt yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no KeepAlive yes Subsystem sftp /usr/lib/sftp-server

2.3.3 Utilisation

Détaillons maintenant ce qui se passe lorsqu'un client ssh se connecte à un serveur:

$ ssh login@host

OpenSSH_3.6.1p2 Debian 1:3.6.1p2-11, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
Reading configuration data /etc/ssh/ssh_config
Rhosts Authentication disabled, originating port will not be trusted.
Connecting to serveur [192.168.1.4] port 22.
Connection established.
identity file /home/login/.ssh/identity type -1
identity file /home/login/.ssh/id_rsa type -1
identity file /home/login/.ssh/id_dsa type -1
Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3
match: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-11
SSH2_MSG_KEXINIT sent
SSH2_MSG_KEXINIT received
kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none
SSH2_MSG_KEX_DH_GEX_REQUEST sent
expecting SSH2_MSG_KEX_DH_GEX_GROUP
SSH2_MSG_KEX_DH_GEX_INIT sent
expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'host (IP_host)' can't be established.
RSA key fingerprint is a1:d5:91:14:e6:cd:32:3c:9b:e6:dd:a5:ca:bd:ab:4b.
Are you sure you want to continue connecting (yes/no)?

L'utilisateur doit vérifier par un moyen sûr que l'empreinte de la clé publique du serveur est coorecte. Ensuite il peut accepter et répondre par yes, puis la connexion se poursuit :

Warning: Permanently added 'host,IP_host' (RSA) to the list of known hosts.
ssh_rsa_verify: signature correct
SSH2_MSG_NEWKEYS sent
expecting SSH2_MSG_NEWKEYS
SSH2_MSG_NEWKEYS received
SSH2_MSG_SERVICE_REQUEST sent
SSH2_MSG_SERVICE_ACCEPT received
Authentications that can continue: publickey,password,keyboard-interactive
Next authentication method: publickey
Trying private key: /home/login/.ssh/identity
Trying private key: /home/login/.ssh/id_rsa
Trying private key: /home/login/.ssh/id_dsa
Next authentication method: keyboard-interactive
Authentications that can continue: publickey,password,keyboard-interactive
Next authentication method: password
reg@serveur's password:

On entre le mot de passe correspondant au login.

Authentication succeeded (password).
channel 0: new [client-session]
Entering interactive session.
channel 0: request pty-req
channel 0: request shell
channel 0: open confirm rwindow 0 rmax 32768

L'utilisateur a donc stockée la clé publique RSA du serveur dans le fichier /.ssh/known_hosts sous la forme :
nom_de_domaine_machine,IP_machine ssh-rsa RSA PUBLIC KEY
Ce fichier contient donc toutes les clés publiques des où l'utilisateur s'est connecté au moins une fois.
Lors des connexions suivantes, on aura donc l'assurance de bien s'adresser à la machine voulue (si ni le serveur, ni la machine cliente n'ont été compromises).
Si pour la clé du serveur ne correspond plus (vous êtes victime d'une attaque, le serveur a changé de clé publique, etc.) vous obtiendrez ceci :

$ ssh login@host

OpenSSH_3.6.1p2 Debian 1:3.6.1p2-11, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
Reading configuration data /etc/ssh/ssh_config
Rhosts Authentication disabled, originating port will not be trusted.
Connecting to host [IP_host] port 22.
Connection established.
identity file /home/login/.ssh/identity type -1
identity file /home/login/.ssh/id_rsa type -1
identity file /home/login/.ssh/id_dsa type -1
Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3
match: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-11
SSH2_MSG_KEXINIT sent
SSH2_MSG_KEXINIT received
kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none
SSH2_MSG_KEX_DH_GEX_REQUEST sent
expecting SSH2_MSG_KEX_DH_GEX_GROUP
SSH2_MSG_KEX_DH_GEX_INIT sent
expecting SSH2_MSG_KEX_DH_GEX_REPLY
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
a1:d5:91:14:e6:cd:32:3c:9b:e6:dd:a5:ca:bd:ab:4b.
Please contact your system administrator.
Add correct host key in /home/login/.ssh/known_hosts to get rid of this message.
Offending key in /home/login/.ssh/known_hosts:27
RSA host key for serveur has changed and you have requested strict checking.
Host key verification failed.
Calling cleanup 0x80623b0(0x0)

Si vous êtes sûr que le serveur a changé de clé, vous pouvez effacer la ligne dans le fichier /.ssh/known_hosts correspondante à l'ancienne clé publique et recommencer la connexion.
Il est vraiment important de vérifier l'empreinte de la clé publique du serveur par un moyen sûr avant d'accepter la clé afin de s'assurer que l'on est pas victime d'une attaque active.

D'autres options intéressantes sont disponibles pour une connexion ssh notamment :
-c blowfish|3des|des : choisir le type de clés symétriques utilisées
-f : lancer en arrière plan
-p num_port : connexion au serveur ssh tournant sur le port num_port
-X : autorise le X11 forwarding qui permet d'exécuter des applications graphiques du serveur sur le client
Ces options peuvent être stockés dans le fichier /.ssh/config

2.3.4 Tunnel SSH

Attardons nous sur l'une des fonctionnalités de SSH qui permet de faire des tunnels.
Prenons par exemple un serveur VNC qui tourne sur les sockets :
5901/tcp open vnc-1
6001/tcp open X11:1

Nous voulons donc sécuriser la transmission entre le client et le serveur VNC.
Il faut un serveur ssh démarré sur le serveur. Sur le serveur, on lance donc un vncserver :

$ vncserver

Sur le client on lance le tunnel ssh :

$ ssh -L 5901:localhost:5901 login@serveur

On peut donc maintenant se connecter au serveur vncserver par le tunnel ssh en spécifiant que le serveur est désormais l'hôte local :

$ vncviewer localhost:1

Pour quitter on fermera le client VNC puis la connexion ssh et éventuellement le vncserver.

2.4 VPN et IPSec

Les technologies de VPN sont de plus en plus utilisées.
Le but d'un VPN est de relier des réseaux distants comme s'il s'agissait d'un unique réseau local. En pratique, les VPN sont chiffrés. Une façon répandue d'établir les VPN est d'utiliser des certificats x509. Ces certificats sont générés avec OpenSSL.
Le protocole IPSec devient standard pour les VPN, voir la RFC 2411
Les noyaux Linux 2.4 ont besoin du patch FreeS/WAN,
voir http://www.freeswan.org pour pouvoir bénéficier des technologies VPN. Les noyaux Linux 2.6, FreeBSD, NetBSD et OpenBSD incluent directement les fonctionnalités IPSec.
Nous alons prendre l'exemple pour un noyau Linux 2.4

2.4.1 Installation de FreeS/WAN sur un noyau Linux 2.4

On télécharge les sources du noyau Linux et de FreeS/WAN que l'on décompresse dans le répertoire /usr/usrc et ontre dans le répertoire freeswan-x.xx nouvellement créé.
On lance la commande:

# make menugo

On choisit donc les options du noyau Linux et parmi celles-ci les options de FreeS/WAN :

<*> IP Security Protocol (FreeS/WAN IPSEC)
--- IPSec options (FreeS/WAN)
[*] IPSEC: IP-in-IP encapsulation (tunnel mode)
[*] IPSEC: Authentication Header
[*] HMAC-MD5 authentication algorithm
[*] HMAC-SHA1 authentication algorithm
[*] IPSEC: Encapsulating Security Payload
[*] 3DES encryption algorithm
[*] IPSEC: IP Compression
[*] IPSEC Debugging Option

Ensuite on compile et on installe le noyau.

2.4.2 Configuration

On peut ensuite démarrer l'interface IPSec par la commande :

# /etc/init.d/ipsec start

On obtient une interface dont on peut voir les détails avec la commande ifconfig, par exemple :

# ifconfig ipsec0 Link encap:Ethernet HWaddr 00:E0:7D:D2:00:10 inet addr:192.168.1.1 Mask:255.255.255.0 UP RUNNING NOARP MTU:16260 Metric:1 RX packets:364 errors:0 dropped:25 overruns:0 TX packets:1696 errors:0 dropped:89 overruns:0 collisions:0 RX bytes:27438 (26.7 KiB) TX bytes:267228 (260.9 KiB)

Les paramètres d'IPSec sont principalement contenus dans deux fichiers :
/etc/ipsec.conf qui contient la configuration d'IPsec
/etc/ipsec.secrets qui contient un éventuel secret partagé

Il existe plusieurs types de configuration :
- La configuration manuelle des clés. Les clés sont stockées sur les deux machines.
- La configuration avec un secret partagé. Les clés sont négociées entre les deux machines grâce à IKE qui utilisent notamment l'algorithme de Diffie-Hellman. Un secret identique est stocké sur les deux machines afin de les identifier.
- La configuration avec certificts. Les clés sont négociées entre les deux machines grâce à IKE qui utilisent cette fois des certificats pour identifier les deux machines.

Divers degrés de sécurité peuvent être mis en place. L'utilisation des protocoles AH, ESP ou AH & ESP, la longueur des clés à utiliser, les fontions de hashage à utiliser, etc. sont autant de paramètres à configurer pour avoir un VPN satisfaisant. Il faut aussi prendre en compte la bande passante et la puissance des machines servant de passerelles VPN.

3 Conclusion

Le développement d'Internet et la croissance exponentielle des réseaux provoquent un besoin en sécurité de plus en plus important. De nombreuses applications et protocoles datent de plusieurs années et ne sont pas sécurisés à la base. Le protocole SSL et son implémentation libre OpenSSL permettent d'ajouter cette notion de sécurité à ces protocoles, à savoir l'authenticité et surtout le chiffrement, le tout de façon transparente.
C'est pourquoi OpenSSL est actuellement une solution extrêmement répandue et qui devrait continuer à l'être (notamment car le protocole TLS est devenu standard).
De plus OpenSSL comporte de multiples librairies et fonctions cryptographiques et de nombreux programmes les utilisent. En effet, chacun peut se servir de ces implémentations qui sont disponibles librement. Enfin, rappelons que dissimuler ses sources est une mauvaise méthode en matière de sécurité et qu'il vaut mieux utiliser des outils connus, standards et éprouvés. La suite d'outils OpenSSL confirme cela.

4 À propos de ce document

L'original de ce document se trouve à l'adresse Internet
http://www.gcolpart.com/~reg/ssl/
Permission vous est donnée de copier, distribuer et modifier ce document selon les termes de la licence GNU pour les documentations libres, version 1.2 ou toute autre version ultérieure publiée par la Free Software Foundation.

Cette licence est disponible à l'adresse suivante :
http://www.gnu.org/copyleft/fdl.html

Ce document a été traduit de L^AT_EX par H^EV^EA.