Examen de l unité de valeur RÉSEAUX ET COMMUNICATIONS. Seconde partie : couches hautes. Première session : le 15 juin Durée 2 heures CORRIGE

Transcription

1 Examen de l unité de valeur RÉSEAUX ET COMMUNICATIONS Seconde partie : couches hautes Première session : le 15 juin 2002 Durée 2 heures CORRIGE DOCUMENTS AUTORISES : TOUS Justifiez toutes vos réponses Notation sur 20. 1

2 Problème I : Programmation répartie en mode message et en mode RPC objets répartis (10 points) Pour comparer les deux modes de communication on étudie une application de commerce électronique, qui consiste à obtenir d un site serveur distant une cotation pour une valeur boursière. La solution en mode message utilise le niveau transport TCP avec l interface socket et la solution en mode RPC utilise l approche objets répartis Corba. Ce problème ne traite que des comportements d un client. Il n est pas nécessaire de comprendre très en détail les codes présentés en C ou en C++ pour répondre aux questions d ordre général concernant les aspects réseaux des deux solutions. A) Utilisation du niveau transport TCP avec l interface Socket L application considérée est celle d un mode client serveur basique avec un message requête de demande de cotation et un message réponse contenant le cours de bourse. On identifie donc comme premier élément du protocole (message et donnée à échanger dans le message) une requête qui comporte un nom de valeur boursière à coter. C est une chaîne de caractères de longueur variable. La longueur est codée sur un entier long (valeur maximum 100 octets). La réponse comporte la cotation demandée (codée pour simplifier sous la forme d un entier long). Elle comporte aussi un code réponse entier au cas ou des erreurs auraient rendu l opération impossible. Les structures de données échangées dans les messages en langage C sont donc décrites comme suit : #define MAXSTOCKNAMELEN 100 struct Quote_Request { long len; /* Longueur de la requête */ char name[maxstocknamelen]; /* Nom de la valeur à coter */ }; struct Quote_Response { long value; /* Cours de la valeur */ long errno; /* 0 si succès, code d erreur sinon */ }; On rassemble, dans une procédure utilisée par le client (connect_quote_server), les instructions nécessaires pour la mise en connexion du client avec le serveur, selon les primitives de l interface socket. - En entrée de la procédure, server est une chaîne de caractères qui définit le nom du service de cotation. - En entrée de la procédure, port contient le numéro de port du service de cotation. - En résultat HANDLE est un entier qui contient la référence du descriptif de la socket. 2

3 typedef int HANDLE; HANDLE connect_quote_server (const char server[], u_short port) { struct sockaddr_in addr; struct hostent *hp; HANDLE sd; /* Création de la terminaison locale */ sd = socket (AF_INET, SOCK_STREAM, 0); /* Détermination adresse du serveur */ hp = gethostbyname(server); /* Remise à zéro de la zone adresse et initialisation adresse du serveur */ memset ((void *) &addr, 0, sizeof addr); addr.sin_family = AF_INET; addr.sin_port = htons (port); memcpy (&addr.sin_addr, hp->h_addr, hp->h_length); /* Ouverture de la connexion avec le serveur */ connect (sd,(struct sockaddr *)&addr, sizeof addr); return sd; } I.1) A quoi sert la primitive socket? Pourquoi utiliser le paramètre AF-INET? Pourquoi utiliser le paramètre SOCK-STREAM? (1,5 points) s La primitive socket sert à créer une socket. Plus précisément on créé la structure de données qui va contenir le descriptif. L espace mémoire est réservé et les cases correspondant aux valeurs passées en paramètre sont initialisées. On réserve l espace de travail nécessaire aux files d attentes des octets en émission et en réception. On récupère une référence sur le descriptif de la socket créée sous forme d un entier. AF_INET indique que l on utilise comme famille d adresses (adress family) les adresses internet. Le paramètre veut donc simplement dire que l on va communiquer en utilisant l Internet. On trouve aussi quelquefois la déclaration PF_INET (pour Protocol Family) famille des protocoles Internet. Pour tous les systèmes normaux les deux valeurs sont identiques et égales à 2. Certains systèmes font une différence. Le mode sock_stream définit une communication par flot d'octets en mode connecté qui ne préserve pas les limites d'enregistrement entre deux messages successifs. C est le mode adapté à la communication en TCP. On sélectionne donc ce mode pour faire du TCP. 3

4 I.2) A quoi sert la primitive gethostbyname. Quel est le nom de l application Internet qui est utilisée par la primitive gesthostbyname. Quel doit donc être le format d un nom de service? (1,5 points) s Si on ne connaît pas déjà la réponse on voit que la primitive gethostbyname sert à obtenir un résultat noté hp et qu une partie de hp de type hostent sert plus loin à initialiser l adresse h_addr (host addr). gethostbyname comme son nom l indique, est un résolveur d adresse. On lui présente un nom symbolique (ou logique) c est à dire une chaîne de caractères et on obtient une adresse ip. Le nom de l application Internet qui convertit les noms symboliques (sous forme de chaînes de caractères) en adresses IP est le DNS (Domain Name System). L accès à un service distant, nécessite en Internet, la connaissance du nom de la machine distante à laquelle on accède et du port utilisé pour communiquer avec le processus fournisseur du service. Dans la terminologie DNS un nom de domaine permet de définir un nom de service et ou un nom d hôte. ftp.cnam.fr ou sont des noms de service qui sont en fait converties en des noms de machines. La procédure gethostbyname qui fournit une adresse IP doit donc recevoir en paramètre un nom de domaine dns. Il peut s agir d un nom complet d un hôte Internet (un FQDN Fully Qualified Domain Name comme ulysse.cnam.fr..) ou d un nom relatif (comme ulysse) qui sera complété par une chaîne définie au niveau du serveur DNS. En général c est le nom du domaine courant, le domaine dans lequel la requête à été émise qui est pris (dans l exemple on utilise donc ulysse complété par.cnam.fr..). Il faut compléter une adresse ip par un numéro de port. Dans le cas des services ayant des ports bien connus comme www ou ftp le numéro de port est déductible directement. On parle aussi de nom de service dans le cas des numéros de ports fournis sous forme symbolique. Il faut alors effectuer une recherche dans un fichier des noms de services (/etc/services) pour obtenir la valeur numérique (getservbyname). Dans l exemple traité ici, il n y a pas de définition symbolique du numéro de port. Le numéro de port doit être fourni directement en numérique. Il est directement installé dans la structure addr par l instruction addr.sin_port = htons (port); ) (voir plus loin le problème de conversion résolu au passage). Quelques approfondissements : Le résultat de gethostbyname est en fait une structure complexe dont le type est hostent. Ce type est défini par ailleurs et installé par des include par tous les utilisateurs de la procédure gethostbyname. La structure hostent retourne possiblement un tableau d adresses IP h_addr_list, typées h_addr_type au cas ou le dns serait utilisé pour des adresses autres que l internet). Elle retourne aussi le nom correct dns qui aurait du être soumis hname, et les alias de ce nom haliases. struct hostent { char *h_name; char **h_aliases; int h_addrtype; int h_length; char **h_addr_list; }; 4

5 #define h_addr h_addr_list[0] Les requêtes inverses sont réalisées au moyen de gethostbyaddr résolution d un nom logique en présentant une adresse IP. I.3) Quel est le rôle de la primitive connect? (0,5 point) La primitive connect sert dans le mode connecté c est à dire en TCP à connecter le client au serveur. Plus précisément, sur la primitive connect, le TCP client va réaliser avec le TCP serveur, le protocole de connexion en trois étapes ( three way handsahke ), le client étant l initiateur de l ouverture de la connexion, il jouera le rôle d ouvreur actif. Une seconde procédure utilisée par le client send_request rassemble toutes les instructions nécessaires pour la transmission de la requête. - En paramètre entrée de la procédure, sd est le descriptif de la socket. - En paramètre entrée stock_name contient le nom de la valeur boursière à coter. - Il n y a pas de résultat (void). void send_request (HANDLE sd,const char stock_name[]) { struct Quote_Request req; size_t w_bytes; size_t packet_len; int n; /* Détermination longueur du nom de valeur boursière et */ /* recopie du nom de valeur boursière dans la requête */ packet_len = strlen (stock_name); if (packet_len > MAXSTOCKNAMELEN) packet_len = MAXSTOCKNAMELEN; strncpy (req.name, stock_name, packet_len); /* Calcul longueur totale de la requête et conversion vers l ordre des octets réseau */ packet_len = packet_len + sizeof req.len; req.len = htonl (packet_len); /* Envoyer le message au serveur */ n = send (sd, ((const char *) &req),packet_len, 0); } I.4) Dans la procédure précédente send_request la primitive htonl est appliquée à la longueur du paquet packet_len pour fabriquer la zone req.len (longueur de la requête). Htonl (littéralement host to network long integer ) convertit l ordre des octets de la machine client dans l ordre réseau. Pourquoi effectuer une telle conversion. Sous quel nom est connu le problème résolu par htonl? (1 point) 5

6 Selon le texte la primitive htonl sert à régler le problème de l ordre des octets en adaptant l ordre local au client en un ordre réseau. C est donc le problème de la différence entre les machines petit boutiste et grand boutiste (little endian big endian) qui est traité au moyen de cette procédure. La procédure htonl installée dans les librairies du système client connaît le mode adopté par ce système. Elle connaît également le choix du réseau Internet (grand boutiste). Elle effectue si nécessaire la conversion. On a déjà vu aussi dans le code la primitive de conversion d entiers courts htons à propos du numéro de port. On rassemble dans la procédure client recv_response la collecte d un message de réponse à une requête de cotation. La structure de donnée d un message de réponse Quote_Response a été définie plus haut. int recv_response (HANDLE sd, long *value) { struct Quote_Response res; recv (sd, (char*) &res, sizeof res, 0); errno = ntohl (res.errno); if (errno > 0) /* Erreur */ return -1; else { /* Succès */ *value = ntohl (res.value); return 0; } } I.5) A quoi servent les primitives ntohl utilisées dans le code recv_response? (0,5 point) On a vu l usage de la primitive htonl à la question précédente. La primitive htonl sert à régler le problème de conversion inverse (réception des données en provenance du réseau). C est donc une conversion des octets dans l ordre réseau vers l ordre local au client. I.6) On souhaite évaluer la solution proposée de programmation client-serveur en mode message avec les sockets relativement à l assemblage des données dans les messages. Quel est le point de vue adopté relativement aux conversions dans ce programme (quel est le niveau d interopérabilité de la solution)? (1 point) On voit dans le code d émission de la requête que, immédiatement après l opération htonl l émission a lieu. Il n y a donc pas d autres précautions que de veiller à ce que l ordre des octets soit respecté. De même dans la réception on ne se préoccupe que de l ordre des octets. Or on achemine des entiers et une chaîne de caractères. On suppose donc que les codages des entiers longs sont exactement les mêmes sur les deux machines client et serveur. Ils doivent donc occuper le même nombre de bits (32 bits) et utiliser la même approche du codage des valeurs négatives (complément à 2). On suppose aussi que les 6

7 codes caractères utilisés sont les mêmes pour les deux machines (par exemple l US- ASCII). C est possible si le langage du code client et du code serveur sont suffisamment compatibles (du C standard, des plates-formes homogènes). A la moindre variation (par exemple codage d un client dans un autre langage que celui du serveur, ou dans un compilateur ne fabriquant les structures de données (types articles) de la même façon, etc.) les programmes n interopéreront plus. Il faudra prévoir des conversions explicites vers un langage pivot (comme BER), c est à dire appeler une bibliothèque de conversion de toute donnée émise ou reçue. Cette tâche devra être assurée manuellement complètement par le programme émetteur. La solution la plus souple consiste à disposer d une automatisation du codage des messages et de leur décodage ( marshaling et unmarshaling ) comme en CORBA. B) Utilisation de l approche objets répartis avec Corba On se propose d étudier la solution au problème de cotation précédent en utilisant l approche objet réparti CORBA. I.7) Rappelez les principes généraux de l approche CORBA? Comment est réalisée l invocation à distance en CORBA? (1 point) Corba définit une approche de communication orientée objets répartis Normalement Corba fait communiquer des programmes en langage objet, mais Corba peut également permettre de communiquer entre des programmes non objet (comme C ou Cobol). L invocation à distance s effectue donc entre un objet client et un objet servant en appel de procédure distante (en appel de méthode dans le langage des objets). Pour invoquer une méthode d un objet distant, un objet client a besoin de posséder une référence sur l objet servant. La notion d IOR, Interoperable Object Reference définit une structure de données comportant différentes informations comme l adresse réseau de l objet distant, le protocole utilisé, le nom de la méthode à activer etc pour supporter l adressage en invocation distante. L ORB Corba (Object Request Broker) est responsable de l automatisation des tâches de communication en RPC. Ces tâches comprennent la localisation de l objet distant, son lancement si nécessaire, l acheminement de la requête et le retour de la réponse, (l alignement des paramètres dans la requête et dans la réponse c est à dire le marshalling) en effectuant les conversions nécessaires. Tout ceci permet une réalisation des invocations de façon simplifiée et correcte entre des objets dans des langages objets différents, résidants sur des plates-formes différentes. Le code IDL suivant décrit l accès au serveur de cotation : module Stock { exception Invalid_Stock {}; interface Quoter { long get_quote (in string stock_name) raises (Invalid_Stock); }; 7

8 }; I.8) A quoi sert la déclaration interface Quoter. A quoi sert la déclaration long get_quote (in string stock_name) (à quoi correspond elle dans le programme socket)? A quoi sert l exception exception Invalid_Stock {}; (qu est ce qu elle remplace dans le programme socket)? (1 point) Un programme IDL peut réunir plusieurs interfaces dans un module et comprendre plusieurs modules. Le mot clé interface délimite donc la description d une interface particulière, ici l interface du service de cotation qui a été baptisée quoter. La déclaration long get_quote (in string stock_name)définit en IDL la signature de l opération de demande de cotation. On voit qu elle définit un paramètre d appel de type chaîne qui est le nom de la valeur boursière à coter. En résultat on obtient le cours sous la forme d un entier long. Cette déclaration remplace essentiellement dans le programme de communication socket, les déclarations de structures de données échangées dans les messages requête et réponse : struct Quote_Request { long len; /* Longueur de la requête */ char name[maxstocknamelen]; /* Nom de la valeur */ }; struct Quote_Response { long value; /* Cours de la valeur */ long errno; /* 0 si succès, sinon code d erreur */ }; La déclaration exception Invalid_Stock définit une exception c est à dire un traitement à réaliser en cas d erreur. Ici l exception est baptisée invalid_stock soit encore valeur boursière invalide. On voit qu elle est levée par l appel à la méthode de cotation get_quote. Elle remplace le code d erreur entier errno retourné comme un paramètre out dans le message réponse de la programmation socket. Un programme client CORBA pour l invocation du service de cotation est le suivant: int main (int argc, char *argv[]) { // Nom du service de cotation invoqué. const char *name = "Quoter"; Name service_name; service_name.length(1); service_name[0].id = name; // Obtention objet obj invoqué localement (tous les traitements // nécessaires sont résumés par une procédure bind_service) Object_var obj = bind_service (argc, argv, service_name); int result = 1; try { 8

9 // Obtention d une référence q sur obj (avec vérification de type) Quoter_var q = Quoter::_narrow (obj); // Invocation sur obj du service de cotation distante pour la valeur IBM const char *stock_name = "IBM"; long value = q->get_quote (stock_name); // Edition du résultat et traitement des erreurs cout << "value of " << stock_name <<"=$" << value << endl; result = 0; // Success! } // Exception BAD PARAM si erreur de type d interface catch (CORBA::BAD_PARAM) { cerr << "_narrow() failed: " << service_name << " is not a Quoter!"; } catch (Invalid_Stock &) { cerr << stock_name << " is not a valid stock name!\n"; } return result; } I.9) La requête Object_var obj = bind_service (argc, argv, service_name); permet la création d un objet local au client obj sur lequel est réalisé l invocation distante. Que est le rôle de obj (quel traitement réalise l objet obj), quel est le point de vue adopté relativement aux conversions dans ce programme (quel est le niveau d interopérabilité de la solution)? (2 points) L objet obj, est selon le texte un objet local sur lequel est réalisée l invocation distante. Cet objet joue donc exactement le rôle de souche client. Dans un RPC la souche est invoquée en mode local et permet de réaliser les appels distant. L objet obj a donc une interface qui correspond à l interface du service quoter, défini par son IDL (stocké dans le référentiel d interfaces). Cet interface comporte principalement une méthode get_quote (stock_name);. La compilation de l IDL génère l ensemble de traitements suivants. a) Localisation du service invoqué. Pour cela on utilise le service de localisation de CORBA le Name service qui détermine la référence réseau du service quoter. Les problèmes d adressage réseaux sont résolus. b) Création des messages de requêtes (conversion des paramètres du format local vers le format réseau, marshalling des paramètres d appel et nom de la requête), envoi de la requête, attente de la réponse, conversion des paramètres résultats et fourniture du résultat comme s il s agissait d un résultat local. 9

10 Le problème de conversion est donc, moyennant la définition de l interface en IDL complètement et automatiquement résolu par la création de la souche et l utilisation du format de syntaxe de transfert de CORBA CDR. Le programme d accès au service de cotation en Corba, porté sur n importe quelle plate-forme reste interopérable vis à vis du serveur de cotation. 10

11 Problème II : Sécurisation des communications en Internet avec SSL-TLS (10 points) SSL ( Secure Sockets Layer ), est une norme de réseau qui permet de sécuriser les communications pour des applications Internet utilisant TCP/IP. SSL offre un service de communication analogue à celui des sockets mais SSL ajoute aux communications standards des fonctions de sécurité (authentification du client par le serveur, du serveur par le client, intégrité, confidentialité des données échangées) et éventuellement aussi des fonctions de compression. Développé par Netscape jusqu à la version 3.0 (novembre 1996), l IETF a alors adopté SSL et a présenté sa version baptisée TLS ( Transport Layer Security RFC 2246 en 1998) compatible avec SSL 3.0. Par rapport à SSL, TLS offre quelques extensions mineures comme une amélioration des signatures, différents traitements d erreurs supplémentaires,... En ce sens TLS 1.0 est parfois désigné comme SSL 3.1. SSL/TLS est découpé en deux grandes parties. La partie Handshake assure les fonctions initiales d un échange sécurisé. La partie Record assure les fonctions de sécurité sur les données utilisateur en appliquant des approches de cryptographie et de signatures définies pendant la phase de Handshake. Ce problème étudie plus particulièrement la partie Handshake. La partie Handshake de SSL/TLS permet d établir le contexte de sécurisation utilisé ensuite dans la phase d échange de données. La partie Handshake permet l authentification des entités communicantes. Elle permet également l échange de clés de session. Un contexte de sécurisation comporte : - Un identifiant de session sécurisée choisi par le serveur. - Un certificat d entité distante (optionnel). - Une méthode de compression (si la compression est appliquée). - La suite cryptographique utilisée (voir plus loin). - Une clé secrète ( master secret 48 octets partagés entre client et serveur). - Une variable indiquant si la session peut couvrir plusieurs connexions TCP. Les opérations principales du protocole Handshake sont : 1. Négocier la suite cryptographique utilisée pendant le transfert des données. 2. Etablir une clé de session partagée entre le client et le serveur 3. Authentifier le serveur par le client (optionnel). 4. Authentifier le client par le serveur (optionnel). En SSL/TLS une suite cryptographique est un choix relatif aux éléments suivants : - La méthode d échange de clés. - La méthode de chiffrement utilisée pendant le transfert des données. - La méthode de hachage utilisée pour la création d une signature. La méthode d échange de clés peut se faire de deux façons. L une utilise les algorithmes à clé publique et la notion de certificat. Une autre méthode est prévue en l absence de certificats : la méthode de Diffie-Hellman. 11

12 Le chiffrement est réalisé au moyen d un algorithme à clé secrète. Neuf algorithmes à clé secrètes avec des variantes sur les longueurs de clés sont possibles (DES, Triple- DES, IDEA, etc ) La fonction de hachage à sens unique (Digest Function) peut également être sélectionnée (MD5, SHA-1) En combinant les différentes choix possibles dans les trois domaines précédents, la norme définit 31 suites de chiffrement cohérentes qui peuvent être adoptées après négociation. II.1) Du point de vue du modèle OSI on considère que SSL-TLS est de niveau session alors que l interface socket standard n est pas de niveau session. Pourquoi? (1 point) Correction D après le texte de présentation, SSL réalise en phase de handshake des échanges de messages pour ses besoins propres, pour négocier le contexte de sécurisation (les suites cryptographiques utilisées, les méthodes de compression, échanger des certificats). Le texte indique aussi qu il y a possibilité d authentification réciproque et échange de données sécurisées. Pour tout ces échanges, SSL utilise les services de la couche transport sous-jacente TCP. En ce sens, une entité SSL réalise un véritable protocole de communication qui agit par échange de messages avec une entité SSL distante. SSL constitue donc une véritable couche au sens du modèle OSI avec une définition de service (les communications socket sécurisées) et une définition de protocole (les échanges de messages de négociation, les échanges d authentification, les échanges de messages de données sécurisées). On doit donc effectivement considérer SSL comme un niveau à part entière dans le modèle OSI. Le niveau session étant immédiatement situé au dessus du niveau transport est assez naturellement le niveau retenu. Cependant on peut remarquer que la session dans le modèle OSI est dédiée aux fonctions de synchronisation alors que le niveau présentation est dédié aux fonctions de conversion. SSL effectuant pour une grande part des traitement concernant les données (chiffrement en confidentialité, signature) correspond pratiquement plus dans l esprit du modèle OSI au niveau présentation. Il aurait été aussi possible de considérer SSL comme de niveau présentation. Rappelons qu au contraire, l interface socket standard n est qu une API d accès à TCP ou à UDP. Les sockets ne sont associées à aucun protocole spécifique mais ne font que donner accès au niveau transport (en Internet TCP ou UDP). Comme il n existe aucun échange spécifique de messages de socket à socket, l interface socket ne peut constituer une couche au sens du modèle OSI. II.2) La plupart des utilisations de SSL/TLS comporte l authentification du serveur par le client (bien que les fonctions d authentification soient optionnelles). Citez une application de cette authentification. De manière générale pourquoi est il important d authentifier un serveur? (1 point) Correction Une application de l authentification du serveur intervient à chaque fois qu un client veut s assurer qu il s adresse à un serveur qui est bien celui qu il prétend être. Il 12

13 ne doit pas s agir d un programme douteux qui peut faire un mauvais usage des informations qui lui sont confiées. En ce sens SSL est utilisé dans le commerce électronique pour transmettre les numéros de carte bleue à des serveurs authentifiés (dans des conditions de sécurité du point de vue des clients qui ne veulent pas communiquer leur numéro à n importe qui). De manière générale, l authentification du serveur est un élément avec d autres qui permet d éviter les attaques dites du milieu ( man in the middle, active wiretapping ). Dans ces attaques un programme intrus se place entre le client et le serveur en se faisant passer pour le serveur de façon à en tirer un avantage (recopier des numéros de carte bleue). II.3) Pour un serveur, il est également possible avec SSL-TLS d authentifier le client. Citez une application de cette authentification. De manière générale quelle est l utilisation de cette authentification. (1 point) Correction Par exemple dans le domaine du commerce électronique on peut vouloir protéger un serveur comme une galerie marchande contre une utilisation abusive de celui-ci par un client qui usurperait l identité de quelqu un d autre. Une autre catégorie d applications concerne la communication d informations confidentielles détenues par une entreprise au sujet d un individu : cette communication ne peut être réalisée à n importe qui et l on doit s assurer que la personne à qui l on communique des informations est bien celle qui est concernée par ces informations (loi informatique et libertés droit d accès à l information et protection de la vie privée). Exemple des informations financières connues par une banque concernant l un de ses clients. Exemple des informations médicales détenues par un hôpital concernant un patient. Le même argument que celui de la question précédente concernant la parade des attaques par le milieu est bien sur valable et justifie de manière générale l authentification du client. II.4) Le protocole SSL/TLS propose, dans l une de ses modalités, d utiliser la notion de certificat. Cette approche est d ailleurs de loin la plus souvent retenue. A quoi sert un certificat. Rappelez les principaux champs d un certificat? (1 point) Un certificat est une structure de données dont la principale raison d être est de servir de support à l échange des clés publiques. Cependant un certificat doit présenter une qualité essentielle qui est son intégrité. Il ne doit pas pouvoir être forgé par n importe qui. Un intrus pourrait générer un couple clé publique, clé privée et transmettre la clé publique forgée à la place de la clé publique réelle d un usager. Un certificat comportant une clé publique doit donc impérativement être signé par une autorité de certification reconnue. Les principaux champs d un certificat sont alors : 13

14 - L identifiant du porteur de la clé publique (ici pour une authentification du serveur ce serait l identifiant du serveur). - La clé publique (ici la clé publique du serveur) - La période de validité de cette clé publique - L identifiant de l émetteur du certificat (l autorité de certification reconnue) - La signature du certificat par l autorité de certification. - Un numéro de série du certificat qui sert d identifiant unique à ce certificat. II.5) La vérification d un certificat comporte différentes étapes. Quels sont les traitements à réaliser pour vérifier un certificat? (2 points) La vérification d un certificat peut commencer par la vérification de la date. Est ce que la date courante se trouve dans la période de validité du certificat. On doit ensuite s assurer que l émetteur du certificat appartient à une liste d autorité de certification de confiance. L émetteur du certificat est connu par son identifiant contenu dans le certificat. Une liste d autorités de certification de confiance doit être disponible sur la machine qui vérifie le certificat. On doit alors vérifier que le certificat est bien signé par l émetteur du certificat. On rappelle que la signature numérique utilise une fonction de hachage appliquée au certificat, le résultat du hachage ( digest ) est chiffré au moyen de la clé secrète de l'émetteur. Pour vérifier un certificat en intégrité on doit donc posséder le certificat de l émetteur du certificat (puisqu on a besoin de sa clé publique). Ce qui permet donc de valider la signature en la déchiffrant avec la clé publique de l émetteur et en vérifiant que l on retrouve bien le hachage du certificat. Deux propriétés sont vérifiées d un coup : le certificat n a pas été modifié depuis son émission (intégrité), et l émetteur du certificat dont le nom figure dans le certificat est bien celui qui a signé le certificat. Comme le certificat de l émetteur peut lui même être falsifié, une bonne validation se doit de remonter la chaîne des signatures de certificats selon une longueur prédéfinie jusqu à atteindre un niveau de confiance satisfaisant. Une quatrième vérification ne fait pas partie de l ensemble des vérifications SSL mais elle est suggérée pour prévenir des attaques par le milieu. Elle consiste à utiliser le nom de domaine de résidence du porteur du certificat (par exemple ici le serveur). Si ce nom de domaine se trouve dans le certificat (par exemple dans la partie identification du porteur) on peut le comparer avec le nom de domaine réellement utilisé pour les communications qui sont en cours. On peut alors rejeter des échanges avec un serveur si les deux noms de domaines ne correspondent pas. Une telle vérification est un peu contraignante car elle empêche un prestataire de service de déléguer son activité à un autre prestataire qui serait hors de son domaine. II.6) Rappelez les principes d une authentification en utilisant un algorithme à clés publiques? (1 point) 14

15 Le fait de détenir un certificat valide n assure en rien qu un site distant présentant ce certificat est vraiment celui qu il prétend être puisque n importe quel certificat est par essence une donnée publique que tout le monde peut détenir. Pour authentifier une entité distante, il faut que celle-ci soit capable de chiffrer ou de déchiffrer une information en utilisant la clé privée qu elle est la seule à détenir. Il ne faut pas qu un rejeu soit possible d ou les protocoles habituels d authentification à clés publiques qui utilisent des nonces. Par exemple le demandeur d une authentification présente un nonce (valeur aléatoire) pour éviter le rejeu. Le site devant s authentifier le chiffre avec sa clé privée. Il est le seul a pouvoir le faire. Le demandeur vérifie le chiffrement en utilisant une clé publique de confiance (obtenue par un certificat valide). Les échanges du protocole Handshake sont assez complexes. En particulier ce protocole dépend des techniques de sécurisation utilisées (définies par le contexte de sécurisation négocié). On présente les principaux éléments du fonctionnement du protocole Handshake en omettant beaucoup de détails pour simplifier. L échange suivant est utilisé en cas d authentification dans les deux sens au moyen de certificats. Ce protocole négocie le contexte de sécurisation, échange les certificats et les valide, construit un secret partagé sur 48 octets ( master secret ) qui permet de fabriquer des clés de session et il échange des messages de terminaison. Client Serveur ClientHello(protocolVersion, random, sessionid,ciphersuite, compressmethod) ServerHello(protocolVersion, random, sessionid,ciphersuite, compressmethod) Certificate () CertificateRequest () Certificate () ClientKeyExchange () Finished() Explications des échanges Finished() 1) La première phase (messages ClientHello, ServerHello) correspond à la négociation du contexte de sécurisation. Le client envoie différentes informations proposant un contexte de sécurisation (premier message avec version du protocole SSL, un nombre aléatoire, un nonce, une suite cryptographique, une méthode de compression). Le serveur choisit les valeurs définitives du contexte de sécurisation acceptable en fonction de la proposition client (second message). Il fournit également un nombre aléatoire. 15

16 2) Dans le cas d une authentification du serveur, le serveur fournit son certificat (message Certificate). Il demande le certificat du client s il y a aussi authentification du client (message CertificateRequest). 3) Le client valide le certificat du serveur. 4) Le client envoie son certificat au serveur. Il créée un secret au moyen d un générateur de nombres aléatoires ( pre master secret ). Le client l envoie au serveur encrypté avec la clé publique du serveur (message ClientKeyExchange). Le client génère le secret partagé (master secret) à partir du pre master secret et des deux nombres aléatoires échangés dans les deux premiers messages. 5) Le serveur valide le certificat client. Il décrypte le secret (pre master secret) envoyé par le client au moyen de sa clé privée. Il génère selon le même algorithme que le client le même secret partagé (master secret). 6) En utilisant le secret maintenant partagé (master secret), le client et le serveur génèrent chacun de leur coté la même clé secrète de session utilisable pour des algorithmes à clés privées (comme le DES). 7) Le client et le serveur échangent des messages de terminaison (Finished) chiffrés au moyen de la clé secrète de session. Ces messages indiquent que le protocole de Handshake est terminé et que les échanges auront lieu à partir de maintenant en utilisant le contexte de sécurité négocié. Ces messages doivent être déchiffrés et vérifiés. II.7) Quels sont les mécanismes du protocole Handshake qui assurent l authentification du serveur vis à vis du client? (2 points) Dans ce protocole il y a des nonces échangés au début (les deux nombres aléatoires échangés dans clienthello et serverhello) mais ils ne sont pas utilisés classiquement pour faire de l authentification. Il aurait fallu faire chiffrer le nombre aléatoire client avec la clé secrète du serveur mais ce n est pas le cas. En étudiant plus à fond les mécanismes décrits on voit qu un client transmet une information chiffrée avec la clé publique du serveur au moment de l envoi du secret pre master secret dans le message ClientKeyExchange. Le texte indique clairement que ce secret est un nombre aléatoire. En fait ce secret n a pas circulé en clair comme un nonce mais il va prendre le même statut qu un nonce. Remarquons tout d abord que ce secret est généré par le client, il est aléatoire, il est donc imprévisible et non rejouable. Le serveur le reçoit et lui seul peut l interpréter en le déchiffrant avec sa clé privée mais la preuve de l authentification du serveur n est apportée que plus tard. En effet le pre master secret permet de fabriquer pour les deux communicants le master secret en tenant compte des deux nonces échangés dans les deux premiers messages. La formule exacte de calcul utilise une fonction PRF (pseudo random fonction) qui est analogue à une fonction de hachage à sens unique: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; 16

17 Le texte indique que le master secret permet a son tour aux deux communicants de générer une clé de session (en fait on génère plusieurs clés si nécessaire a partir de ce nombre considéré comme une racine pour la génération de clés). La clé de session permet à la fin d échanger un premier message chiffré en cryptographie à clé secrète. La norme comme le texte soulignent bien que cet échange doit être vérifié. En effet seuls le client et le serveur qui ont suivis en parallèle le même chemin leur permettant d aboutir à la même clé peuvent communiquer de façon correcte et échanger le message finished. C est en fait à cet instant que l authentification est réalisée. Seul le serveur, qui possède la clé privée permettant de décoder le pre master secret a pu générer la clé de session et peu envoyer un message finished correctement chiffré. Une attaque du milieu ne peut réussir car si un attaquant remplace le serveur vis à vis du client, il ne peut dialoguer avec le client car il ne peut jamais connaître le pre master secret. II.8) Le protocole SSL utilise une combinaison de méthodes de cryptographie qui comprend des algorithmes à clés publiques et des algorithmes à clés privées. Pourquoi utiliser concurremment les deux techniques? (1 point) Les méthodes de cryptographie à chiffre symétrique sont beaucoup plus rapides que les méthodes à clés publiques, donc pour ne pas ralentir les communications réseaux en confidentialité il est de très loin préférable d utiliser des chiffres symétriques (a clés privées). Par contre les chiffres à clés publiques offrent des méthodes d authentification et d échange de clés très sures. Comme il s agit d échanges brefs la pénalisation due au manque de performances est largement contrebalancée par les avantages offerts dans la construction des solutions. 17

18 Questions supplémentaires Socket I.6) Détermination des adresses. Quelles sont les adresses à déterminer. Quel est le niveau de souplesse de la solution proposée. Pourrait t on avoir une solution plus pratique? (1 point) Pour effectuer une communication en mode message on doit déterminer deux niveaux d adresses. L adresse de réseau IP est indispensable pour connaître le site de résidence du serveur. Le numéro de port permet de préciser le point d accès au service de cotation (le processus serveur de la cotation). Du point de vue des adresses de réseaux (adresses d hôtes) la solution retenue qui utilise le DNS est assez souple puisque le nom du service peut être fourni sous une forme symbolique (nom de domaine DNS). Le service d annuaire réparti permet d établir la correspondance entre le nom symbolique et l adresse physique (l adresse IP). Si l on veut changer la machine ou réside le service de cotation il suffit de changer l enregistrement ressource (resource record) définissant le nom du service. Du point de vue des numéros de port la solution est très rigide car le numéro de port est à fournir sous la forme d un entier c est à dire sans utiliser un nom symbolique de service. Il n est pas possible de changer le numéro de port du service sur le serveur sans recompiler le client. Une solution plus souple consiste à utiliser un nom de service et à établir la correspondance avec le numéro de port au moyen d un appel à une procédure de correspondance gestservbyname. Cependant chaque site client. Un schéma de détermination des adresses vraiment flexible devrait utiliser une service d annuaire réparti complet. Celui-ci permettrait d une part à un nouveau service de s enregistrer en mettant en correspondance un nom symbolique du service et le couple adresse IP, numéro de port sur lequel ce service est rendu actuellement. D autre part, tous les clients potentiels pourraient alors effectuer une interrogation de l annuaire réparti (quelle que soit leur localisation dans l Internet) pour connaître le couple adresse IP, numéro de port de ce service (effectuer une liaison dynamique). I.8) Transmission et réception des données dans les messages. Quel est le niveau de souplesse de la solution? 18

19 Le programme doit émettre la requête et recevoir la réponse en s adaptant aux spécificités de l interface socket et en traitant tous les cas possibles d erreurs. Par exemple il doit transférer des messages orientés structures de données fixes ( records ) en utilisant une communication orientée flots d octets ( byte stream ). Il doit traiter manuellement toutes les erreurs possibles. Non pas les erreurs de transmission mais les cas d erreurs de programmation, d inconsistance qui apparaissent dans certains cas en exécution. Ces traitements d erreur ont été ici réduits ici à rien mais ils représentent un pourcentage en général très important d un code de programme fiable. Par exemple, les descripteurs de sockets sont très faiblement typés : un descripteur de socket dédié à un mode de communication (avec connexion) peut être accidentellement utilisé pour un autre mode (sans connexion). Une solution plus flexible devrait automatiser une grande partie des traitements et surtout des traitements d erreurs, rédigés une fois pour toute par des spécialistes. I.9) Portabilité. Quel est le niveau de souplesse de la solution? Le programme écrit dépend complètement de l interface socket utilisée. Le portage vers une autre plate-forme de communication oblige à réécrire une part importante du code. Même conclusion que pour la question précédente. Les interfaces de programmation d application réseau, même si elles prétendent à une certaine généralité sont spécifiques. Les opérations de protage sont nombreuses et coûteuses. 19