Après de nombreux essais non concluants, j’ai fini par suivre à la lettre le document http://www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm.
Environnement de tests :
– système pour le serveur RADIUS : Debian Woody, noyau 2.4.18
– système pour le client (supplicant) : Windows XP Pro Service Pack 1
– borne WiFi (AP) : D-Link DWL 900AP+ et 2000AP
– carte WiFi : PCMCIA Cisco Aironet 350 (configurée par Windows)
La procédure suivie
Tout est parfaitement et clairement expliqué dans le document référencé. Il n’y a qu’à suivre les étapes dans l’ordre et rigoureusement.
Les seules différences que je me suis permises par rapport aux indications du document pointé ci-dessus concernent les versions de logiciel :
– la version 0.9.6c d’Openssl, du 21 décembre 2001 pour le système, au lieu de la 0.9.6g, car il s’agit d’un système utilisé uniquement pour ces tests, et non d’un système où la sécurité est importante,
– la version 0.9.0 de Freeradius, du 21 juillet 2003, au lieu de la version CVS.
En dehors de ça, j’ai téléchargé les versions d’Openssl pointées dans le document de McKay : la version beta 0.9.7-beta3 et la version snapshot-20021028.
La 0.9.7-beta3 est utilisée pour la génération des certificats, car les certificats des versions antérieures ne plaisent pas à Windows, et la version SNAPSHOT (0.9.8) est utilisée pour la compilation du module EAP_TLS de Freeradius.
Puis j’ai suivi scrupuleusement les indications, en faisant des copier/coller des commandes et des scripts et fichiers donnés.
| Serveur | AP (NAS) | Client |
|---|---|---|
| radiusd.conf | 802.1X activé | root.der |
| clients.conf | IP serveur RADIUS | nom_utilisateur.p12 |
| users | port (8012 par défaut) | 802.1X par certificats |
| root.pem | clé dyn. : longueur, fréquence | "clé fournie automatiquement" |
| nom_serveur.pem |
Et tout a fini par bien marcher !
Mode d’emploi des certificats
Le script CA.root sert à générer le certificat de l’Autorité de Certification (CA, l’entité qui délivre les certificats). Il s’agit donc d’un certificat auto-signé, que tout le monde doit pouvoir consulter pour vérifier les certificats générés par cette CA.
Dans notre cas, une copie de ce certificat doit être installée sur le poste de l’utilisateur. Ce certificat est nommé root.der.
Le script CA.srv génère le certificat du serveur RADIUS. Lors de la phase d’authentification, ce certificat sert au client à authentifier le serveur. Il est stocké sur l’ordinateur où tourne le serveur RADIUS.
Le script CA.clt, enfin, sert à générer les certificats pour les utilisateurs : nom_utilisateur.p12. Chaque certificat client généré doit être installé sur l’ordinateur de l’utilisateur, sur son compte. Sous Windows 2000 et XP, un certificat installé sur un compte n’est pas utilisable depuis un autre compte (heureusement !).
Pour les paranoïaques (et si on installe un serveur RADIUS, c’est qu’on l’est un peu :), les certificats root.der et nom_utilisateur.p12 doivent être fournis à l’utilisateur par une méthode sûre : une disquette reste l’idéal. Les faire passer par un réseau expose au risque d’interception, même s’ils sont protégés par un mot de passe... Même le certificat de l’autorité de certification (root.der) est sensible : si il est intercepté, on peut fournir à la place des certificats générés par une fausse autorité de certification.
Attention ! Les méthodes d’authentification par certificat ont une limite importante : elles permettent l’authentification d’un compte utilisateur sur un ordinateur. C’est à dire que,
– d’une part, toute personne qui a accès à votre compte sur l’ordinateur a accès à votre compte authentifié par le serveur RADIUS ;
– d’autre part, si vous utilisez plusieurs comptes sur un ou plusieurs ordinateurs, il faudra installer sur chaque compte les deux certificats, client et root. Si vous utilisez un compte d’"emprunt" temporaire, vous ne pourrez pas accéder aux ressources protégées par Freeradius, sauf si vous installez votre certificat sur ce compte, mais alors tous ceux qui pourront utiliser ce compte pourront se faire authentifier à votre place.
D’ailleurs, en cherchant une possibilité de supprimer les certificats (et n’en trouvant pas), me sont venues des questions : où sont stockés les certificats (apparamment au moins dans c :\Documents and Settings\utilisateur\Application Data\Microsoft\Crypto) ? Sous quelle forme ? Peut-on les supprimer ? Le mot de passe d’un certificat est-il enregistré quelque part ? Peut-on faire confiance à Microsoft et stocker un certificat sous Windows ?
Voilà les joies de la sécurité par l’opacité ! Aucune sécurité n’est possible si on ne sait pas ce qui est fait de nos clés !
A voir ou revoir
La seule imprécision du document concerne le mot de passe des certificats générés : par défaut, il s’agit de "whatever". Il est défini dans les différents scripts CA.root, CA.srv et CA.clt. Pour une utilisation normale, il est préférable de les changer. Les indications données pour le changement de droits mettent ces scripts en accès réservé à root.
Cependant, l’idéal, dans le cadre d’une utilisation rigoureuse, sera peut-être de modifier le script CA.clt pour qu’il demande un mot de passe différent pour chaque certificat généré. Il faut voir si cela peut s’avérer nécessaire ou si c’est une perte d’énergie inutile.
Il faudrait par ailleurs essayer la procédure avec Openssl-0.9.7b, maintenant qu’elle est stable, en l’utilisant à la fois pour le système et pour la génération des certificats (donc à la place de la 0.9.6g et de la 0.9.7-beta3 du document).
Vérifications
Pour vérifier qu’un chiffrement WEP était bien mis en place, j’ai procédé comme suit :
– j’ai configuré mon réseau wiFi (AP et carte) sans clé WEP,
– j’ai configuré ensuite le 802.1X sur l’AP, et sur la configuration de la carte j’ai coché la case "la clé m’est fournie automatiquement",
– j’ai lancé la connexion,
– enfin, j’ai lancé NetStumbler, qui m’a affiché la présence de mon réseau WiFi protégé par clé WEP.
En revanche, je n’ai pas trouvé de moyen pour vérifier que cette clé change bien régulièrement, selon la fréquence choisie sur mon AP.
