Examen de la demi unité de valeur RÉSEAUX ET COMMUNICATIONS CORRIGÉ Seconde partie Seconde session : le 8 septembre 2000 Durée 1 heure 30 DOCUMENTS AUTORISES : TOUS Justifiez toujours brièvement votre réponse. Une réponse non argumentée, même juste ne pourra donner lieu au maximum des points. Notation sur 20. 1
Problème Authentification des usagers et autorisation des requêtes dans le WEB Le World Wide Web a tout d abord été conçu comme un outil de diffusion de documents publics de sorte que peu d efforts ont été effectués au départ pour contrôler l accès aux informations offertes. Comme un domaine de plus en plus large d informations et surtout de services ont été distribués au moyen du WEB, des outils de sécurité ont été proposés pour satisfaire les besoins qui sont apparus. Ce sujet examine des solutions successives qui ont été développées dans le cadre du protocole HTTP pour répondre aux besoins d authentification des usagers et d autorisation des requêtes qu ils émettent. La version 1.0 du protocole HTTP (HTTP/1.0 RFC 1945 mai 1996) propose un mécanisme de base de contrôle d accès utilisant une authentification à mot de passe (mécanisme basic ). Si un utilisateur client requiert une page protégée d un serveur WEB sans fournir de couple usager, mot de passe, il reçoit en réponse un code d erreur 401 ( unauthenticated ). Sur réception de ce diagnostic le navigateur du client demande alors à l utilisateur un nom d usager autorisé et son mot de passe au moyen d un dialogue interactif dans une fenêtre. Lorsqu une réponse est fournie le navigateur client réémet la requête vers le serveur avec les informations usager:mot_de_passe. Lorsque l on émet sur le réseau une requête avec le couple nom d usager et mot de passe, ces informations sont codées mais non cryptées (enregistrement de la requête baptisé Authorization ). La méthode de codage en format texte ascii employée est baptisée Base64. Elle consiste essentiellement à découper les informations par groupes de 6 bits et à représenter les groupes de 6 bits par un caractère ASCII. Par exemple si on souhaite transmettre le couple usager:mot_de_passe "Aladdin:open sesame", il apparaît dans la requête une ligne de la forme : Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== De la sorte, si les mots de passe ne sont pas immédiatement lisibles dans les requêtes ( human readable ), il sont facilement décodables par un programme de décodage et peuvent donc être connus de tout le monde (les mots de passe ne sont pas cryptés). 1) Quels sont les avantages et les inconvénients en termes de sécurité et de coût de mise en œuvre d une telle approche d authentification? (2 points) En fait, la solution est tout à fait comparable à celle des premières authentifications en réseau utilisant des mots de passe en clair comme par exemple l outil d ouverture de sessions à distance telnet. 2
Le principal inconvénient de cette approche est que les mots de passe peuvent être obtenus par une simple écoute du trafic réseau généré par un accès à des pages protégées. Un tel mécanisme est très peu sûr compte tenu de la nature d internet. L avantage est que le mécanisme est extrêmement simple à implanter. On peut aussi remarquer que le fichier des mots de passe peut-être crypté sur le serveur comme l est un fichier de mots de passe d accès à un système interactif comme UNIX. Le serveur WEB autorise une requête en consultant des fichiers créés par l administrateur du serveur. Nous reprenons ici la protection de pages WEB par répertoires telle qu elle est définie dans le cadre de l outil NCSA Mosaic et reprise en version très voisine dans le serveur Apache. Le système d exploitation est le système UNIX. Supposons que l administrateur d un serveur WEB souhaite protéger un répertoire (baptisons le /mydir/turkey) contenant des pages WEB. Il doit créer dans ce répertoire un fichier dont le nom par défaut est.htaccess. Un exemple de fichier.htaccess est le suivant: AuthUserFile /otherdir/.htpasswd AuthGroupFile /dev/null AuthName ByPassword AuthType Basic <Limit GET PUT> require user daniel </Limit> Dans la première ligne de ce fichier on décrit où se trouve le fichier des mots de passe. Il est ici baptisé /otherdir/.htpasswd (c est un fichier qui a pour nom.htpasswd et qui se trouve dans le répertoire otherdir). La seconde ligne indique qu il n existe pas de protection d accès au niveau groupe d utilisateurs, ce qui est indiqué par le fait que le fichier des protections de groupe est un flot vide (/dev/null). La chaîne associée à la troisième ligne (mot clé AuthName) peut être arbitrairement choisie par l administrateur. Elle définit le nom du domaine auquel s applique la politique de protection. Ce nom est transmis par le serveur au navigateur et il est affiché lors des demandes de mots de passe. Il permet à l usager de savoir quel nom d usager et quel mot de passe fournir (en fonction du domaine accédé). Ici le nom du domaine est un nom passe partout Bypassword. La ligne AuthType (type d authentification) définit le protocole d authentification comme étant Basic c est-à-dire celui que nous étudions ici. D autres authentifications sont utilisables (PGP, KerberosV4, KerberosV5, ou Digest que nous examinons plus loin). On voit ensuite que dans ce fichier 3
exemple seules les requêtes GET et PUT sont autorisées (enregistrement Limit GET PUT). On aurait pu définir ici une authentification pour d autres opérations du protocole HTTP. Ici, l autorisation est prévue uniquement pour l usager daniel. Il faut bien sur créer le fichier /otherdir/.htpasswd de mots de passe. Il contient des enregistrements de la forme usager:mot_de_passe. Les serveurs WEB disposent d outils pour créer simplement par des dialogues interactifs ces fichiers de protection. 2) On suppose que l administrateur du serveur WEB doit protèger d autres pages WEB qui ont été créées dans un autre répertoire /mydir/goose. Ces pages appartiennent à un nouveau domaine baptisé realm. L administrateur souhaite protéger l accès à ces pages WEB en autorisant l usager daniel pour les opérations GET, PUT et POST, et l usager laurent uniquement pour les requêtes GET sur ces nouvelles pages. Quels sont les fichiers qui doivent être créés et à quel endroit doivent t il se trouver? (3 points) On applique les règles de construction des fichiers qui ont été données à titre d exemple. Le principal fichier d autorisation d accès.htaccess (nom par défaut) doit être placé dans le répertoire /mydir/goose. Il doit contenir les quatre premiers enregistrements qui définissent le fichier des mots de passe, des protections de groupe, le domaine et le type d authentification. On peut garder le même fichier de mots de passe, toujours pas de protection de groupe. Pour le nom de domaine il faut changer ByPassword pour realm. La méthode d authentification reste basic. Soit les quatre premières lignes : AuthUserFile /otherdir/.htpasswd AuthGroupFile /dev/null AuthName realm AuthType Basic Les enregistrements suivants sont modifiés pour autoriser daniel sur les accès get, put et post et pour autoriser laurent seulement pour get. <Limit GET PUT POST> require user daniel </Limit> <Limit GET > require user laurent </Limit> Le fichier des mots de passe /otherdir/.htpasswd doit maintenant contenir au moins deux enregistrements pour les mots de passe de daniel et de laurent. La structure a titre d exemple est la suivante : daniel:mot_de_passe1 laurent:mot_de_passe2 4
Quand on réalise un service d accès distant en réseau comme telnet ou de transfert de fichiers comme ftp, on commence par une ouverture de connexion ( login process ) pendant laquelle on réalise une authentification de l usager. Cette authentification demeure effective pendant toute une période considérée comme formant un tout du point de vue de la protection. Pendant une telle session un usager peut réaliser un ensemble d opérations puis fermer la session quand bon lui semble. 3) Le protocole HTTP est il conçu selon le principe précédent, c est à dire que l accès à un ensemble de pages, d images d un serveur forme un tout ou bien chaque accès est-il considéré comme indépendant des autres comme c est le cas pour un serveur sans état (le serveur est il avec ou sans état)? (1 point) Le protocole HTTP est prévu pour pouvoir réaliser des serveurs sans état (stateless). Cette option simplifie considérablement la conception des serveurs puisque chaque requête étant auto suffisante, elle peut être traitée à partir de son contenu par le serveur sans qu il ait à faire référence à un état (à une connexion). L inconvénient est qu on ne peut pas considérer une suite d accès comme logiquement reliés (en particulier du point de vue de l authentification). 4) Quelles sont les conséquences du choix précédent relativement au problème d authentification (quelle technique peut-on proposer coté navigateur client pour simplifier la vie de l usager à sa console)? (2 points) Suite à la question précédente on voit que si l on veut faire du contrôle d accès (autoriser l accès à différentes pages basé sur une authentification à mot de passe) il faut que celui-ci soit complètement effectué à chaque requête. Chaque requête comportant le nom d usager et le mot de passe le serveur pourra vérifier si elle est autorisée au moyen des fichiers.htaccess et.htpasswd. Pour ne pas rendre furieux l utilisateur qui accède au même répertoire pendant un certain temps, le navigateur coté client peut mettre en cache des couples usager:mot_de_passe et automatiquement les insérer dans les requêtes. Rappelons que c est le serveur qui est sans état, pas le client. A la version 1.1 du protocole HTTP (HTTP/1.1 RFC 2068 janvier 1997) est associée un autre protocole d authentification baptisé «message digest authentication» défini par la RFC 2069 janvier 1997. Des améliorations ont encore été apportées au protocole de la version digest par la RFC 2617 juin 1999. On définit ici les principes généraux de la solution sans entrer dans les détails. Lorsqu une réponse d un serveur WEB à une requête d un navigateur 5
client est un rejet (code 401 unauthenticated ), la réponse du serveur contient un champ particulier baptisé nonce qui contient une valeur aléatoire à la discrétion du serveur. Ce message de rejet devient alors ce que l on appelle un challenge. Au lieu de répondre par le nom d usager et le mot de passe, le navigateur client doit alors répondre par un nom d usager et à la place du mot de passe la valeur : MD5( concat ( nom d usager, mot de passe, nonce ) ) Dans l expression précédente, concat désigne l opérateur de concaténation. On voit donc que le navigateur ayant obtenu un nom d usager et un mot de passe doit fabriquer un texte qui concatène le nom d usager, le mot de passe et le nonce. Ensuite il lui applique la fonction MD5 qui définit une fonction de hachage à sens unique. Le résultat est la valeur transmise (à la place du mot de passe). La RFC 2069 propose d utiliser par défaut dans le protocole d authentification de type digest la fonction MD5 ( Message Digest version 5). D autres fonctions de hachage à sens unique peuvent être négociées. 5) Rappelez la définition d une fonction de hachage à sens unique. (2 points) C est d abord une fonction de hachage c est à dire une fonction qui génère, à partir d un message de longueur quelconque, un résumé ( digest, hash code ) de longueur fixe (typiquement 128 bits). Elle doit avoir de bonnes propriétés concernant les collisions : si deux messages sont différents ils doivent générer des hachages différents avec une probabilité très élevée. La fonction est à sens unique s il est très difficile (en terme de complexité algorithmique) de repasser du résumé au message source. 6) Comment le serveur WEB réalise la vérification de l autorisation d accès à une page WEB protégée (le navigateur client ayant envoyé une requête avec nom d usager, MD5( concat ( nom d usager, mot de passe, nonce ) ) comme expliqué plus haut)? (2 points) On applique à la réception le même algorithme qu à l émission pour calculer une fonction de hachage MD5 qui porte sur la concaténation du nom d usager, du mot de passe et du nonce. Si les résultats sont identiques c est que le mot de passe était connu du client en raison des bonnes propriétés du MD5. Le serveur doit pouvoir accéder à toutes les informations nécessaires. Le nom d usager vient à nouveau avec la requête, le mot de passe est dans un fichier accessible du serveur, le nonce doit pouvoir être recalculé comme lors du challenge car le serveur est sans état. 6
7) Pourquoi avoir appliqué la fonction MD5 au mot de passe et en même temps au nonce (qu est ce que cela apporte en termes de sécurité)? (2 points) On applique MD5 au mot de passe pour ne pas le faire circuler en clair. En raison des propriétés du MD5 (à sens unique) il est très difficile de repasser du hachage au mot de passe. L utilisation conjointe du nonce qui est a priori une valeur aléatoire dépendante du temps, permet d éviter le rejeu, c est à dire l écoute d un hachage correct et sa réutilisation utltérieure. 8) La méthode de vérification permet-elle de stocker les mots de passe dans le fichier des mots de passe sous une forme cryptée (comme dans les fichiers de mot de passe d accès à un système UNIX) ou bien doit-on avoir sur le serveur le fichier des mots de passe en clair? Quelle est la conséquence relativement à la sécurité de la méthode? (2 points) On est obligé de disposer du mot de passe d un usager en clair sur le serveur car s il est crypté comme dans les fichiers de mots de passe à la UNIX (fonction crypt fonction à sens unique) il est impossible de repasser à la valeur en clair et donc il est impossible de calculer le MD5 sur la concaténation usager, mot de passe en clair, nonce comme à l émission. Un cryptage du fichier des mots de passe en confidentialité avec clé au sens habituel qui permet de revenir du texte crypté au texte en clair serait par contre utilisable (on a alors le problème de protection de la clé de cryptage en confidentialité). Ceci implique que les fichiers de mots de passe sur les serveurs WEB doivent être en clair. C est extrêmement pénalisant du point de vue de la sécurité car la protection d accès aux fichiers est en général assez difficile à assurer dans un système très visité. La méthode d autorisation de type digest est donc en général considérée comme assez faible. Pour aller vers des solutions robustes il faut utiliser des solutions comme SSL ou SHTTP. La valeur du nonce dépend de l implantation du serveur ( implementation dependent ). La norme suggère néanmoins pour assister les implanteurs de serveurs WEB une valeur de nonce qui peut-être recalculée, de manière à ce que la valeur obtenue soit identique (presque toujours) entre un challenge et sa réponse. Nonce = MD5 ( concat (adresse_ip, ":", estampille, ":", clé_privée) ) Adresse_ip est l adresse IP de la machine du client. Estampille est une valeur dépendante du temps qui ne change pas très souvent. Clé_privée est une valeur secrète du serveur. 7
9) Pourquoi choisir une estampille temporelle qui ne change pas très souvent? Quel est le risque encouru par cette méthode? (2 points) Le nonce est une valeur a priori imprévisible (aléatoire) qui évite normalement les attaques de type rejeu. C est pour cela que le nonce incorpore une estampille temporelle. Cependant il est précisé que cette estampille ne change pas souvent. C est donc contraire au souci d éviter des rejeux puisque l on peut imaginer de copier une valeur et de la réutiliser à l identique dans un futur assez proche. Le problème que l on traite ici, c est que le protocole HTTP est sans état. Il faut donc pouvoir calculer un nonce qui ne dépend que d informations qui apparaissent dans une requête (ici l adresse IP et on peut suggérer aussi d introduire l URL de la page accédée) ou qui sont gérées de manière centralisée par le serveur (l estampille temporelle et le secret). De la sorte on peut calculer un nonce lorsqu on lance un challenge, ne pas avoir à le mémoriser et recalculer le même nonce quand on devra vérifier que le client a bien été capable de satisfaire le challenge. Le risque encouru c est que le nonce qui doit protéger contre le rejeu ne le fasse pas bien puisqu il ne change pas assez souvent dans le temps. 10) Pourquoi avoir choisi d introduire dans le nonce l adresse IP du client, une estampille temporelle, un secret (en quoi le choix des valeurs utilisées dans le nonce limite t il le risque encouru)? (2 points) Si l on introduit l adresse IP dans le calcul du nonce on limite les possibilités de rejeu à des messages originaires de la même machine (sauf pour un pirate à pouvoir déguiser son adresse IP en celle de l auteur du message intercepté puis à récupérer les messages suivants, IP spoofing ). On limite encore le risque en mettant l URL de la page puisqu on ne pourra rejouer que l accès à une même page). En mettant une estampille temporelle on limite les possibilités de rejeu à la période pendant laquelle on utilise la même valeur. Le problème est celui du réglage de la durée d utilisation d une estampille temporelle. Enfin la valeur secrète du serveur lui permet de signer ses nonces. Il est impossible de forger un nonce sans connaître ce secret. Comme on passe l ensemble en MD5, il est normalement impossible de forger des nonces corrects. 8