La sécurité en pratique
Les problèmes de sécurité sont suffisamment complexes et sérieux pour que ceux qui s’y connaissent aient raison de dire que ceux qui ne les comprennent pas ne devraient pas s’en occuper : c’est ce que pense l’un de nous (Ben Laurie). L’autre (Peter Laurie) voit plus les choses du point de vue du webmestre ordinaire, qui souhaite simplement protéger ses biens. La sécurité d’un site web n’est qu’un des nombreux problèmes à résoudre.
C’est un peu comme s’il fallait obtenir un doctorat de mécanique avant de pouvoir acheter et conduire une voiture en toute sécurité. L’industrie mécanique était comme cela en 1900 -- elle a évolué depuis.
Dans les éditions précédentes, nous avions prudemment esquivé les questions pratiques et renvoyé le lecteur à d’autres lectures. Nous pensons maintenant que les choses ont suffisamment évolué pour ajouter une section sur ce que les professionnels appellent « recettes de cuisine sur la sécurité ». Cela dit, nous ne vous conseillons pas de lire cette section puis d’aussitôt mettre en ligne un site bancaire ; cependant, si vos problèmes de sécurité se limitent à interdire l’accès aux pirates occasionnels et à vos rivaux commerciaux, elle peut suffire.
La plupart d’entre nous a besoin d’une bonne serrure sur sa porte d’entrée et, au cours des années, nous avons appris comment choisir et mettre en place cette serrure. Malheureusement, ce niveau de compétence ne s’est pas encore développé sur le Web. Dans cette section, nous présentons une bonne serrure ordinaire ; l’installation d’un système de sécurité plus élaboré demandera de plus amples investigations de la part du lecteur.
Recettes de sécurité
Le premier problème de la sécurité consiste à savoir avec qui vous traitez. Les interrogations du client sur l’identité du site (« Est-ce que j’envoie bien mon argent à la véritable MegaBank, ou à une bande de clowns à Bogota ? ») devraient être réglées par un certificat du serveur, comme nous l’avons décrit plus haut.
Vous, en tant que webmestre, voulez aussi être sûr que la personne qui se connecte sous l’identité de l’un de vos chers clients est bien cette personne et non un rusé lascar.
Sans qu’il ne vous en coûte rien, SSL chiffre à la fois vos données et vos mots de passe pour l’authentification de base (voir le chapitre 5) lorsqu’ils traversent le Web. C’est un grand pas vers la sécurité : les sales types qui espionneraient votre trafic seraient un peu découragés. Mais, on se fie encore à un mot de passe pour prouver que ce n’est pas un sale type qui se trouve à la place du client ; les certificats des clients peuvent améliorer cela.
Bien qu’il existe des techniques pour vérifier qu’un individus précis se trouve derrière la console -- lecture des empreintes digitales ou de la rétine, etc. -- aucun de ces dispositifs n’a un prix suffisamment abordable (ou n’est suffisamment fiable) pour être utilisé à grande échelle. De plus, la biométrie a deux gros défauts : ses empreintes ne peuvent être révoquées et elle encourage les sales types à voler des parties de votre corps. Elle n’est pas si fiable que cela non plus : vous pouvez utiliser de la gélatine pour obtenir des empreintes digitales déposées sur les capteurs et les réutiliser ensuite, puis faire disparaître les preuves une fois que vous êtes passé. Les capteurs d’iris peuvent être trompés par un portable affichant une image de l’œil autorisé.
On peut, par contre, s’assurer que la machine du client dispose du certificat client adéquat (de façon logicielle ou, mieux, par un dispositif matériel quelconque) et que la personne au clavier connaît la phrase d’authentification correcte.
Pour montrer comment tout cela fonctionne, nous devons suivre les étapes suivantes.
Certificat client de test
Pour commencer, nous devons obtenir un certificat client (pour pouvoir prétendre être un client vérifié). Votre navigateur aura peut-être un dispositif qui prend en charge cette opération, ou vous pouvez consulter deux sources indépendantes : Thawte ( http://www.thawte.com ) et Verisign ( http://www.verisign.com ). Thawte les appelle « certificats personnels » et Verisign « identifiants numériques personnels ». Comme la version de Verisign coûte environ 15 euros par an et que celle de Thawte est gratuite, nous avons choisi cette dernière.
Le processus est bien expliqué sur le site web de Thawte, nous ne le reproduirons donc pas ici. Cependant, il y a un obstacle caché. La première chose à faire consiste à établir un compte client : on indique son nom, son adresse postale et électronique, etc., ainsi qu’un identifiant numérique quelconque -- numéro de permis de conduire, de passeport, d’assurance, etc. (aucune vérification n’est faite sur ce numéro) ; puis, on choisit un mot de passe.
Jusque là, tout va bien. J’avais oublié qu’il y a un an ou deux j’avais ouvert un compte chez Thawte pour une autre raison : je n’ai rien fait avec, sauf oublier son mot de passe.
De nombreux sites peuvent vous envoyer votre mot de passe par courrier électronique pourvu que vous leur fournissiez un nom et une adresse électronique correcte : ce n’est pas le cas de Thawte. Ils disposent d’une procédure vous permettant de récupérer votre mot de passe mais c’est d’une lourdeur incroyable. Pour m’éviter des efforts, j’ai donc décidé de m’inventer une nouvelle identité électronique, « K. D. Price » avec une adresse électronique sur http://www.hotmail.com afin d’ouvrir un nouveau compte Thawte sous ce nom. Lorsque ce compte est créé, on vous demande d’indiquer votre logiciel parmi ceux de la liste suivante :
Netscape Communicator ou Messenger
Microsoft Internet Explorer, Outlook et Outlook Express
Lotus Notes R5 Navigateur
Opera Mandataire web
C2Net SafePassage
pour télécharger le certificat X509 qui s’installera automatiquement (pour l’anecdote, j’ai demandé un certificat pour Netscape en utilisant MSIE et le site de Thawte s’en est plaint). Le processus peut afficher un certain nombre de fois le message « Cliquez sur OK, sauf si vous savez ce que vous faites » et ceux qui pensent savoir ce qu’ils font y trouveront sûrement matière à sourire. À la fin, le jeu se termine sans expliquer ce qui se passera ensuite, mais vous trouverez dans votre boîte aux lettres l’URL où récupérer le certificat : lorsqu’on se rend à l’adresse indiquée, le certificat s’installe de lui-même. Enfin, on vous indique que vous pouvez voir votre nouvelle acquisition :
To view the certificate in MSIE 4, select View->Internet Options->Content and then press the button for "Personal" certificates. To view the certificate in MSIE 5, select Tools->Internet Options->Content and then press the button for "Certificates".
Obtention du certificat de la CA
Le « certificat client » que nous venons d’acquérir n’a de valeur que s’il a été produit par une autorité responsable et reconnue. Pour prouver que c’est le cas, nous avons besoin d’un certificat de CA établissant que Thawte est l’autorité en question. Comme c’est un point important, vous pourriez penser que cette opération est facile à réaliser mais, pour des raisons incompréhensibles, Thawte et Verisign compliquent véritablement la recherche de leurs certificats de CA. À partir de la page http://www.thawte.com, entrez root trustmapping dans le champ de recherche, puis suivez le premier lien donné en résultat.
Nous avons placé ce fichier dans /usr/www/APACHE3/ca_cert -- bien au-dessus de la racine d’Apache. Puis, nous avons ajouté la ligne suivante au fichier de configuration :
SSLCACertificateFile /usr/www/APACHE3/ca_cert/persfree.crt
Puis, nous avons lancé Apache, qui a bien démarré mais qui a produit la ligne suivante dans error_log :
...
[<date>][error] mod_ssl: Init: (sales.butterthlies.com:443) Unable to configure
verify locations for client authentication
ce qui semble indiquer que quelque chose ne va pas. Le problème est que le certificat de Thawte est au format DER alors qu’il devrait être au format PEM. Le premier est simplement un contenu binaire brut, tandis que le second est encodé en base64 avec un léger enrobage. Pour passer de l’un à l’autre, il suffit de faire :
openssl x509 -in persfree.crt -inform DER -out persfree2.crt
Après avoir modifié le fichier de configuration pour qu’il désigne persfree2.crt, nous avons relancé Apache : cette fois-ci, error_log contenait une ligne indiquant "...mod_ssl/3.0a0 OpenSSL/0.9.6b configured..." -- ce qui est bon signe. Cependant, lorsque nous avons tenté d’accéder à sales.butterthlies.com, cela a échoué et nous avons trouvé la ligne suivante dans error_log :
...[error] mod_ssl: Certificate Verification: Certificate Chain too long
chain has 2 cerificates, but maximum allowed are only 1)
Ce problème se règle facilement en ajoutant une ligne au début du fichier de configuration :
...
SSLVerifyDepth 2
....
Désormais, tout fonctionne et nous avons un site raisonnablement sécurisé. Le fichier de configuration final est :
User webuser
Group webgroup
LogLevel notice
LogFormat "%h %l %t \"%r\" %s %b %a %{user-agent}i %U" sidney
#SSLCacheServerPort 1234
#SSLCacheServerPath /usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLSessionCache dbm:/usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLCertificateFile /usr/src/apache/apache_1.3.19/SSLconf/conf/new1.cert.cert
SSLCertificateKeyFile /usr/src/apache/apache_1.3.19/SSLconf/conf/privkey.pem
SSLCACertificateFile /usr/www/APACHE3/ca_cert/persfree2.crt SSLVerifyDepth 2
SSLVerifyClient require
SSLSessionCacheTimeout 3600
Listen 192.168.123.2:80
Listen 192.168.123.2:443
<VirtualHost 192.168.123.2:80>
SSLEngine off
ServerName www.butterthlies.com
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/customers
ErrorLog /usr/www/APACHE3/site.ssl/apache_2/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_2/logs/butterthlies_log sidney
</VirtualHost>
<VirtualHost 192.168.123.2:443>
SSLEngine on
ServerName sales.butterthlies.com
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/salesmen
ErrorLog /usr/www/APACHE3/site.ssl/apache_2/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_2/logs/butterthlies_log sidney
<Directory /usr/www/APACHE3/site.virtual/htdocs/salesmen>
AuthType Basic
AuthName darkness
AuthUserFile /usr/www/APACHE3/ok_users/sales
AuthGroupFile /usr/www/APACHE3/ok_users/groups
Require group cleaners
</Directory>
</VirtualHost>