|
Julien Thomas - TELECOM Bretagne
|
![]()
|
|
Informations
Déploiement d'applications
Sécurité des applications
Sécurité SELinux
|
Introduction à SSL et aux certificationsSSL et chaînes de certificationSSL (Secure Sockets Layers) est un procédé de sécurisation. Le standard SSL a été mis au point par Netscape, en collaboration avec Mastercard, Bank of America, MCI et Silicon Graphics. Il repose sur un procédé de cryptographie par clef publique. Son principe consiste à établir un canal de communication chiffré entre deux machines après une étape d'authentification. Le système SSL n'assure pas le chiffrement par lui-même, étant donné qu'il est indépendant du protocole utilisé. En effet, SSL se comporte comme une couche supplémentaire abstraite située entre la couche application et la couche transport. Le mécanisme de chiffrement est négocié entre les deux entités. Les certificats ont pour but d'assurer l'authentification des entités. Il s'agit de clés RSA publiques émises par les entités. Ces certificats sont ensuite vérifiées lors de l'utilisation des clés privées en tant que preuves (technique de signature). Les chaînes de certifications sont utilisées pour simplifier (et aussi assurer) l'authentification des certificats des entités. Ainsi, chaque client désirant utiliser un service a besoin de simplement connaître la liste des certificats root, ceux étant internationalement reconnus. A partir de ces certificats, il est possible de valider l'authenticité d'un serveur si son certificat est signé par l'un des certificats racines ou s'il existe une chaîne de certification menant à un certificat racine. Il n'est pas donc nécessaire de connaître à priori le certificat, ce qui limite les attaques par usurpations d'identités (phissing). Création du certificat racine (Root Certificate)Dans notre cas, nous avons utilisé un certificat de base permettant de signer l'ensemble des autres certificats de la maquette. Si l'on avait voulu avoir un service accessible en ligne, il aurait alors été nécessaire et suffisant de signer ce certificat de base par une entité reconnue (certificat racine ou transitivement signée par un certificat racine). L'ensemble des opérations liées aux certificats a été réalisé en utilisant le projet openSSL, gratuit et largement documenté. L'ensemble des opérations ont été effectuées sur la machine mv4, afin de limiter la propagation des clés SSL (et de centraliser leur gestion). La première étape consiste à créer le certificat de base avec la commande CA.pl -newcert : cd /home/ /etc/ssl/misc/CA.pl -newcert iamthecaroot Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:France Locality Name (eg, city) []:Rennes Organization Name (eg, company) [Internet Widgits Pty Ltd]:POLUX Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:POLUX Staff Email Address []:admin@polux.org Après avoir créé le ceritifcat, il faut initialiser (vérifier) la librairie openSSL cd /etc/ssl/ cp /home/newkey.pem private/cakey.pem cp /home/newcert.pem cacert.pem echo > /etc/ssl/index.txt echo 01 > /etc/ssl/serial La troisième étape a pour but d'ajouter le certificat polux dans la liste des certificats reconnus (dossier certs). Cette étape doit être réalisée sur les différentes machines, afin de pouvoir utiliser les chiffrements SSL sur les différents serveurs.<:p> cd /etc/ssl/certs cp Il est à noter que différentes informations peuvent être importante lors de la génération d'un certificat. Premièrement la valeur Country Name est restrictive au sens où tous les certificats fils devront obligatoirement avoir le même cette même valeur. Deuxièmement, le Common Name (CN) permet d'effectuer un contrôle d'identité important. Dans le cas du certificat racine, cela n'est pas important étant donné que le certificat n'a pas pour vocation à être utilisé directement. Cependant, pour les certificats fils, c'est très important, afin d'éviter l'apparition d'alertes SSL, voir le rejet des certificats. Le CN doit en effet correspondre à l'url de connexion. Par exemple, pour apache, il faudra spécifier CN: webmail.polux.org. Certificats utilisés sur la maquetteDans le cadre du projet POLUX, le schéma de certification suivant a été utilisé.
«Design-by-assumption works as long as assumptions hold. Assumptions are
shortcuts to useful efficiencies, provided they are not violated. »
|