Utiliser les certificats numériques avec Linux Création, configuration des services, accès SSH

Transcription

1 Utiliser les certificats numériques avec Linux Création, configuration des services, accès SSH Copyright (c) Éric Quinton. Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.1 ou toute version ultérieure publiée par la Free Software Foundation ; sans section invariable. Une copie de la présente Licence est incluse dans la section intitulée «Licence de Documentation Libre GNU» Rédaction : Eric Quinton - 05/09/2011 Dernière modification : Éric Quinton - 13/09/ révision 81

2

3 Table des matières I. Introduction... 1 A. Cryptage ou chiffrement?...1 II. Quelques rappels concernant le cryptage...3 A. Principes généraux...3 B. Les fonctions de calcul d'empreinte (hachage)...4 C. Protéger les empreintes des mots de passe : le salage...5 D. Le pseudo-cryptage...5 E. Quel chiffrement utiliser?...6 F. Quelques algorithmes de chiffrement RSA Blowfish DES et triple DES AES Autres... 8 G. Quelques algorithmes de calcul d'empreintes Whirlpool SHA MD H. Algorithme de signature DSA... 9 III. Le cryptage asymétrique...11 A. Comment s'utilise le cryptage asymétrique? Pour crypter un échange Pour signer un fichier...11 B. Le tiers de confiance Les certificats chaînés...13 C. La révocation des certificats...14 D. En résumé IV. Mettre en place une couche TLS dans un serveur...15 A. Quel est le coût d'implémentation d'un chiffrement pour les sessions web?...15 B. OpenSSL C. Les différents types de certificats...15 D. Générer les certificats Créer le certificat racine Créer les clés privée et publique du serveur Créer la requête de certificat qui sera validée par l'autorité racine Signer le certificat localement Faire signer le certificat par une autorité d'enregistrement...17 E. Quelques commandes pour consulter les clés et les certificats Commandes générales Commandes spécifiques pour les certificats p F. Documentation V. Utiliser les certificats dans les serveurs Linux...21 A. Installer le paquet ssl-certs...21 B. Recopier les clés dans le dossier /etc/ssl...21 C. Rajouter des autorités de certification Copier les certificats dans le dossier /etc/ssl/certs Créer un lien vers le certificat Faut-il rajouter tous les certificats des autorités intermédiaires?...22 D. Utiliser les certificats avec Apache Configurer Apache de façon classique Configurer Apache pour utiliser de multiples certificats dans le même serveur...23 E. Intégrer les certificats dans le serveur LDAP...26 F. Intégrer les certificats dans le client LDAP...27 G. Intégrer les certificats dans webmin...27 H. Intégrer les certificats dans CUPS...27 VI. Utiliser la clé privée et la clé publique pour automatiser les échanges SSH...29 A. S'identifier avec le protocole DSA...29 B. S'identifier avec le protocole RSA...30 C. Se connecter à un serveur à partir de son certificat p

4 Utiliser les certificats numériques avec Linux 1. Avec Linux Avec Windows...31 D. Quelques conseils de sécurité...33 VII. Chiffrer les accès aux bases de données...35 A. Configurer les SGBD pour activer le mode SSL...35 B. Configurer les clients pour qu'ils puissent se connecter en mode SSL Utiliser le pilote JDBC PostGreSQL Utiliser le pilote JDBC MySQL Utiliser d'autres mécanismes de connexion...36 C. Se connecter en SSL depuis PHP PostGreSQL MySql VIII. Appendice sur la sécurité...39 A. Quelle longueur pour les clés de chiffrement?...39 B. Le paradoxe des anniversaires...39 C. Longueur des mots de passe Verrouiller les mots de passe Quelques préconisations...41 I. Licence de Documentation Libre GNU (GNU Free Documentation License)

5 Création, configuration des services, accès SSH I. Introduction Ces derniers mois, j'ai publié plusieurs documentations techniques concernant la mise en place de services fonctionnant avec Linux, comme la migration ou l'installation d'une architecture Samba/ldap, l'installation d'un serveur d'impression CUPS, ou des documents plus confidentiels concernant la connexion à des réseaux wifi d'entreprise. Dans ces publications, j'aborde régulièrement certains aspects concernant le cryptage, et plus particulièrement ce qui touche au cryptage asymétrique et à la gestion des certificats. Ce document doit donc être vu comme une synthèse des différents aspects traités auparavant. Il intègre une partie théorique, qui présente les différents cryptages possibles, et une explication concernant la cryptographie asymétrique et l'utilisation des certificats numériques. La seconde partie est plus pratique, et explique comment utiliser les certificats dans les logiciels courants des serveurs Linux. N'étant pas un spécialiste de la cryptographie, il est possible qu'on y trouve quelques raccourcis malheureux, des approximations, voire des contresens ou des erreurs manifestes. Si c'était le cas, n'hésitez pas à me les signaler. A. Cryptage ou chiffrement? Le mot cryptage est un anglicisme provenant de encryption 1, et le terme est banni par l'académie française. Il faut utiliser, à la place, le terme chiffrement. Il est par contre autorisé au Québec comme synonyme de chiffrement. Une fois n'est pas coutume, j'ai largement utilisé le terme «cryptage» dans ce document, en suivant nos amis québécois... 1 cf. 1

6

7 Création, configuration des services, accès SSH II. Quelques rappels concernant le cryptage A. Principes généraux Le cryptage est une opération qui vise à éviter qu'un échange puisse être lu par une personne tierce. Deux types de cryptage existent, le cryptage symétrique et le cryptage asymétrique. Dans le cryptage symétrique (ou cryptage à clé privée), une même clé est utilisée pour crypter et décrypter le message. C'est une technique rapide à mettre en place, mais elle implique que les deux correspondants aient la même clé. Actuellement, l'algorithme AES256 est largement utilisé pour mettre en place un tel cryptage. Il est notamment utilisé dans les cartes bancaires. Le chiffrement symétrique est réalisé par bloc 1. Le message à chiffrer est découpé en plusieurs blocs, de 64, 128 ou 256 bits en général. Un bloc est choisi aléatoirement pour commencer le chiffrement. Ce bloc est chiffré avec la clé de chiffrement. Le bloc suivant est transformé, avant chiffrement, en l'additionnant (addition bit à bit, sans retenue) avec le résultat du chiffrement du bloc précédent, puis est chiffré avec la clé. Les autres blocs sont chiffrés selon le même mécanisme. La sécurité du chiffrement symétrique tient d'une part à la longueur de la clé, et d'autre part à la taille des blocs : plus les blocs sont grands, meilleure sera la sécurité. De plus, en raison du mode de chiffrement, la perte d'un bloc peut être compensée en recalculant sa valeur, à partir des deux blocs continus. On peut également rajouter une valeur de hachage, calculée à partir d'une clé différente et prenant en compte l'intégralité des blocs transmis, pour s'assurer de l'intégrité du message. Le cryptage asymétrique est d'invention assez récente. Il est basé sur le calcul du produit de deux nombres premiers. Sa résistance tient à l'impossibilité actuelle de factoriser le nombre produit autrement que par la «force brute», c'est à dire en testant toutes les combinaisons possibles. Le temps de calcul croît de façon exponentielle avec la taille de la clé. L algorithme le plus connu est le RSA, décrit en 1977 par Ronald Rivest, Adi Shamir et Leonard Adleman. Son principe est simple : deux clés sont générées, et un message crypté avec une des clés ne peut être décrypté qu'avec la seconde, et vice versa. Dans la pratique, une des deux clés générées reste en la possession exclusive de son propriétaire (la clé privée), la seconde étant transmise à tous les correspondants (la clé publique). Selon que l'on veuille envoyer un message chiffré ou s'assurer de l'identité de l'expéditeur, on utilisera soit la clé publique du correspondant pour chiffrer le message, soit la clé privée. Pour de plus amples informations concernant le détail du fonctionnement de l'algorithme, consultez l'article de Wikipedia Rivest, Shamir, Adleman 2. 1 Il est possible de réaliser un chiffrement en continu, chaque bit étant recalculé à partir de la clé de chiffrement. Cette technique est imparable, il est impossible de retrouver le message d'origine, dès lors que la clé est de la taille du message à chiffrer. Néanmoins, comme le message est chiffré «au fil de l'eau», un pirate qui s'introduit au milieu du système (attaque dite de Man in the middle) peut facilement modifier un bit dans le message et, si la structure du message est connue (flux de paiement, par exemple), modifier des informations facilement. De fait, le chiffrement en continu ne permet pas de s'assurer de l'intégrité du message

8 Utiliser les certificats numériques avec Linux B. Les fonctions de calcul d'empreinte (hachage) Le calcul d'empreinte permet de calculer, à partir d'un texte ou d'un fichier, un condensat de longueur fixe, qui a les caractéristiques suivantes : il est unique (il n'existe pas de possibilité pour que deux entrées différentes puisse aboutir à la même empreinte dans ce cas, on parle de collision) ; le texte ou le fichier d'origine ne peut être retrouvé à partir de l'empreinte. Ce mécanisme va être utilisé principalement dans deux cas : d'une part, quand on veut s'assurer que la copie d'un fichier est bien identique à l'original, par exemple dans le cas du téléchargement d'une image ISO 1 ; d'autre part, pour encoder un mot de passe, qui ne pourra pas être décodé. Pour vérifier la cohérence d'un fichier téléchargé, nous appliquerons le processus suivant : le fournisseur du fichier calcule une empreinte, et la publie ; une fois le fichier récupéré, l'empreinte de celui ci est calculée ; si les deux empreintes sont identiques, alors on considère que les deux fichiers sont identiques. Pour stocker les mots de passe, le mécanisme suivant va être utilisé : lors de la création du mot de passe, son empreinte est calculée, et c'est celle ci qui va être stockée en base de données ; au moment où le mot de passe est utilisé, c'est à dire quand son détenteur le saisit, le programme de vérification calcule l'empreinte du texte saisi, puis la compare à la valeur stockée dans la base de données. Si les deux empreintes sont identiques, alors le mot de passe est correct. Voici un exemple de calcul d'empreinte du mot Bonjour en utilisant l'algorithme sha 256 (commande sha256sum) : 8dc2a6966f1be1644ec6b1f7223f47e53de5ad05e1c976736d948e7977a13dd3 Il suffit de modifier une seule lettre, en tapant par exemple bonjour (sans majuscule), pour que le résultat soit totalement différent : 9cec0af bac85c7b908d5e0b9b0ef c5ad8da26f065ad926 Pour qu'un algorithme de hashage soit considéré comme suffisamment sûr, il faut : qu'il ne soit pas possible de créer des collisions (même si, comme le nombre de combinaisons est nécessairement fini la taille du condensat étant fixe cette possibilité ne puisse jamais être totalement exclue) ; que la longueur de stockage soit suffisamment élevée pour que l'on ne puisse pas créer de dictionnaire inverse, c'est à dire une base de données qui permettrait, à partir du condensat obtenu, d'obtenir l'original. Un codage sur 256 bits entraîne 1,158x10 77 combinaisons possibles (2 256 )... L'utilisation de SHA 256 est donc considéré comme sûr. 1 Image d'un disque, qui pourra être reproduit à l'identique 4

9 Création, configuration des services, accès SSH C. Protéger les empreintes des mots de passe : le salage Nous venons de voir qu'une empreinte correspond à une et une seule chaîne, et qu'il n'est pas possible de retrouver la chaîne à partir de l'empreinte. Ça, c'est le cas général. En général, les calculs d'empreintes sont utilisés pour gérer les mots de passe. Malheureusement, les utilisateurs sont rarement inventifs dans le choix des mots de passe. Une étude américaine 1 a permis de relever le top 25 des mots de passe les plus utilisés, et c'est assez navrant... Voici le début de la liste : password qwerty Vous remplacez qwerty par azerty, et vous avez l'équivalent en français! Maintenant, si je calcule l'empreinte de azerty, j'obtiens la valeur suivante : 70b2e56b49d cea3da97a5213b511e68ae905a077cfec6f6a257af8 Si, par hasard, la base de données contenant les empreintes est piratée, ou simplement publiée par erreur (ou accessible...), il suffit de rechercher dans celle ci si une empreinte contenant la chaîne précédente pour retrouver le mot de passe : azerty. Ainsi, un pirate pourra facilement retrouver une bonne partie des mots de passe à partir d'un dictionnaire comprenant les combinaisons les plus fréquentes. Pour pallier cette éventualité, on utilise aujourd'hui la technique dite du «salage». Elle consiste à rajouter une chaîne (non publiée, bien sûr) avant de calculer l'empreinte. Ainsi, si j'insère la chaîne 9d8c47b après le 3ème caractère du mot de passe, je vais calculer l'empreinte de aze9d8c47brty, qui vaut : 05f91406b3665ac5ec8f63599afa50ea786405fd2b9be76732e84d9319d61cd8 Les pirates ne pourront alors plus utiliser un dictionnaire pour rechercher les mots de passe les plus fréquents. D. Le pseudo-cryptage Si le chiffrement permet de garantir la confidentialité d'une information échangée, il présente un inconvénient : un fichier crypté se reconnaît très facilement, et certains gouvernements totalitaires pourraient être tentés de bloquer les échanges cryptés, par l'utilisation de logiciels qui vont analyser les messages échangés et repérer ceux dont les chaînes de caractères sont totalement aléatoires. Pour éviter cela, il est possible de transformer les messages envoyés en appliquant des transformations suffisantes pour les rendre incompréhensibles, mais qui ne seront pas considérés comme aléatoires par les systèmes de surveillance automatiques. Bien sûr, ces messages pourraient être décryptés en quelques jours, à condition qu'ils soient reconnus comme tels, être interceptés, et 1 5

10 Utiliser les certificats numériques avec Linux qu'on y consacre des ressources de calcul importantes, mais cela peut être suffisant : certaines informations n'ont pas besoin de rester confidentielles trop longtemps (scoop journalistique, par exemple). On est typiquement dans le rapport entre les moyens à mettre en œuvre pour décoder une information et sa valeur intrinsèque : dans beaucoup de cas, le «jeu n'en vaudra pas la chandelle». De plus, si le cryptage est autorisé en France, ce n'est pas le cas dans un certain nombre de pays, qui tiennent à pouvoir déchiffrer tous les messages échangés (lutte contre le terrorisme, par exemple). Des technologies de chiffrage classique comme AES ne pourront pas être utilisées, seules celles permettant un déchiffrage seront permises 1. La bibliothèque PERSEUS 2 répond à ces besoins : elle garantit qu'un message échangé ne peut être déchiffré qu'à condition d'y consacrer des ressources très importantes, hors de portée des pirates habituels. Concrètement, l'idée est de chiffrer les données échangées à l'aide de codes convolutifs 3. Une fois chiffré, le code est brouillé à l'aide d'un «bruit» numérique. Avant transmission, les paramètres nécessaires au déchiffrement, générés aléatoirement pour chaque séquence, sont envoyés lors d'une courte session https standard. Le destinataire commence donc par recevoir ces codes à partir desquels il obtiendra sans difficulté la suite de l'échange. Pour accéder aux informations transmises, tout observateur placé sur la ligne, doit de son côté commencer par déchiffrer la première séquence, avant d'opérer une seconde opération de déchiffrement. Comme les codes changent en permanence de façon aléatoire, le pirate doit fournir une puissance de calcul importante pour ne rien perdre d'une communication. L'augmentation des ressources consommées finirait alors par trahir la machine infectée. Autrement dit, l'écoute «systématique» deviendrait prohibitive, alors qu'il reste possible d'intervenir ponctuellement sur un échange donné, en allouant à cette tâche des machines dédiées. En raison de sa faible complexité technique, le pseudo cryptage peut également être mis en place pour protéger des sauvegardes de données : les temps de calcul ne ralentiront pas significativement l'opération, ce qui pourrait se produire avec un chiffrement classique. E. Quel chiffrement utiliser? Le chiffrement asymétrique est très gourmand en ressources, en raison du mode de calcul, mais il permet de s'assurer de l'identité du correspondant. A contrario, le chiffrement symétrique s'exécute rapidement, mais impose que la clé de chiffrement/déchiffrement soit partagée entre les deux correspondants. Plusieurs cas d'utilisation peuvent être identifiés : 1 Mais ça ne signifie pas que le déchiffrage soit facile et à la portée de tous! 2 Pour plus d'informations concernant PERSEUS, un article dans Linux Magazine N 135 : PERSEUS : protéger des communications avec du bruit ( ou une page web : 3 Un code convolutif est un code qui utilise les valeurs obtenues précédemment pour continuer le codage (effet mémoire). Ils sont très souvent utilisés comme codes de détections d'erreurs, notamment dans les transmissions. 6

11 Création, configuration des services, accès SSH l'échange de fichiers : le fichier est crypté au préalable, puis envoyé, par exemple par mél. L'important, c'est que seul le destinataire puisse décrypter le fichier, pas les personnes qui pourraient l'intercepter. On utilisera alors le cryptage asymétrique. La connexion permanente, par exemple pour se connecter au système d'informations de l'entreprise. On crée alors un tunnel crypté. La procédure de cryptage va être réalisée en deux étapes : le cryptage asymétrique va être utilisé pour initier la connexion, pour s'assurer de l'identité de chacun des correspondants ; une clé de cryptage symétrique va alors être échangée entre les deux correspondants, qui ne sera donc connue que d'eux seuls ; le reste de la communication est crypté en mode symétrique, ce qui sera plus performant et moins coûteux en temps machine. le stockage de mots de passe, par exemple dans une base de données. Dans ce cas, soit on utilise une fonction de cryptage symétrique classique, qui permet de recouvrer le mot de passe, soit on préférera l'utilisation d'une fonction de calcul d'empreinte (hachage), associée à la méthode du salage, qui garantira la confidentialité du mot de passe. F. Quelques algorithmes de chiffrement 1. RSA Cf. le début de ce chapitre. 2. Blowfish 1 Blowfish est un algorithme de chiffrement symétrique (i.e. «à clef secrète») par blocs conçu par Bruce Schneier en Il tire son nom du poisson globe japonais (ou fugu), qui en est également l'emblème. Blowfish utilise une taille de bloc de 64 bits et la clé de longueur variable peut aller de 32 à 448 bits. Elle est basée sur l'idée qu'une bonne sécurité contre les attaques de cryptanalyse peut être obtenue en utilisant de très grandes clés pseudo aléatoires. Blowfish présente une bonne rapidité d'exécution excepté lors d'un changement de clé, il est environ 5 fois plus rapide que Triple DES et deux fois plus rapide que IDEA. Malgré son âge, il demeure encore solide du point de vue cryptographique avec relativement peu d'attaques efficaces sur les versions avec moins de tours. La version complète avec 16 tours est à ce jour entièrement fiable et la recherche exhaustive reste le seul moyen pour l'attaquer. Il a été placé dans le domaine public par son créateur ; il n'est protégé par aucun brevet, et son utilisation n'est pas soumise à licence. Cela explique en partie son succès, car ce fut un des premiers algorithmes de chiffrement dont l'utilisation était libre. Il est utilisé dans de nombreux logiciels propriétaires et libres (dont GnuPG et OpenSSH). 3. DES et triple DES 2 Le Data Encryption Standard (DES) est un algorithme de chiffrement symétrique (chiffrement par bloc) utilisant des clés de 56 bits. Son emploi n'est plus recommandé aujourd'hui, du fait de sa lenteur à l'exécution et de son 1 Source : wikipedia Source : wikipedia - 7

12 Utiliser les certificats numériques avec Linux espace de clés trop petit permettant une attaque systématique en un temps raisonnable. Quand il est encore utilisé c'est généralement en Triple DES, ce qui ne fait rien pour améliorer ses performances. DES a notamment été utilisé dans le système de mots de passe UNIX. 4. AES 1 Advanced Encryption Standard ou AES (soit «standard de chiffrement avancé» en français), aussi connu sous le nom de Rijndael, est un algorithme de chiffrement symétrique. Il remporta en octobre 2000 le concours AES, lancé en 1997 par le NIST et devint le nouveau standard de chiffrement pour les organisations du gouvernement des États Unis. 5. Autres... On peut également citer Serpent et Twofish, que l'on retrouve dans des logiciels de cryptage comme Truecrypt ( G. Quelques algorithmes de calcul d'empreintes 1. Whirlpool 2 Whirlpool est une fonction de hachage cryptographique conçue par Vincent Rijmen et Paulo Barreto pour le projet NESSIE. Elle a été nommée d'après la galaxie M51. La fonction utilise une architecture de type Miyaguchi Preneel connue pour sa résistance à la cryptanalyse, cette structure produit des empreintes de 512 bits ( ). En interne, l'algorithme travaille sur 512 bits grâce à une fonction similaire à celle de l'algorithme de chiffrement symétrique AES (auquel Vincent Rijmen a également participé et qui à l'origine s'appelle Rijndael). L'utilisation d'une version modifiée du bloc de chiffrage de AES (appelée W) garantit un système robuste et fiable. 2. SHA SHA 256 (Secure Hash Algorithm) est une fonction de hachage cryptographique conçue par la National Security Agency des États Unis (NSA), et publiée en Elle produit un résultat (appelé «hash» ou condensat) de 256 bits et dérive du SHA 1. SHA 256 est devenu le nouveau standard recommandé en matière de hachage cryptographique après les attaques sur MD5 et SHA MD5 4 L'algorithme MD5, pour Message Digest 5, est une fonction de hachage cryptographique qui permet d'obtenir l'empreinte numérique d'un fichier (...). Il a été inventé par Ronald Rivest en Cette fonction de hachage produit des condensats de 64 bits, dont seuls 56 sont réellement utilisés, les autres servant de code de correction. En 2004, une équipe chinoise découvre des collisions complètes. MD5 n'est donc plus considéré comme sûr au sens cryptographique. On suggère maintenant d'utiliser plutôt des algorithmes tels que SHA 256, RIPEMD 160 ou Whirlpool. 1 Source : wikipedia Source : wikipedia Source : wikipedia Source : wikipedia - 8

13 Création, configuration des services, accès SSH Cependant, la fonction MD5 reste encore largement utilisée comme outil de vérification lors des téléchargements et l'utilisateur peut valider l'intégrité de la version téléchargée grâce à l'empreinte. Elle a été également utilisée par GNU/Linux pour stocker les mots de passe (en utilisant une fonction complémentaire pour compliquer le déchiffrement) 1. H. Algorithme de signature 1. DSA Le Digital Signature Algorithm a été inventé alors que le RSA était encore breveté. Il est basé sur le même principe de clés asymétriques, et est utilisé uniquement pour la signature. En pratique, on le retrouve associé à SSH, notamment pour identifier les serveurs susceptibles de se connecter automatiquement à un autre serveur sans fournir de mot de passe. 1 Aujourd'hui, les distributions Linux utilisent des méthodes de chiffrement bien plus sûres. Vous pouvez consulter le mécanisme utilisé dans votre distribution en consultant, dans le fichier /etc/login.defs, la valeur de ENCRYPT_METHOD. Les dernières versions d'ubuntu utilisent SHA512, qui produit des condensats de 512 bits. 9

14

15 Création, configuration des services, accès SSH III. Le cryptage asymétrique A. Comment s'utilise le cryptage asymétrique? Paul et Julie disposent chacun de clés asymétriques, une clé privée, qu'ils conservent en leur possession, et une clé publique, qu'ils transmettent à leurs correspondants Pour crypter un échange Paul veut envoyer un fichier crypté à Julie. Voici les différentes étapes qu'il va suivre : Julie transmet sa clé publique à Paul ; Paul crypte son fichier avec la clé publique de Julie, puis lui transmet son fichier crypté ; Julie décrypte le fichier avec sa clé privée. 2. Pour signer un fichier Paul veut transmettre un message, et Julie veut être sûre que c'est Paul qui lui envoie : Paul transmet sa clé publique à Julie ; Paul crypte son message avec sa clé privée ; Julie reçoit le message, et le décrypte avec la clé publique de Paul : si le décryptage fonctionne, c'est que c'est bien Paul qui a envoyé le message. B. Le tiers de confiance Bien sûr, cela ne peut fonctionner que : si Paul est sûr que la clé publique fournie par Julie est bien la sienne ; si Julie est sûre que la clé publique fournie par Paul lui appartient bien... Pour cela, Paul et Julie vont demander à un tiers de confiance, c'est à dire quelqu'un dont l'identité est reconnue par tous, de valider leur clé publique. Pour la clé de Paul, ce tiers de confiance va crypter l'empreinte de sa clé publique avec sa propre clé privée. Ce tiers de confiance va donc : récupérer la clé publique de Paul ; s'assurer qu'il s'agit bien de Paul, et pas de quelqu'un d'autre 2 ; calculer l'empreinte de la clé de Paul ; crypter cette empreinte avec sa propre clé privée. Pour s'assurer que la clé de Paul est bien la sienne, Julie va : calculer l'empreinte de la clé de Paul ; utiliser la clé publique du tiers de confiance, pour décrypter l'empreinte cryptée. Si les deux informations sont identiques, alors Julie sera sûre qu'elle est bien en possession de la clé de Paul. Le tiers de confiance est donc une autorité reconnue par tous, qui dispose d'une clé privée, et d'une clé publique qu'il va distribuer. Mais comment éviter que quelqu'un crée son propre certificat, en se faisant passer pour un autre? Après tout, chacun peut facilement créer une clé privée et un certificat, et se faire 1 Par défaut, les logiciels de messagerie, comme Thunderbird, transmettent systématiquement les clés publiques aux correspondants, ce qui permet d'initier les échanges et de faciliter les échanges cryptés futurs. 2 Cela peut être en vérifiant les papiers d'identité, un code fourni dans un document, comme la déclaration d'impôts ou le montant de la dernière facture associé à un numéro de client... 11

16 Utiliser les certificats numériques avec Linux passer pour une société comme Verisign, par exemple 1. Il est possible également d'émettre un certificat comprenant le nom d'une banque, de créer un site ressemblant à s'y méprendre au site institutionnel de celle ci, puis, au moyen de pages web malicieuses, rediriger les internautes vers ce site pirate. Normalement, l'internaute devrait avoir ceci : certificat racine Verisign certificat banque XXX site banque XXX À partir du site pirate, l'architecture sera la suivante : faux certificat Verisign faux certificat de la banque XXX faux site de la banque XXX C'est sur les «épaules» du navigateur que va porter la responsabilité de valider ou non le certificat racine, c'est à dire toute la chaîne de certification. Si le navigateur ne contient pas le certificat racine, il va émettre une alerte : Le navigateur a vérifié plusieurs points : est ce que le nom du site correspond exactement au nom présent dans le certificat? Est ce qu'il existe un certificat racine connu pour ce site? Les navigateurs modernes intègrent les certificats des tiers de confiance. Vous pouvez les consulter, par exemple dans Firefox, à partir du menu Outils Options (ou Édition préférences sous Windows), bouton Avancé, onglet Chiffrement, Afficher les certificats, puis Autorités. N'intégrez jamais des certificats d'autorités qui ne seraient pas présents, à moins que vous ne soyez sûrs de ce que vous faites (autorité interne à une entreprise, par exemple). De même, ne passez jamais outre les alertes concernant la sécurité d'un site, sauf s'il s'agit d'un site interne à votre entreprise (et qu'on vous en a informé au préalable), ou s'il s'agit d'un site internet où vous n'avez pas besoin 1 Il est facile d'intégrer n'importe quelle information dans un certificat auto-généré, et pourquoi pas, le nom d'une société... 12

17 Création, configuration des services, accès SSH de vous identifier (sites d'informations qui utilisent systématiquement le protocole https). 1. Les certificats chaînés Nous l'avons vu, le point faible de la chaîne de certification est le certificat racine initial. Dans la pratique, les sociétés de certification n'utilisent (ou ne devraient utiliser) le certificat racine que très rarement, et uniquement pour créer des autorités de certification intermédiaires. Ainsi, générer un certificat pour un serveur ou pour une personne entraîne souvent une chaîne de certification relativement longue. Voici par exemple la chaîne de certification concernant un site du ministère de l'agriculture : IGC/A : certificat racine de l'état français Agriculture AC Racine : certificat racine, validé par l'igc/a, pour le ministère de l'agriculture Agriculture AC Serveurs : autorité de certification qui délivre les certificats pour les serveurs eap.agriculture.gouv.fr : certificat du site éponyme Pour vérifier le certificat eap.agriculture.gouv.fr, il faudra donc vérifier chacune des signatures des certificats précédents, jusqu'à remonter au certificat racine IGC/A. Le logiciel qui voudra s'assurer de la validité du certificat devra donc : vérifier l'empreinte du certificat eap.agriculture.gouv.fr, cryptée avec la clé privée de Agriculture AC Serveurs, à l'aide de la clé publique correspondante ; cette clé publique est intégrée dans le certificat Agriculture AC Serveurs ; vérifier de la même façon l'empreinte du certificat Agriculture AC Serveurs, cryptée avec la clé privée de Agriculture AC Racine, à partir de la clé publique contenue dans le certificat correspondant ; enfin, vérifier l'empreinte du certificat Agriculture AC Racine, cryptée avec la clé privée de IGC/A, à partir de la clé publique présente dans le certificat éponyme. Si un seul des certificats présentés n'est pas valide (expiré, révoqué...), le certificat eap.agriculture.gouv.fr ne pourra pas être considéré comme sûr. La plus grande difficulté de cette vérification tient au fait qu'il faut disposer de tous les certificats intermédiaires. En général, les certificats racines considérés comme sûrs sont intégrés dans les logiciels, notamment les navigateurs ou les clients de messagerie. Par contre, les certificats intermédiaires doivent être récupérés, soit automatiquement 1, soit manuellement, pour que la vérification puisse se faire. Dans les certificats personnels de type p12, les certificats des autorités intermédiaires sont en principe intégrés. Ce n'est pas toujours le cas pour d'autres certificats : il importe donc soit de les importer manuellement, soit de demander au logiciel qui génère le cryptage (serveur web Apache, par exemple), de présenter la liste des certificats intermédiaires. Il est également important de mettre à jour régulièrement les logiciels qui utilisent les certificats, pour qu'ils puissent intégrer les nouvelles autorités racines, ou pour qu'ils soient purgés des autorités racines qui ne sont plus 1 Les serveurs web comme Apache peuvent fournir les certificats intermédiaires, à condition d'être correctement configurés (il faut qu'ils disposent d'un certificat «bundle» comprenant tous les certificats utilisés) 13

18 Utiliser les certificats numériques avec Linux considérées comme fiables, suite à une attaque se traduisant par une corruption de la chaîne de certification, par exemple. C. La révocation des certificats Un certificat est émis pour une durée déterminée. Toutefois, il peut arriver que ce certificat ne soit plus sûr : il suffit que la clé privée qui lui est attachée soit divulguée pour qu'il ne puisse plus être utilisé. C'est bien le principe même des clés asymétriques : si la clé privée est détenue par quelqu'un d'autre que son propriétaire, la confidentialité des informations échangées ne peut plus être garantie. Ainsi, les autorités de certification éditent régulièrement des listes des certificats qui sont révoqués avant leur date d'expiration (fichiers au format crl principalement). L'adresse où l'on peut trouver les listes de révocation est souvent intégrée dans les certificats. Suite à des attaques informatiques de grande ampleur, il est même arrivé que le certificat racine d'une autorité de certification soit volé, ou utilisé pour générer des certificats frauduleux : ainsi, ce sont tous les certificats émis par cette autorité qui n'ont plus de valeur et qui doivent être révoqués. D. En résumé... Le cryptage asymétrique est basé sur la mise en place d'un couple de clés (également appelé bi clés) ; une information cryptée avec une clé ne peut être décryptée qu'avec l'autre. Une des deux clés est nommée la clé privée, l'autre la clé publique. La clé privée est conservée précieusement par son propriétaire, et ne doit en aucun cas être divulguée. La clé publique est transmise à l'ensemble des correspondants, qui l'utilisent soit pour s'assurer de l'identité de son propriétaire, soit pour lui envoyer des informations cryptées. Pour garantir l'identité du détenteur de la clé publique, celle ci est signée par une autorité de certification reconnue. La signature, ainsi que la clé publique, sont stockées dans un certificat numérique. Un certificat racine est un certificat auto signé par une autorité de certification, qui contient donc la clé publique de cette autorité. Pour vérifier un certificat, il faut impérativement disposer du certificat racine de l'autorité de certification, voire des certificats des autorités intermédiaires. Un certificat a une durée de validité limitée. Il peut être révoqué avant sa date d'expiration ; des listes de certificats révoqués sont régulièrement publiées par les autorités de certification. 14

19 Création, configuration des services, accès SSH IV. Mettre en place une couche TLS dans un serveur Aujourd'hui, les attaques informatiques sont de plus en plus fréquentes, et sont le fait de personnes particulièrement compétentes et souvent dotées de moyens importants ; il ne se passe pas un mois sans qu'une affaire de grande ampleur ne soit relatée dans la presse. Pour cette raison, la mise en place d'échanges cryptés entre les serveurs devient une obligation. C'est le cryptage TLS (Transport Layers Security), qui est en général utilisé ; ils est basé sur le cryptage asymétrique. Transport Layer Security (TLS), anciennement nommé Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé à l'origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en Transport Layer Security (TLS) par l'ietf suite au rachat du brevet de Netscape par l'ietf en Comme nous l'avons vu précédemment, nous avons besoin : pour chaque serveur, d'une clé privée associée à une clé publique ; d'une autorité de certification, qui va certifier la clé publique ; de la clé publique de l'autorité de certification, pour vérifier la validité des clés qu'elle aura certifié. A. Quel est le coût d'implémentation d'un chiffrement pour les sessions web? Google, en 2010, a activé par défaut le https pour tous les comptes GMAIL. Il considère que le TLS SSL consomme moins de 1 % de la charge CPU, moins de 10 Ko par connexion, et 2 % de la charge réseau 2. Si, il y a quelques années, les performances des ordinateurs étaient susceptibles de freiner le basculement vers le protocole https, ce n'est plus vraiment le cas aujourd'hui, et cet argument technique n'est plus recevable pour refuser de sécuriser une connexion. B. OpenSSL OpenSSL est un ensemble d'outils qui permettent de gérer le chiffrement TLS. Disponible sous licence Apache, il existe pour quasiment tous les systèmes d'exploitations, et est, de fait, le plus fréquemment utilisé. C. Les différents types de certificats Les clés publiques, privées, certificats sont fournis selon différents formats. Voici les principaux : DER : Utilisé pour encoder des certificats X509 en notation ASN.1 Extensions usuelles :.der,.cer,.crt,.cert PEM Privacy Enhanced Mail. C'est du DER encodé en base64 auquel sont ajoutées des en têtes en ASCII. Extensions usuelles :.pem,.cer,.crt,.cert PKCS#12 Personnal Information Exchange Syntax Standard. C'est un standard pour stocker des clés privées, des clés publiques et des certificats 1 Source : wikipedia Données extraites d'un document rédigé par Verisign, SSL : la solution contre les attaques par Firesheep et les détournements de session HTTP, téléchargeable depuis le site 15

20 Utiliser les certificats numériques avec Linux en les protégeant en général par mot de passe. Les données sont stockées en format binaire. Extension :.p12,.pfx (pour Microsoft). Les certificats personnels sont en format p12. Ils contiennent à la fois la clé privée et la clé publique, et doivent donc être protégés avec un mot de passe. D. Générer les certificats Deux possibilités s'offrent à nous : soit nous signons nous mêmes nos clés publiques, soit nous faisons appel à une autorité de certification pour réaliser cette signature. Pour commencer, nous allons signer nous mêmes nos clés publiques. C'est la seule solution si vous n'avez pas accès à une autorité de certification. 1. Créer le certificat racine Nous allons d'abord créer la clé privée de l'autorité de certification racine : openssl req -new -x509 -keyout cacert.pem -out cacert.pem -days 3650 Lors de la procédure, le programme demande un mot de passe : c'est celui qui devra être fourni à chaque demande de signature d'un certificat. Ici, le certificat racine est valide 10 ans (3650 jours). Nous allons maintenant générer le certificat de l'autorité de certification, qui va être utilisé pour valider les certificats des serveurs ; ce certificat contient donc la clé publique de l'autorité de certification : openssl x509 -in cacert.pem -out cacert.crt 2. Créer les clés privée et publique du serveur Nous allons maintenant générer la bi clé (clé privée, clé publique) du serveur : openssl genrsa -out server.key 1024 Puis nous la protégeons pour éviter que quiconque, à part root ou les process autorisés, puissent y accéder : chmod 600 server.key 3. Créer la requête de certificat qui sera validée par l'autorité racine A partir de la clé privée, nous allons préparer une requête qui sera transmise à l'autorité de certification. Cette requête contient non seulement la clé publique, mais également un certain nombre d'informations, dont le nom du serveur. openssl req -new -key server.key -out server.csr Une fois la commande lancée, un certain nombre de champs vont devoir être renseignés. Les champs laissés à vide doivent comporter un point (.). Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]: MA SOCIETE Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:monserveur.societe.com Address []:. Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: 16

21 Création, configuration des services, accès SSH Les deux derniers champs sont laissés à vide. Attention : le Common Name doit impérativement correspondre au nom du serveur qui va être utilisé dans les requêtes. Si vous utilisez un serveur DNS, vous devrez donner le nom complet. Sinon, indiquez uniquement le nom de la machine (et renseignez, sur les clients, le fichier hosts pour faire la correspondance). De nombreux soucis de fonctionnement de la couche TLS sont liés à une gestion des noms erronée... Certaines autorités de certification autorisent le rajout de plusieurs noms, ce qui fait que le même certificat pourra être utilisé avec plusieurs noms DNS. C'est parfois utilisé pour les serveurs de messagerie, qui peuvent ainsi fournir le même certificat tant pour un accès en mode TLS pop (pop.monserveur.fr), que webmail (webmail.monserveur.fr), etc. Il est aussi possible de créer un certificat avec un caractère «joker», par exemple *.mondomaine.com : tous les sites du domaine seront validés par le même certificat. On peut également créer plusieurs certificats à partir du même couple clé privée clé publique, pour chaque nom DNS qui sera utilisé dans le serveur. C'est parfois mis en œuvre dans les serveurs web, à condition d'activer le support multiple des certificats dans Apache (activation de SVI). 4. Signer le certificat localement Si vous n'utilisez pas les services d'une autorité d'enregistrement, vous devez générer vous même le certificat : openssl x509 -req -days in server.csr -CA cacert.pem -out server.crt Si vous avez un message d'erreur du type : cacert.srl: No such file or directory il faut rajouter l'option suivante : CAcreateserial, qui va créer le fichier contenant le numéro de série. La commande devient donc : openssl x509 -req -in server.csr -CA cacert.pem -CAkey cacert.pem -out server.crt -Cacreateserial Ne lancez cette commande qu'une seule fois... Le fichier server.crt est donc un certificat, qui contient non seulement la clé publique de notre serveur, mais également son empreinte cryptée avec notre certificat racine. 5. Faire signer le certificat par une autorité d'enregistrement Si vous disposez d'une autorité de certification, envoyez le fichier qui vient d'être généré (server.csr) pour recevoir, en retour, la clé publique. En général, les champs Organization Name et Organizational unit name vous sont imposés : consultez votre autorité de certification pour connaître les bonnes informations à fournir. Il vous faut également récupérer le certificat racine (équivalent du cacert.crt, la clé publique de l'autorité de certification) qui permettra de vérifier la validité du certificat qui vous sera fourni par l'autorité de certification. 17

22 Utiliser les certificats numériques avec Linux E. Quelques commandes pour consulter les clés et les certificats 1. Commandes générales Pour visualiser le contenu d'une clé privée : openssl rsa -in server.key -text Pour visualiser la clé publique associée : openssl rsa -in server.key -pubout Pour visualiser un certificat : openssl x509 -in server.crt -text -noout Pour vérifier la validité du certificat : openssl verify -CAfile cacert.crt server.crt 2. Commandes spécifiques pour les certificats p12 Ces certificats contiennent : la clé privée ; la clé publique ; l'empreinte cryptée de la clé publique, signée par l'autorité de certification. Il est parfois nécessaire d'extraire la clé privée, et de disposer d'un certificat sans la clé privée (uniquement avec la clé publique). C'est notamment indispensable pour configurer certains réseaux wifi dont l'identification est basée sur des certificats, notamment avec Linux. Pour extraire le certificat (sans la clé privée) : openssl pkcs12 -in eric.quinton.p12 -out eric.quinton.pem -nokeys -clcerts Le programme vous demande de taper le mot de passe : Enter Import Password: MAC verified OK Le certificat est maintenant stocké dans le fichier eric.quinton.pem. Comme il s'agit de la clé publique, celle ci n'a pas besoin d'être protégée par un mot de passe. Pour extraire la clé privée : openssl pkcs12 -in eric.quinton.p12 -out eric.quinton.key -nocerts Le programme vous demande de taper le mot de passe : Enter Import Password: MAC verified OK Puis il vous demande d'entrer un nouveau mot de passe pour protéger la clé privée : Enter PEM pass phrase: Verifying - Enter PEM pass phrase: La clé privée est maintenant stockée dans le fichier eric.quinton.key. Vérifier la validité du certificat : openssl verify -CApath /etc/ssl/certs eric.quinton.pem 18

23 Création, configuration des services, accès SSH Avant de lancer cette commande, il faut s'assurer au préalable que tous les certificats intermédiaires sont correctement insérés dans le dossier /etc/ssl/certs (cf. chapitre suivant). F. Documentation

24

25 Création, configuration des services, accès SSH V. Utiliser les certificats dans les serveurs Linux Les certificats numériques peuvent être utilisés pour deux usages : pour identifier le serveur, lorsqu'il fournit un service (service web, par exemple) ; pour échanger des informations cryptées avec un autre serveur. L'utilisation des certificats impose que le serveur dispose des certificats des autorités de certification racines, voire des certificats des autorités intermédiaires. Dans Linux, un paquetage permet de gérer ces certificats à un seul endroit, qui pourra être utilisé par toutes les applications qui souhaitent vérifier la validité d'un certificat. A. Installer le paquet ssl-certs Nous allons installer ce paquet : apt-get install ssl-certs qui va créer le dossier /etc/ssl, et deux sous dossiers : certs : comprend tous les certificats. Le dossier est normalement en accès en lecture à tous ; private : est utilisé pour le stockage de la clé privée du serveur. Par défaut, le dossier private est uniquement accessible au compte root, et a un modulus de 700. Nous allons modifier les droits, pour que tous les services qui ont besoin d'accéder à la clé privée puisse le faire, notamment ceux qui ne se lancent pas avec le compte root, comme openldap, par exemple. chmod 750 /etc/ssl/private chmod 640 /etc/ssl/private/* chown -R root:ssl-cert /etc/ssl/private/ À partir de maintenant, les membres du groupe ssl cert pourront accéder à la clé privée du serveur. Ainsi, pour openldap, nous lancerons la commande : usermod -a -G ssl-cert openldap Le compte openldap fait maintenant partie du groupe ssl cert, et peut donc accéder à la clé privée. B. Recopier les clés dans le dossier /etc/ssl Maintenant que l'arborescence /etc/ssl est prête, il faut que nous recopions nos clés privée et publique dans les sous dossiers : cp server.pem /etc/ssl/certs/ chmod 644 /etc/ssl/certs/server.pem cp server.key /etc/ssl/private/ C. Rajouter des autorités de certification Si la plupart des autorités de certification sont intégrées grâce à ssl certs, ce ne sont que les autorités racines. Si certains certificats sont générés par des autorités intermédiaires, il faudra intégrer leurs certificats dans le dossier /etc/ssl/certs/. 1. Copier les certificats dans le dossier /etc/ssl/certs Voici un exemple de commande à réaliser. Le certificat est d'abord copié, puis les droits d'accès sont positionnés pour que tous les services puissent y accéder : cp AgricultureACRacine.pem /etc/ssl/certs/ 21

26 Utiliser les certificats numériques avec Linux chmod 644 /etc/ssl/certs/agriculture*.pem 2. Créer un lien vers le certificat Nous allons maintenant créer un lien vers ce certificat, pour que le programme de vérification des signatures puisse le retrouver facilement. En effet, les certificats indiquent quelle est l'autorité qui les a validé. Voici un exemple concernant un serveur : Pour valider ce certificat, le programme doit rechercher le certificat émis par Agriculture AC Serveurs dans le dossier /etc/ssl/certs. Plutôt que de parcourir tout le dossier, ce qui deviendrait vite fastidieux, il va calculer un condensat du nom du certificat, puis rechercher un fichier qui correspondra à ce condensat : ce sera notre lien. Voici la commande qui va permettre de calculer le condensat : cd /etc/ssl/certs sudo ln -s AgricultureACRacine.pem `openssl x509 -hash -in AgricultureACRacine.pem -noout`.0 Pour ce certificat, nous aurons donc, dans notre dossier, les fichiers et liens suivants : lrwxrwxrwx 1 root root :05 72e7eb8f.0 -> AgricultureACRacine.pem -rw-r--r-- 1 root root :04 AgricultureACRacine.pem 3. Faut-il rajouter tous les certificats des autorités intermédiaires? Si certains logiciels sont capables de demander au serveur appelé de lui fournir les certificats intermédiaires, ce n'est pas toujours le cas... Pour éviter les problèmes, et dès lors que les échanges sont réalisés entre des serveurs connus, il est préférable d'intégrer les autorités intermédiaires. Dans tous les cas de figure, il faut que l'autorité racine soit présente : elle ne pourra jamais être téléchargée automatiquement depuis les serveurs appelés. C'est la base de la sécurité du cryptage asymétrique, le certificat racine étant celui de l'autorité de confiance reconnue comme sûre. D. Utiliser les certificats avec Apache Le serveur web Apache est capable de crypter une communication via le protocole SSL. Nous allons étudier deux cas : 22

27 Création, configuration des services, accès SSH le premier, le plus simple, consiste à utiliser un seul certificat pour crypter le site. L'inconvénient, c'est que le certificat doit avoir le même nom que le site appelé ; le second permet de contourner cette limitation, et fait appel à SNI, un outil permettant d'utiliser plusieurs certificats dans le même serveur Apache (un par site), tout en conservant une seule adresse IP. 1. Configurer Apache de façon classique Nous allons activer le support du ssl dans Apache : a2enmod ssl puis activer le site par défaut : a2ensite default-ssl. Ces deux commandes créent des liens depuis les dossiers /etc/apache2/[sites mods] available vers /etc/apache2/[sites mods] enabled. Il faudra redémarrer le service Apache pour que la configuration soit prise en compte, mais nous ferons cela plus tard. Nous allons maintenant éditer le fichier /etc/apache2/sites available/default ssl, et modifier les lignes suivantes : SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key Ces deux lignes correspondent au certificat contenant la clé publique et à la clé privée. Si les certificats ont été générés par une autorité de certification intermédiaire, vous devez très probablement disposer d'un fichier contenant le mot bundle (paquet, en anglais). C'est un fichier qui contient le certificat, ainsi que tous les certificats des autorités intermédiaires. Ce fichier sera transmis si nécessaire aux applications qui le demanderont. Pour cela, vous devrez alors renseigner la ligne suivante : SSLCertificateChainFile /etc/ssl/certs/server-bundle.pem Enfin, nous allons indiquer le certificat racine permettant de valider notre certificat serveur : SSLCACertificateFile /etc/ssl/certs/cert_igca_rsa.pem Vous pouvez également, ici, indiquer simplement le chemin d'accès au fichier (à condition que le lien sur le condensat ait été réalisé, cf. ci dessus) : SSLCACertificatePath /etc/ssl/certs/ Néanmoins, la commande précédente est plus rapide à l'exécution... Il ne vous reste plus qu'à redémarrer votre service apache : service apache2 restart 2. Configurer Apache pour utiliser de multiples certificats dans le même serveur 1 Avant d accéder à une page web cryptée (protocole https), le navigateur va réaliser deux vérifications : 1 Cette configuration n'a pas été testée en grandeur réelle : il est possible que certains paramètres soient erronés, ou que des approximations aient été réalisées. 23

28 Utiliser les certificats numériques avec Linux d une part, la signature du certificat présenté par le site web est vérifiée par rapport à un certificat «sûr», à savoir le certificat de signature délivré par l autorité de certification (certificat racine), certificat qui est intégré dans le navigateur ; d autre part, le nom présenté dans le certificat est confronté au nom du site auquel on cherche à accéder : s il n y a pas concordance, le navigateur le signale. Dans le protocole SSL v.2, les concepteurs ont prévu qu à un site correspond un certificat. Mais avec le déploiement des «virtual hosts», qui permettent de faire héberger de multiples sites dans le même serveur, cette approche ne tient plus. Cette situation ne serait, en soi, pas vraiment problématique, si le protocole ne prévoyait pas que le serveur doit fournir le certificat, basée sur l adresse IP de destination, avant qu il puisse lire le nom du domaine (le nom du site). Ainsi, il n est pas possible de fournir plusieurs certificats pour une même adresse IP. De même, si le nombre d'adresses était illimité, le problème ne se poserait pas non plus : il suffirait de créer autant d'adresses IP que de sites hébergés, et ce serait réglé. Tant que nous utiliserons la norme IPv4, dont toutes les adresses ou quasiment ont été attribuées, cette solution n'est pas envisageable. Dans une dizaine d'années, il est probable que le basculement vers IPv6 aura levé cette limitation. Pour remédier à ce problème, deux évolutions ont été mises en œuvre. La première consiste à autoriser la création de certificats «génériques», où le nom du domaine contiendrait des caractères génériques ; par exemple, on pourrait créer un certificat *.mondomaine.com. Tous les sites de ce domaine pourraient alors utiliser le même certificat. Cette solution présente des avantages, mais également pas mal d inconvénients, et notamment le fait de ne pas avoir la liste exaustive des sites rattachés. Les risques de rajout «intempestif» d un site à partir d un certificat générique pourraient être assez importants. La seconde solution a consisté à faire évoluer la norme SSL TLS, en autorisant le serveur à lire le nom du domaine pendant la négociation SSL, et donc d envoyer le bon certificat correspondant à un vhost particulier. Cette extension s appelle Server Name Indication (SNI), et est implémentée dans tous les navigateurs récents. Elle n est pas supportée dans Internet Explorer 7 dans Windows XP, mais l est dans les versions des OS de Microsoft à partir de Vista. Le support de SNI est implémenté dans Apache à partir de la version , mais nécessite également que OpenSSL soit en version 0.9.8j. Pour Ubuntu , le support serait total 1. Nous allons d'abord activer le site SSL par défaut, qui ne devra pas accepter le mode SVN, pour des raisons de compatibilité avec d'anciens navigateurs : cd /etc/apache2/sites-available mv default-ssl 00_default-ssl Éditez le fichier 00_default ssl : <IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin adresse_admin@monsite.com 1 Les tests n'ont pas été menés complètement, faute de temps 24

29 Création, configuration des services, accès SSH DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/ssl_access.log combined Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from / ::1/128 </Directory> SSLEngine on SSLCertificateFile {{/etc/ssl/certs/server.pem}} SSLCertificateKeyFile {{/etc/ssl/private/server.key}} SSLCACertificatePath /etc/ssl/certs/ <FilesMatch "\.(cgi shtml phtml php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> NameVirtualHost *:443 # Go ahead and accept connections for these vhosts # from non-sni clients SSLStrictSNIVHostCheck off </IfModule> Activons maintenant le mode ssl : a2enmod ssl a2ensite 00_default-ssl service apache2 restart Nous allons maintenant configurer nos différents hôtes virtuels. Auparavant, nous avons créés autant de certificats que de sites à identifier. Voici un exemple concernant un site appelé informatique.masociete.com, qui devra n'être accessible qu'en https. Nous allons créer le fichier /etc/apache2/sites available/50_informatique.conf : <VirtualHost *:80> 25

30 Utiliser les certificats numériques avec Linux ServerName informatique.masociete.fr ServerPath /informatique.masociete.fr RewriteEngine On RewriteRule ^ [R] </VirtualHost> Et nous paramétrons maintenant notre accès en mode https : <VirtualHost *:443> ServerAdmin administrateur@masociete.fr ServerName informatique.masociete.fr ServerPath /informatique.masociete.fr DocumentRoot /opt/donnees/informatique SSLEngine on Nous indiquons maintenant la clé publique signée, envoyée par l autorité de certification : SSLCertificateFile /etc/ssl/certs/informatique_masociete_fr.pem et la clé privée, commune pour l ensemble du serveur : SSLCertificateKeyFile /etc/ssl/private/server.key ainsi que le certificat de l autorité racine (ici, celle de l administration) : SSLCACertificateFile /etc/ssl/certs/igca-racine-serveur.crt </VirtualHost> Il reste à activer notre site : a2ensite 50_informatique.conf service apache2 reload Si tout se passe bien, vous pourrez accéder à votre site informatique.masociete.com avec un certificat qui sera correctement reconnu. E. Intégrer les certificats dans le serveur LDAP 1 Les échanges vers un serveur LDAP, soit depuis un client, soit depuis un autre serveur, peuvent être également chiffrés. La configuration est assez simple à mettre en œuvre. Dans le fichier /etc/ldap/slapd.conf, qui contient la configuration de votre annuaire LDAP, modifiez les lignes suivantes : TLSCertificateFile /etc/ssl/certs/server.pem TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCACertificateFile /etc/ssl/certs/cacert.pem TLSCACertificatePath /etc/ssl/certs Les deux dernières instructions peuvent être utilisées l'une à la place de l'autre, selon la configuration locale. Pour pouvoir exécuter les commandes ldap depuis un terminal, il faut également indiquer où trouver le certificat racine, dans le fichier /etc/ldap/ldap.conf : TLS_CACERT /etc/ssl/certs/cacert.pem TLS_CACERTDIR /etc/ssl/certs Insérez au moins une des deux instructions. Si vous conservez les deux, conservez l'ordre tel qu'il est noté ci dessus. 1 Pour plus d'informations sur la configuration d'un annuaire openldap, consultez le document Migrer Samba-Ldap depuis Mandriva CS3/CS4 vers Ubuntu server 10, 26

31 Création, configuration des services, accès SSH F. Intégrer les certificats dans le client LDAP Le client openldap, utilisé par exemple pour identifier les utilisateurs à partir d'un serveur Ldap, se configure à partir du fichier /etc/ldap.conf 1. Voici les informations à indiquer pour vérifier les certificats présentés : ssl start_tls ssl on tls_checkpeer yes tls_cacertfile /etc/ssl/certs/igca-racine-serveur.crt Évidemment, on peut également n'indiquer que le chemin des certificats : tls_cacertdir /etc/ssl/certs G. Intégrer les certificats dans webmin Par défaut, webmin génère ses propres certificats. Il est possible de lui faire utiliser les certificats que nous venons de générer. Pour cela : connectez vous à webmin ( Choisissez webmin > webmin Configuration choisissez SSL Encryption, puis positionnez vous dans l'onglet SSL Settings(l'onglet par défaut) ; Sélectionnez dans le serveur l'emplacement de votre clé privée, puis cochez Certificate file : separate file, et indiquez l'emplacement de votre clé publique ; Validez : le nouveau certificat va être utilisé à la place de l'ancien. H. Intégrer les certificats dans CUPS Contrairement à d'autres logiciels, CUPS ne permet pas d'indiquer où se trouvent la clé privée et le certificat, mais les stocke dans un dossier ; les fichiers doivent avoir un nom bien précis (server.key et server.crt). La configuration va donc consister à créer (ou à remplacer) des liens vers la clé privée et le certificat dans le dossier ad hoc. Voici les commandes à exécuter : cd /etc/cups/ssl rm -f * ln -s /etc/ssl/private/server.key server.key ln -s /etc/ssl/certs/server.pem server.crt Relancez cups pour lui faire prendre en compte la modification : service cups restart 1 Il ne faut pas confondre le fichier /etc/ldap/ldap.conf, utilisé pour les commandes natives ldap (ldapadd, ldapmodify, par exemple) et le fichier /etc/ldap.conf, utilisé par Linux pour interroger un annuaire (liste des utilisateurs, groupes, identification...) 27

32

33 Création, configuration des services, accès SSH VI. Utiliser la clé privée et la clé publique pour automatiser les échanges SSH Lorsque l'on gère un parc de serveurs, il est fréquent de vouloir automatiser les tâches d'exécution, et d'exécuter ou copier des fichiers depuis un serveur dans un autre. Le programme ssh (et son complément, scp, pour la copie de fichiers) permet d'accéder à des serveurs distants en chiffrant la communication. Il autorise plusieurs modes de connexion, dont l'un utilise le classique couple login/mot de passe, et l'autre l'identification par clé publique/clé privée. Ce second mode permet ainsi d'automatiser l'exécution de scripts depuis un serveur vers un (ou plusieurs) autre(s) serveur(s). Le principe est simple : la clé publique du serveur qui veut se connecter est intégrée dans un fichier spécial (~/.ssl/authorized_keys) dans le serveur cible. Au moment de la connexion, le serveur cible vérifie avec la clé publique qui est stockée dans ce fichier l'identité du serveur appelant. Deux algorithmes de signatures sont utilisables : l'un est le DSA, l'autre le RSA. Le DSA est l'algorithme le plus usuel (et le premier utilisé avec ssh), mais nous verrons également comment utiliser les clés générées avec le protocole RSA pour assurer l'identification. Par convention, et pour présenter les exemples, le serveur Pluton va exécuter une commande dans le serveur Neptune (commande ls, par exemple). A. S'identifier avec le protocole DSA Dans le serveur Pluton, et dans le dossier /root/.ssh, nous allons générer le couple de clés DSA : ssh-keygen -t dsa Nous conservons tous les choix par défaut (noms des fichiers, pas de passphrase). Le programme génère deux fichiers : id_dsa, la clé privée id_dsa.pub, la clé publique. Le nom des fichiers doit impérativement être conservé, sinon SSH n'arrivera pas à retrouver ses clés. Nous recopions maintenant la clé publique dans Neptune : scp /root/.ssh/id_dsa.pub Neptune:/root/ puis, dans le serveur Neptune, nous rajoutons la clé publique au fichier authorized_keys : cat /root/id_dsa.pub >>/root/.ssh/authorized_keys Le fichier id_dsa.pub peut maintenant être supprimé : rm /root/id_dsa.pub Il nous reste à tester... Depuis Pluton, la commande : ssh Neptune -l root ls affiche la liste des fichiers de /root sans demander de mot de passe. 29

34 Utiliser les certificats numériques avec Linux B. S'identifier avec le protocole RSA La procédure est identique, hormis en ce qui concerne l'extraction de la clé publique. Dans le serveur Pluton, si nous ne l'avons pas déjà fait, nous créons le couple clé privée/clé publique, avec openssh : cd /root/.ssh openssl genrsa -out server.key 1024 Ce fichier pourra être utilisé pour obtenir un certificat numérique, mais c'est une autre histoire! Ce qui nous intéresse ici, c'est d'extraire la clé publique, dans un format qui pourra être compris par le programme ssh. Il faut également savoir que le programme ssh impose le nom de la clé privée et celui de la clé publique, qui doivent être id_rsa pour la clé privée, et id_rsa.pub pour la clé publique. De plus, ces fichiers doivent être présents dans le dossier ~/.ssh. Ce dossier doit impérativement avoir des droits positionnés en 700 (seul le propriétaire peut y accéder). Fidèles à notre habitude, nous allons maintenant déplacer la clé privée dans le dossier /etc/ssl/private : mv server.key /etc/ssl/private/ puis nous allons créer un lien dans le dossier.ssh vers ce fichier, en lui donnant le nom id_rsa : ln -s server.key id_rsa et enfin, nous allons extraire la clé publique, en la configurant dans le bon format : ssh-keygen -y -f id_rsa > id_rsa.pub Il ne nous reste plus qu'à recopier cette clé publique dans le serveur Neptune : scp /root/.ssh/id_rsa.pub Neptune:/root/ puis, dans le serveur Neptune, à intégrer cette clé publique dans la liste des clés autorisées : cat /root/id_rsa.pub >>/root/.ssh/authorized_keys Grâce à cette opération, toutes les connexions initiées par Pluton seront autorisées. C. Se connecter à un serveur à partir de son certificat p Avec Linux Si vous disposez d'un certificat numérique au format p12 (qui contient à la fois votre clé privée et votre clé publique), vous pourriez être tenté de vous connecter directement à votre serveur. Voici les commandes à réaliser... 1 Cette méthode présente beaucoup d'avantages. Il est ainsi possible de donner des accès à un serveur à plusieurs informaticiens, sans que ceux-ci aient besoin de connaître le mot de passe root : ils n'ont besoin de gérer que leur mot de passe de la clé privée, et ce quel que soit le serveur à atteindre. De plus, pour révoquer l'accès à un serveur, il suffit de supprimer leur clé publique du fichier authorized_keys, sans avoir besoin de modifier les autres mots de passe. On pourrait multiplier les exemples ou les situations. Toutefois, cela ne peut fonctionner qu'à condition que la clé privée soit correctement protégée, avec un mot de passe non trivial, suffisamment long, et stocké de préférence dans un espace crypté (notamment dans les ordinateurs portables). 30

35 Création, configuration des services, accès SSH Nous allons dans un premier temps extraire le couple clé privée/clé publique du certificat p12, sans le certificat, et en le protégeant par un mot de passe : openssl pkcs12 -in eric.quinton.p12 -out id_rsa -nocerts Enter Import Password: MAC verified OK Enter PEM pass phrase: Verifying - Enter PEM pass phrase: La clé privée est protégée par un mot de passe, que j'espère non trivial... Le reste de la procédure est identique (cf. paragraphe précédent). Il faut extraire la clé publique id_rsa.pub, puis la recopier dans le serveur distant, et l'intégrer au fichier /root/.ssh/autorized_keys. Pour accéder à votre serveur, il ne vous restera donc plus qu'à lancer une commande ainsi : ssh -l root Neptune ls -l Le programme vous demandera alors le mot de passe de votre clé privée, et le tour sera joué! 2. Avec Windows Si vous utilisez le logiciel Putty, vous devrez générer un couple clé publique/clé privée à partir du programme puttygen.exe, Putty utilisant son propre format de clés. De plus, il ne sait pas importer les clés RSA, mais uniquement les clé DSA. Vous avez également la possibilité d'installer cygwin 1. Cygwin est une émulation Linux fonctionnant sous Windows. Il permet de lancer une console, dans laquelle vous pourrez saisir toutes les commandes Linux intégrées, dont openssl, par exemple. De plus, à l'usage, il fonctionne mieux que Putty, particulièrement avec des programmes comme vim, et gère mieux les jeux de caractères. Si vous n'accédez à vos serveurs qu'en mode ssh, je ne peux que vous conseiller d'utiliser cygwin plutôt que Putty 2. Pour réaliser l'installation, il faut télécharger le fichier setup.exe, puis l'installation des modules souhaités est réalisée soit depuis internet, soit depuis un dossier local, si le téléchargement a été réalisé au préalable. Voici le déroulement de l'installation. Passez les deux premiers écrans, en conservant les choix par défaut, puis choisissez le mode d'accès à Internet : 1 2Putty est pratique en cas de dépannage impromptu, en raison du fait qu'il n'a pas besoin d'être installé ou configuré pour être utilisé depuis un poste. 31

36 Utiliser les certificats numériques avec Linux Sélectionnez votre miroir : Tapez ensuite le nom du module à installer, ici ssh : 32

37 Création, configuration des services, accès SSH Cliquez sur default pour passer à Install, et lancez l'installation. Cygwin s'installera et vous créera une icône sur le bureau. Pour installer les clés privée et publique (id_rsa et id_rsa.pub), lancez une première fois Cygwin pour qu'il crée les dossiers adéquats, puis recopiez les deux fichiers dans le dossier c:\cygwin\home\votre_login\.ssh\, comme vous le feriez depuis une machine Linux. Vous pouvez alors taper vos commandes ssh ou scp comme d'habitude, le programme vous demandera simplement votre mot de passe de clé privée. D. Quelques conseils de sécurité... En général, l'accès par clés est initié à partir d'un serveur central vers l'ensemble du parc de serveurs. C'est dire que le serveur central doit être particulièrement protégé, un accès en root à celui ci permettant un accès général à tous les serveurs. Dans le cas où on met en place une architecture de ce type, voici quelques conseils de base : supprimez le mot de passe de root (pour les OS récents, comme Ubuntu) : vous ne pourrez alors plus vous connecter directement avec ce login, vous devrez passer soit par un certificat, soit par un compte local, puis lancer la commande sudo s pour basculer en root ; la connexion s'effectuant à partir d'une machine centrale par certificat, vous pouvez mettre un mot de passe root (ou d'un compte administrateur local) différent pour toutes les autres machines. Évitez absolument les mots de passe triviaux, l'idéal étant d'avoir une phrase comportant 4 types de caractères différents, par exemple «Un plus 1 = deux» ; par défaut, les connexions sont enregistrées dans le fichier /var/log/auth.log, avec une rotation sur 4 semaines. Vous pouvez modifier les paramètres d'enregistrement des traces en éditant le fichier /etc/logrotate.conf : 33