Livrable #4. (Document de 23 pages) Fabrice DOUCHANT Tarek AJROUD Charles BALLE Jérémy AMELINE. Roland AGOPIAN

Transcription

1 Master Informatique 1 ère Année Année SSL Livrable #4 (Document de 23 pages) Participants Fabrice DOUCHANT Tarek AJROUD Charles BALLE Jérémy AMELINE Encadrant Roland AGOPIAN Résumé : Ce document décrit le procédé SSL de sécurisation des transactions effectuées via Internet et son utilisation dans les réseaux privés virtuels. Version : 1.2 Page 1/23

2 CONTACTS NOM PRENOM MEL FONCTION DOUCHANT Fabrice Etudiant M1 Informatique AJROUD Tarek Etudiant M1 Informatique BALLE Charles Etudiant M1 Informatique AMELINE Jérémy Etudiant M1 Informatique Version : 1.2 Page 2/23

3 SUIVI DU DOCUMENT NOM DATE VERSION COMMENTAIRES TYPE AMELINE 15/04/ Création du document DOUCHANT 19/04/ Quelques modifications AMELINE 28/05/ Corrections orthographiques, suppression des répetitions, ajout d informations En cours de publication En cours de publication En cours de publication Version : 1.2 Page 3/23

4 TABLE DES MATIERES 1. Introduction à SSL Historique SSL V1 Juillet SSL V2 Décembre SSL V3 Novembre TLS Comprendre SSL Caractéristiques de sécurité Pourquoi utiliser SSL plutôt qu un autre système? Comment fonctionne SSL?... 7 A. La négociation SSL («handshake»)... 7 B. La communication SSL («record») Comment SSL fait-il pour protéger les communications? Utilisation des certificats Protocole SSL Principe :... 8 A. Première phase :... 8 B. Deuxième phase optionnelle (et souvent non utilisée) : Les détails du protocole SSL :... 9 A. Session SSL... 9 B. Connexion SSL Sous protocoles de SSL :... 9 A. Le protocole SSL handshake B. Le protocole SSL Alert C. Le protocole SSL Record D. Comment s assemblent les protocoles? E. Liste des numéros de port associés à SSL Les problèmes de SSL Les proxy Problèmes liés au client SSL : le navigateur Problèmes intrinsèques au protocole : Attaques possibles contre SSL et SSL Pourquoi choisir une solution VPN basée sur SSL? Conclusion Version : 1.2 Page 4/23

5 1. Introduction à SSL SSL (Secure Sockets Layers, que l'on pourrait traduire par couche de sockets sécurisée) est un procédé de sécurisation des transactions effectuées via Internet. 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 afin de garantir la sécurité de la transmission de données sur internet. Son principe consiste à établir un canal de communication sécurisé (chiffré) entre deux machines (un client et un serveur) après une étape d'authentification. Le système SSL est indépendant du protocole utilisé, ce qui signifie qu'il peut aussi bien sécuriser des transactions faites sur le Web par le protocole HTTP que des connexions via le protocole FTP, POP ou IMAP. En effet, SSL agit telle une couche supplémentaire, permettant d'assurer la sécurité des données, située entre la couche application et la couche transport (protocole TCP par exemple). Modèle OSI Pile de protocoles 7 - couche application HTTP, SMTP, FTP, SSH, IRC, SNMP, SIP couche session TLS, SSL, NetBIOS 4 - couche de transport TCP, UDP, SCTP, RTP, DCCP couche réseau IPv4, IPv6, ARP, IPX couche de liaison Ethernet, WiFi, Token ring, FDDI,... Figure 1 - SSL et le modèle OSI Dans la pile de protocole TCP/IP, SSL se situe entre les couches applications (comme HTTP, FTP, SMTP, etc.) et la couche transport TCP. Son utilisation la plus commune reste cependant au dessous de HTTP. La couche SSL est implémentée par la couche application de la pile, ce qui à deux conséquences : pour toutes applications existantes, il peut exister une application utilisant SSL. Par exemple, l'application HTTPS correspond à HTTP au dessus de SSL ; une application SSL se voit attribuer un nouveau numéro de port par l'iana (Internet Assigned Numbers Authority). Par exemple HTTPS est associé au port 443. De cette manière, SSL est transparent pour l'utilisateur. Un utilisateur utilisant un navigateur Internet pour se connecter à un site de commerce électronique sécurisé par SSL enverra des données chiffrées sans aucune manipulation nécessaire de sa part. La quasi intégralité des navigateurs supporte désormais le protocole SSL. Netscape Navigator affiche par exemple un cadenas verrouillé pour indiquer la connexion à un site sécurisé par SSL et un cadenas ouvert dans le cas contraire, tandis que Microsoft Internet Explorer affiche un cadenas uniquement lors de la connexion a un site sécurisé par SSL. Indicateur de sécurité sur quelques navigateurs : Figure 2 - Indicateur de sécurité sur quelques navigateurs Un serveur web sécurisé par SSL possède une URL commençant par où le "s" signifie bien évidemment secured (sécurisé). Au milieu de l'année 2001, le brevet de SSL appartenant jusqu'alors à Netscape a été racheté par l'ietf (Internet Engineering Task Force) et a été rebaptisé pour l'occasion TLS (Transport Layer Security). Version : 1.2 Page 5/23

6 2. Historique Depuis quand ce protocole existe-t-il? A-t-il évolué depuis? Ce chapitre répond à ces questions en montrant l évolution du protocole SSL à travers les différentes versions depuis sa création SSL V1 Juillet 1994 Développé par Netscape, il n'a jamais été diffusé SSL V2 Décembre 1994 Le protocole est diffusé en même temps que la première version du navigateur Navigator. SSL v2 se fonde ainsi sur l'authentification du serveur par le poste client et sur l'utilisation d'un certificat serveur au format X.509 v3. Cette authentification ne nécessite, du côté du poste client, que des calculs en clé publique SSL V3 Novembre 1995 Par rapport à SSL v2, SSL v3 offre en plus la capacité, pour le serveur, d'authentifier le client. Dans ce cas, le client doit pouvoir d'une part exploiter sa clé privée et d'autre part fournir son certificat au format X.509 v TLS En 2001, le brevet de SSL appartenant jusqu'alors à Netscape a été racheté par l'ietf (Internet Engineering Task Force) qui l'a rebaptisé TLS (Transport Layer Security). Le protocole TLS correspond à la version 3.1 de SSL (RFC 2246). Il existe, entre TLS et SSL v.3.1, des différences faibles mais suffisantes pour que ces deux protocoles ne soient pas inters opérables, notamment pour ce qui concerne les algorithmes cryptographiques (calcul du MAC (Message Authentification Code) pour les clés de session) et les codes d'alertes (TLS définit de nouveaux codes d'alerte). Il existe cependant dans TLS, un mécanisme permettant une compatibilité ascendante avec SSL. TLS semble destiné à supplanter SSL dans les développements futurs. Ce protocole dérive de SSL v3. Il en diffère pour la génération des clés symétriques. Cette génération est plus sécurisée dans TLS que dans SSL v3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues quelques faiblesses en cryptanalyse. TLS a été normalisé par l'ietf, groupe de travail TLS : RFC En bref : TLS 1.0 est similaire à SSL v.3 (TLS ~ SSL v.3.1) Différences faibles mais TLS et SSL v.3 ne sont pas inters opérables : o Algorithmes cryptographiques (calcul du MAC pour les clés de session) o Codes d'alertes (TLS définit de nouveaux codes d'alerte) 3. Comprendre SSL Ce chapitre explique le principe de fonctionnement du protocole SSL. Il met en avant les caractéristiques de sécurité ainsi que les utilisations de ce protocole Caractéristiques de sécurité SSL (Secure Socket Layer) est un système qui permet d'échanger des informations entre 2 ordinateurs de façon sûre. SSL assure 3 choses: Version : 1.2 Page 6/23

7 Confidentialité Intégrité Authentification Pour plus d informations sur ces notions se reporter à notre livrable n SSL est un complément à TCP/IP et permet (potentiellement) de sécuriser n'importe quel protocole ou programme utilisant TCP/IP Pourquoi utiliser SSL plutôt qu un autre système? o o o o Il existe une version libre de SSL: OpenSSL ( OpenSSL est open source: tout le monde peut contrôler et vérifier le code source (Le secret réside dans les clés de chiffrement, pas dans l'algorithme lui-même). SSL a été cryptanalysé: ce système a été plus analysé que tous ses concurrents. SSL a été passé en revue par de nombreux spécialistes en cryptographique. On peut donc le considérer comme sûr. Il est répandu: on peut facilement créer des programmes qui dialogueront avec d'autres programmes utilisant SSL. Contrairement à ce qu'on pourrait penser, la sécurité d'un système de chiffrement ne réside pas dans le secret de l'algorithme de chiffrement, mais dans le secret de la clé Comment fonctionne SSL? SSL consiste en 2 protocoles: o SSL Handshake protocol: avant de communiquer, les 2 programmes SSL négocient des clés et des protocoles de chiffrement communs. o SSL Record protocol: Une fois négociés, il chiffre toutes les informations échangées et effectuent divers contrôles. A. La négociation SSL («handshake») Au début de la communication le client et le serveur s'échangent: o la version SSL avec laquelle ils veulent travailler, o la liste des méthodes de chiffrement (symétrique et asymétrique) et de signature que chacun connaît (avec longueurs de clés), o les méthodes de compression que chacun connaît, o des nombres aléatoires, o les certificats. Client et serveur essaient d'utiliser le protocole de chiffrement le plus puissant et diminuent jusqu'à trouver un protocole commun aux deux. Une fois que cela est fait, ils peuvent commencer à échanger des données. B. La communication SSL («record») Avec SSL, l'expéditeur des données: o découpe les données en paquets, o compresse les données, o signe cryptographiquement les données, o chiffre les données, o les envoie. Celui qui réceptionne les données: o déchiffre les données, Version : 1.2 Page 7/23

8 o o o vérifie la signature des données, décompresse les données, rassemble les paquets de données Comment SSL fait-il pour protéger les communications? SSL utilise: o un système de chiffrement asymétrique (comme RSA ou Diffie-Hellman). Il est utilisé pour générer la master key (clé principale) qui permettra de générer des clés de session. o un système de chiffrement symétrique (DES, 3DES, IDEA, RC4...) en utilisant les clés de session pour chiffrer les données. o un système de signature cryptographique des messages (HMAC, utilisant MD5, SHA...) pour s'assurer que les messages ne sont pas corrompus. C'est lors de la négociation SSL que le client et le serveur choisissent des systèmes communs (chiffrement asymétrique, symétrique, signature et longueur de clé) Utilisation des certificats Lors d'une négociation SSL, il faut s'assurer de l'identité de la personne avec qui on communique. Comment être sûr que le serveur auquel on parle est bien celui qu'il prétend être? C'est là qu'interviennent les certificats. Au moment de se connecter sur un serveur web sécurisé, ce dernier enverra un certificat contenant le nom de l'entreprise, son adresse, etc. Pour plus d informations sur les certificats se reporter à notre livrable n Protocole SSL SSL (Secure Socket Layer) est un protocole à négociation (on parle du "handshake" SSL). Clients et serveurs commencent par s authentifier mutuellement, puis négocient une clé symétrique de session qui servira à assurer la confidentialité des transactions. L intégrité de ces dernières est assurée par l application de HMAC (Hashed Message Authentification Code) Principe : Les clés asymétriques utilisées lors des transactions SSL sont encapsulées dans des certificats X.509 version 3, générés par bon nombre d autorités de certification ou de PKI. On distingue deux phases lors du déroulement du handshake SSL : 1. Authentification du serveur 2. et authentification optionnelle du client. A. Première phase : Suite à la requête d un client, le serveur envoie au client son certificat et lui liste les algorithmes qu il souhaite utiliser. Le client vérifie la validité du certificat (à l aide de la clé publique de l AC (Autorité de Certification) contenue dans son navigateur, des dates de validité et, éventuellement, en consultant (rarement dans la pratique) une CRL (Certificate Revocation List = Liste de Révocation de Certificats), puis, si le certificat est valide, génère une clé maître (symétrique), la chiffre à l aide de la clé publique du serveur et la lui envoie. Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l aide de clés dérivées de la clé maître. Version : 1.2 Page 8/23

9 B. Deuxième phase optionnelle (et souvent non utilisée) : Le serveur envoie au client un challenge (une petite série de bits) que le client doit signer, à l aide de sa clé privée correspondant à son certificat, et le renvoyer au serveur pour s authentifier. Il lui envoie de même son certificat, que le serveur vérifiera avant de poursuivre les transactions Les détails du protocole SSL : A. Session SSL Une session SSL est définie par les paramètres suivants partagés entre un client et un serveur : Session identifier : un octet fixé par le serveur pour identifier la session Peer certificat : un certificat pour le serveur, éventuellement un autre pour le client Cipher Spec : définit l algorithme de chiffrement symétrique et l algorithme de condensation Master secret : clé de 48 octets négociée entre le serveur et le client Compression method : NULL pour l instant (en SSLv3 ou TLS) Is resumable : flag qui indique si de nouvelles connexions peuvent être créées à partir de cette session B. Connexion SSL Une connexion SSL est définie par les paramètres suivants partagés entre un client et un serveur : Server and client random : des octets aléatoires déterminés par le client et le serveur pour chaque connexion Server write (send) MAC secret : clé secrète utilisée par le serveur pour faire les MAC Client write (send) MAC secret : clé secrète utilisée par le client pour faire les MAC Server write (send) key : clé symétrique utilisée par le serveur pour chiffrer les données Client write (send) key : clé symétrique utilisée par le client pour chiffrer les données Initialization vectors : pour un algorithme de chiffrement par bloc en mode CBC. Le premier est fixé lors du handshake, les suivants sont les derniers blocs des précédents fragments chiffrés Sequence number : chaque message est numéroté de part et d autre 4.3. Sous protocoles de SSL : Le protocole SSL est constitué des sous protocoles : Le protocole SSL handshake Le protocole SSL Change Cipher Spec (seulement 1 octet) Le protocole SSL Alert Le protocole SSL Record Version : 1.2 Page 9/23

10 A. Le protocole SSL handshake Ce protocole permet au client et au serveur de s authentifier mutuellement, de négocier les algorithmes de chiffrement, de négocier les algorithmes de MAC et enfin de négocier les clés symétriques qui vont servir au chiffrement. Chaque message échangé entre le client et le serveur contient trois champs : Type, indique l objet du message (1 octet) Length, indique la longueur du message (3 octets) Content, contient les données transmises (plus d un octet) Figure 3 - Protocole SSL Handshake A.1. Phase 1 : Etablissement des paramètres de sécurité Cette phase à pour but d établir le lien sécurisé. Se reporter en annexe pour plus d information sur les paramètres du premier message, client_hello, envoyé par le client. Version : 1.2 Page 10/23

11 Après avoir envoyé ces requêtes, le client attend que le serveur réponde en générant une valeur aléatoire, en indiquant la version, et les meilleurs algorithmes qu il peut utiliser : ce sera la réponse server_hello du serveur. A.2. Phase 2 : Authentification du serveur et échange des clés Lors de cette phase, le serveur commence par envoyer son certificat. Ce message peut contenir une chaîne de certificats X.509. L échange de clés entre serveur et client n est possible sans que le serveur n envoie son certificat sauf dans le cas d un Diffie-Hellman anonyme ; dans tous les autres cas, le serveur présente son certificat. Le serveur envoie un message server_key_exchange (se reporter en annexe pour plus d information). Les signatures sont effectuées en utilisant les fonctions de condensation et sont chiffrées grâce aux clés privées (ceci assure que le serveur détient la clé privée associée à la clé publique que contient le certificat). Ensuite, le serveur peut demander au client un certificat : c est le message certificate_request (rarement implémenté dans la réalité), qui comprend les champs certificate_type (algorithme public utilisé) et certificate_authorities (liste des AC valides). Finalement, le serveur envoie le message server_done, qui signifie la fin de cette phase et que le serveur se met en attente. A.3. Phase 3 : Authentification du client et échange des clés Le client doit vérifier que le certificat envoyé par le serveur est valide (c est souvent là que le système est bancal), et que les autres paramètres sont corrects. Si le serveur a demandé au client d envoyer un certificat, le client envoie un message certificate, contenant le certificat (s il n a pas de certificat, il envoie un message no_certificate). Le client envoie ensuite un message client_key_exchange, qui dépend de l algorithme choisi : RSA : le client génère une clé secrète de 48 octets (384bits) qui servira à générer la clé définitive, et l a chiffre avec la clé publique du serveur. D-H anonyme ou temporaire : ce sont les paramètres D-H du client qui sont envoyés. Diffie-Hellman : Dans ce cas les paramètres D-H ont été envoyés avec le certificat, et ce message est donc vide Fortezza : les paramètres Fortezza... Pour finir cette phase, le client envoie un message certificate_verify (sauf si le certificat ne contient que des paramètres D-H, i.e. certificat qui ne peut servir à signer). Ce message consiste en un condensât des messages échangés pendant le handshake, de la clé symétrique générée et des pad, le tout signé avec la clé privée du client. Le but de ce message est de s assurer que le client est bien en possession de la clé privée correspondant à la clé publique envoyée dans le certificat. A.4. Phase 4 : Fin Le client envoie le message (1 octet) change_cypher_spec, qui est en fait l unique message du protocole Change Cipher Spec, et active pour la session courante les algorithmes, clés et sels (Système d Echange Local) du handshake. Puis le client envoie le message finished, qui authentifie le client et valide l échange de clé (le message est constitué d un condensât de la clé symétrique échangée, de l ensemble des messages échangées durant le handshake, du pad et d un identificateur de l expéditeur). Le serveur répond en envoyant son propre change_cypher_spec et clos le handshake. Version : 1.2 Page 11/23

12 B. Le protocole SSL Alert Ce protocole spécifie les messages d erreur que peuvent s envoyer clients et serveurs. Les messages sont composés de deux octets, le premier est soit "warning" soit "fatal". Si le niveau est "fatal", la connexion est abandonnée. Les autres connexions sur la même session ne sont pas coupées mais on ne peut pas en établir de nouvelles. Le deuxième octet donne le code d erreur. Se reporter en annexe pour plus d informations sur les erreurs fatales et les warnings. C. Le protocole SSL Record Ce protocole permet de garantir : La confidentialité des données transmises (c est le Handshake qui permet de négocier une clé symétrique partagée) L intégrité des données transmises (c est encore le Handshake qui négocie une clé partagée qui sert à faire des MAC sur les données) Schématiquement, le protocole SSL Record ressemble à : Version : 1.2 Page 12/23

13 Figure 4 - Protocole SSL Record Dans l entête qui est ajoutée : Content Type : le plus haut protocole utilisé pour traiter ce fragment Major Version : plus haute version de SSL utilisée (3 pour SSLv3) Minor Version : plus basse version utilisée (0 pour SSLv3) Compressed Length : la longueur en octets des données (éventuellement compressées) à chiffrer. Se reporter en annexe pour plus d information sur la création du MAC. D. Comment s assemblent les protocoles? Version : 1.2 Page 13/23

14 Figure 5 - Assemblement des protocoles SSL Version : 1.2 Page 14/23

15 E. Liste des numéros de port associés à SSL Protocole Port TCP nsiiops 261 Description IIOP Name Service sur TLS/SSL https 443 http sur TLS/SSL ddm-ssl 448 DDM-SSL smtps 465 smtp sur TLS/SSL nntps 563 nntp sur TLS/SSL sshell 614 SSLshell ldaps 636 ldap sur TLS/SSL ftps-data 989 ftp données sur TLS/SSL ftps 990 ftp contrôlé sur TLS/SSL telnets 992 telnet sur TLS/SSL imaps 993 imap4 sur TLS/SSL ircs 994 irc sur TLS/SSL pop3s 995 pop3 sur TLS/SSL Figure 6 - Listes des numéros de port associés à SSL 5. Les problèmes de SSL Ce chapitre présente les différents problèmes liés à l utilisation du protocole SSL notamment au niveau du navigateur, au protocole lui-même ainsi que les attaques possibles Les Proxy Le trafic SSL ne s accommode pas de l utilisation de serveurs Proxy classiques (cache et réplication) parce que SSL a été conçu pour contrer les attaques dites "de l homme interposé", et que le Proxy va être considéré comme un attaquant. Pour qu un serveur Proxy puisse gérer du trafic SSL, il doit supporter le protocole SOCKS (qui travaille au niveau socket) ou un protocole spécial de tunneling SSL. Netscape Proxy Server par exemple supporte les deux Problèmes liés au client SSL : le navigateur Les navigateurs n ont pas (encore) de fonctionnalités évoluées de gestion des clés : Les certificats ne peuvent par exemple pas être automatiquement renouvelés et l historique des clés n est pas conservé. Quand un certificat expire, l utilisateur reçoit un message et doit obtenir manuellement un nouveau certificat, ce qui n est pas forcément trivial pour un utilisateur lambda. La cryptographie utilisée par les navigateurs peut être soumise à des restrictions d exportation (hors des Etats-Unis par exemple pour Netscape et Microsoft) cela force les utilisateurs à utiliser des clés de longueur insuffisante. Dans le cas de Netscape, on peut renforcer la cryptographie chez par exemple... tout en veillant à rester en conformité avec la législation... (On peut aussi y voir quelle est la cryptographie utilisée par son navigateur). La relation de confiance est définie par la liste pré installée des autorités de certification : Les navigateurs du commerce sont livrés avec de nombreuses clés publiques pré installées (Netscape en contient 33). Celles-ci sont utilisées pour la vérification de la signature de l autorité de Version : 1.2 Page 15/23

16 certification pour les certificats d autres navigateurs ou serveurs. Pour être conforme, un certificat doit être signé par n importe laquelle des AC présentes dans le navigateur. Par conséquent, si une autorité de certification quelconque parmi les autorités de certification certifie un site frauduleux, ce certificat sera vérifié correctement par des millions de navigateurs. En tant qu utilisateur, il est important d aller voir dans les propriétés "sécurité" de son navigateur et de valider la confiance que l on attribue aux diverses autorités de certification. Par défaut, les navigateurs font confiance à toutes... Les mots de passe : Sur Microsoft Internet Explorer (jusqu a la version 5.0) le mot de passe protégeant les certificats est optionnel alors que protéger sa clé privée est vital Problèmes intrinsèques au protocole : Le système est fondé sur une seule paire de clés : Le principal problème que cela pose vient de la différence entre les contraintes qui pèsent sur les clés de signature/authentification et celles de chiffrement. Avoir la possibilité de sauvegarder en central les clés de chiffrement peut s avérer très pratique (si un utilisateur oublie son mot de passe il n est par exemple pas nécessaire de régénérer une paire de clé et de la certifier à nouveau, mais on peut simplement lui renvoyer ses clés, en l obligeant à ressaisir un mot de passe). Si les services d un tiers sont utilisés pour la sauvegarde d une unique paire de clé (service offert par certaines autorités de certification ou Tiers de Confiance), le client ne sera plus le seul à avoir accès à sa clé privée de signature et la non répudiation n est alors plus assurée. Certes, gérer deux paires de clés est plus lourd que d en gérer une seule. La sauvegarde des clés est importante là où celles-ci sont utilisées pour chiffrer des données stockées, comme des courriers électroniques par exemple. Si les clés ne sont pas sauvegardées et que l accès aux clés est perdu, les données chiffrées n ont plus aucune utilité (et si en essayant d en briser la protection on les récupère quand même, c est alors l application cryptographique qui n est d aucune utilité...). Ce défaut est un peu théorique parce que SSL, dans la pratique, ne chiffre que des flux. Pour un utilisateur "isolé", il est au contraire souhaitable qu aucune de ses clés privées ne soit ailleurs qu en sa possession. Mais il est probable que dans l avenir un même certificat servira à plusieurs types d opérations cryptographiques, auquel cas ce problème se posera. Le protocole SSL ne prévoit pas de vérification systématique des CRL : Lorsqu un serveur Web présente un certificat, le navigateur en vérifie sa validité ; cela consiste pour lui à : Vérifier que les dates de validité sont valides Vérifier que la signature appliquée au certificat est valide Mais le protocole SSL n impose pas qu un certificat ne soit utilisé que suite à la consultation de la CRL qui lui correspond. Un serveur Web peut donc présenter aux navigateurs un certificat révoqué. Netscape 6 permet de vérifier automatiquement les CRL, grâce au protocole OCSP (Online Certificate Status Protocol, désactivé par défaut...). La vérification manuelle des CRL est laborieuse et n est quasiment jamais faite Attaques possibles contre SSL On peut imaginer de construire un site très similaire à un site que l on souhaite abuser. Il est ensuite possible d acheter un certificat chez l une des autorités de certification reconnues par les navigateurs. Le site est mis en place en utilisant un DNS similaire (par exemple " " au lieu de " "), voir même en trompant un serveur DNS pour créer un duplicata de " ". Les utilisateurs ne verront aucune différence, ils croiront être sur le site valide puisque son certificat est vérifié avec succès par le navigateur, et ceci même si le site réel utilise un certificat valide. Vu l absence de consultation automatique des CRL par les navigateurs, l autorité de Version : 1.2 Page 16/23

17 certification qui a émis le certificat pour le site contrefait peut même ensuite révoquer ce certificat sans que les utilisateurs cessent d en vérifier la validité. 6. et SSL Depuis l'apparition du VPN (Virtual Private Network), les entreprises ont pu profiter d'internet pour partager de façon sûr des informations avec des filiales, du personnel, etc... Cependant, les solutions VPN fiables (L2TP/ IPSEC) proposées jusqu'à maintenant présentent comme principales inconvénients une certaine complexité de mise en oeuvre. Ainsi, le déploiement de ses technologies s'avèrent être une tâche souvent difficile, même pour des utilisateurs initiés. Arrivés récemment dans le monde des réseaux privés virtuels, les VPN SSL se révèlent être une alternative séduisante face aux solutions déjà présentes sur le marché, notamment du fait de leurs robustesses et de leurs simplicités de déploiement Pourquoi choisir une solution VPN basée sur SSL? Plusieurs technologies existent pour mettre en place un VPN. Il y a le choix entre des solutions basées sur PPTP (Point To Point Tunneling Protocol), L2TP (Layer Two Tunneling Protocol), IPSEC (Internet Protocol Security), et maintenant sur SSL/TLS (Secure Socket Layer/Transport Layer Security), etc... La majorité des solutions VPN proposées aujourd'hui sont basées sur IPSEC. IPSEC est un ensemble de protocoles permettant d'implémenter des communications sécurisées ainsi que l'échange de clés de cryptage entre deux points distants. Considéré jusqu' aujourd'hui comme la meilleure solution pour déployer un VPN, le protocole IPSEC présente cependant quelques points faibles. L'un des principaux reste sans doute sa complexité de mise en oeuvre. En effet, IPSEC possède beaucoup trop d'options pour être configuré et administré de façon solide par des utilisateurs non experts. De plus, en mode transport, IPSEC présente quelques difficultés à fonctionner derrière les routeurs NAT (Network Address Translation) dû au hachage des adresses sources. IPSEC doit être aussi intégré au noyau linux, ce qui nécessite une recompilation du kernel. Le déploiement d'une solution VPN basé sur IPSEC s'annonce ainsi être une tâche souvent longue et fastidieuse, et peut présenter des risques de sécurité s'il est effectué par des utilisateurs non initiés. Les VPN basés sur PPTP sont quant à eux beaucoup plus facile à déployer mais ne sont malheureusement pas considérés comme très sécurisés. Depuis peu de temps, une technologie fiable et rapide est apparut pour la mise en place d'un réseau privée virtuel: il s'agit des VPN basés sur SSL/TLS. Les VPN SSL apportent les mêmes services que IPSEC, avec beaucoup plus de flexibilité et de facilité de mise en oeuvre. Pour plus d informations sur : les VPN se reporter à notre livrable n 2, les VPN et SSL se reporter au prochain livrable (n 5). 7. Conclusion Il est désormais possible avec la technologie des VPN SSL, et plus précisément OpenVPN de déployer un VPN en alliant fiabilité, sécurité et simplicité. Version : 1.2 Page 17/23

18 Ainsi, les VPN SSL s'avèrent être aujourd'hui la solution la plus simple et la plus efficace en termes de coûts d'installation et d'exploitation pour la mise en place de réseaux privés virtuels. Version : 1.2 Page 18/23

19 BIBLIOGRAPHIE ET LIENS Transport Layer Security (TLS): Développement de TLS (IETF) : TLS Protocol Version 1.0: Site Web d'openssl : Introduction à SSL : Site de sécurité SSL / TLS : Guide pratique des certificats SSL - Version française du SSL Certificates HOWTO : Site de l éditeur d OpenVPN : Créer un VPN sécurisé avec SSL Créer un VPN avec OpenVPN & OpenSSL Création des clés et certificats Configuration d OpenVPN pour Linux Configuration d OpenVPN pour Windows Version : 1.2 Page 19/23

20 ANNEXES PAD : équipement qui permet d accéder aux réseaux à commutation de paquet en adaptant les terminaux. Le protocole SSL handshake : Phase 1 : Etablissement des paramètres de sécurité Les paramètres du premier message, client_hello, envoyé par le client, sont : Version : la plus haute version de SSL que puisse utiliser le client. Random : un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le client. Ces valeurs servent de sel et sont utilisées pour se prémunir contre les rejeux de paquets. Session ID : Un nombre, qui identifie la connexion. Un zéro signifie la volonté du client d établir une nouvelle connexion sur une nouvelle session. Un autre nombre signifie la volonté de changer les paramètres ou de créer une nouvelle connexion sur la session existante. CipherSuite : Une liste, par ordre décroissant de préférence, des algorithmes que supporte le client. Il s agit des algorithmes d échange de clé et de chiffrement. Key Exchange : RSA (clé symétrique chiffrée avec clé RSA contenue dans un certificat) Diffie-Hellman (si le certificat serveur contient des paramètres D-H (Diffie-Hellman). Le client n est pas obligé de présenter un certificat si l authentification du client n est pas demandée par le serveur) Diffie-Hellman temporaire (Une clé symétrique D-H est négociée, les transactions étant signées par des clés RSA ou DSS certifiées par une AC. C est la plus sûre des méthodes parce que la clé générée est unique et authentifiée) Diffie-Hellman anonyme (Un simple échange D-H est effectué, sans authentification des partenaires. Vulnérable à "l attaque du milieu") Fortezza CipherSpec : Cipher Algorithm : DES-40 ; DES, 3-DES, RC2, RC4, IDEA, Fortezza MACAlgorithm : MD5 ou SHA-1 CipherType : Stream ou Block IsExportable : True ou False HashSize : 0, 16 (MD5) ou 20 octets (SHA-1) Key Material : des octets contenant une partie des données utilisées pour générer les clés. IV Size : Taille des Vecteurs d Initialisation pour le chiffrement en mode CBC. Compression Method : liste, par ordre décroissant de préférence, des algorithmes de compression supportés par le client.. Phase 2 : Authentification du serveur et échange des clés Un message server_key_exchange envoyé par le serveur : si le client et le serveur veulent utiliser du D-H anonyme (un nombre premier, un nombre qui lui est relativement premier et la clé publique D-H du serveur), du D-H temporaire (les paramètres D-H et une signature), du RSA key exchange (ou le serveur n a qu une clé RSA pour signer et veut établir une clé RSA temporaire) ou Fortezza. Le protocole SSL Alert : Version : 1.2 Page 20/23

21 A.1. Les erreurs fatales : unexpected_message : message non reconnu bad_record_mac : MAC non correct decompression_failure : la fonction de décompression a reçu une mauvaise entrée handshake_failure : impossible de négocier les bons paramètres illegal_parameter : un champ était mal formaté ou ne correspondait à rien Les warnings sont : Le protocole SSL Record : close_notify : annonce la fin d une connexion no_certificate : réponse à une demande de certificat s il n y en a pas. bad_certificate : le certificat reçu n est pas bon (e.g. signature non valide) unsupported_certificate : le certificat reçu n est pas reconnu certificate_revoked : certificat révoqué par l émetteur certificate_expired : certificat expiré certificate_unknown : tous les problèmes concernant les certificats et non listés au dessus... Le MAC est fait de la façon suivante (effectué avant chiffrement, puis chiffré) : HASH(clé partagée pad_2 HASH(clé partagée pad_1 numéro de ce message protocole pour ce message longueur de ce message les données (compressées)) La fonction de condensation (HASH()) est soit MD5 soit SHA-1 pad_1 = 0x36 et pad_2 = 0x5C (répétés 40 fois pour SHA-1 et 48 fois pour MD5) Les algorithmes autorisés sont : 3-DES 168 IDEA 128 RC4 128 Fortezza 80 DES 56 DES-40 RC4-40 RC2-40 Version : 1.2 Page 21/23

22 INDEX ALPHABETIQUE AC... 8 certificats... 8 CRL... 8 HMAC... 8 IANA... 5 IPSEC L2TP MAC... Voir PPTP Secure Sockets Layers... 5 sel solutions VPN TLS... 6 VPN Version : 1.2 Page 22/23

23 INDEX DES ILLUSTRATIONS Figure 1 - SSL et le modèle OSI... 5 Figure 2 - Indicateur de sécurité sur quelques navigateurs... 5 Figure 3 - Protocole SSL Handshake Figure 4 - Protocole SSL Record Figure 5 - Assemblement des protocoles SSL Figure 6 - Listes des numéros de port associés à SSL Je soussigné, Jérémy AMELINE, avoir lu le document et approuvé son contenu. Je soussigné, Roland AGOPIAN, avoir lu le document et approuvé son contenu. Date : Date : Signature : Signature : Version : 1.2 Page 23/23