Sécurité des RO. Partie 6. Sécurisation des échanges. SSL : Introduction. Rappel: Utilités la sécurité à tous les niveaux SSL SSH.

Transcription

1 Sécurité des RO Rappel: Utilités la sécurité à tous les niveaux Partie 6 Sécurisation des échanges SSH Application : S-MIME, PGP, Sbox, OTP Présentation Session : SHTTP Transport : SSL, TLS Réseau : authentification IP (IPsec) Liaison : CHAP, PAP Liaison physique : Bluetooth SSL, TLS, SHTTP IpSec Boîtier de chiffrement Anas ABOU EL KALAM anas.abouelkalam@enseeiht.fr 2 Plan SSL SSH IPSec VPN S-MIME SSL : Introduction SSL défini par netsacpe et intégré au browser Première version de SSL testé en interne Première version de SSL diffusé : V2 (1994) Version actuelle V3 Standard à l IETF au sein du groupe Transport Layer Security (TLS) Standard au sein du WAP Forum Wireless Transport Layer Security (WTLS) PGP 3 4

2 SSL / TLS : caractéristiques SSL : Architecture Repose sur un procédé de crypto à clès publiques Indépendant du protocole utilisé transactions Web (HTTP), connexions via FTP, POP ou IMAP. Agit telle une couche supplémentaire, permettant d'assurer la sécurité des données, située entre couches Appli & transport Transparent pour l'utilisateur Supporté par la quasi totalité des navigateurs Serveur sécurisé par SSL URL commençant par Confidentialité Algo symétriques (3DES, IDEA, RC4) Intégrité MAC (MD5 ou SHA) Authentification X509 et MAC FTP SMTP HTTP Telnet SSL TCP IP NFS XDR SNMP RPC UDP 5 6 Ports au dessus de SSL (1/2) Ports au dessus de SSL (2/2) Protocole sécurisé Port Protocole non sécurisé Application HTTPS 443 HTTP Transactions requêteréponse sécurisées Protocole sécurisé Port Protocole non sécurisé FTP-DATA 889 FTP Transfert de fichiers Application SSMTP 465 SMTP Messagerie électronique FTPS 990 FTP Contrôle du transfert de fichiers SNNTP 563 NNTP News sur le réseau Internet SSL-LDAP 636 LDAP Annuaire X.500 allégé SPOP3 995 POP3 Accès distant à la boîte aux lettres avec rapatriement des messages IMAPS 991 IMAP4 Accès distant à la boîte aux lettres avec ou sans rapatriement des messages TELNETS 992 Telnet Protocole d accès distant à un système informatique IRCS 993 IRC Protocole de conférence par l écrit 7 8

3 SSL : propriétés / services SSL : Protocoles Authentification Serveur (obligatoire), client (optionnel) Utilisation de certificat X509 V3 A l établissement de la session. Confidentialité Algorithme de chiffrement symétrique négocié, clé généré à l établissement de la session. Intégrité Fonction de hachage avec clé secrète : hmac(clé secrète, h, Message) Non Rejeu Numéro de séquence SSL Application Handshake Alert CCS Record TCP 9 10 SSL / TLS : fonctionnement globale échange de clés entre client & serveur. Le client, se connecte au site (marchand) sécurisé par SSL et lui demande de s'authentifier. Le client envoie également la liste des cryptosystèmes qu'il supporte, triée par ordre décroissant de la longueur des clés. Le serveur a réception de la requête envoie un certificat au client, contenant la clé publique du serveur, signée par une CA, ainsi que nom d algo le plus haut dans la liste avec lequel il est compatible Le client vérifie validité certificat (i.e., authenticité marchand), puis Le client crée une clé secrète aléatoire, chiffre cette clé à l'aide de la clé publique du serveur, puis lui envoie clé de session. Le serveur est en mesure de déchiffrer la clé de session avec sa clé privée. Les deux entités sont en possession d'une clé commune dont ils sont seuls connaisseurs. Le reste des transactions peut se faire à l'aide de clé de session, garantissant l'intégrité et la confidentialité des données échangées. TLS : négociation de session Une session définit les éléments suivants : identifiant de session algorithme de compression algorithme de chiffrement, type d algorithme de chiffrement : (par blocs, flux), taille de la clé de chiffrement algorithme de scellement, taille du sceau secret maître aléa serveur, aléa client certificat session réutilisable Clés utilisées : secret maître, aléas serveur et client permettent de calculer la clé de chiffrement et clé de scellement

4 TLS : négociation de session TLS : négociation de session Toute communication sécurisée débute par une négociation de session «TLS Handshake protocol» Format des trames de négociation : Type Taille Contenu Décider du niveau de sécurité (suivant les capacités de chacun) Le serveur s authentifie et envoie les paramètres permettant d établir un pré-secret maître Type : hello_request (0), client_hello (1), server_hello (2)... Objectif Authentification du serveur et éventuellement du client, Le client s authentifie (si requis) et envoie les paramètres permettant d établir un pré-secret maître Négociation des algorithmes de chiffrement et de hachage, échange d un secret, Génération des clés. 13 Fin négociation de session Client & serveur converseront désormais avec algos et clés de sécurité établies 14 La négociation de session TLS Handshake Message Type de message Sens de transmission Signification HelloRequest optionnel serveur client Ce message demande au client d'entamer le Handshake. ClientHello obligatoire client serveur Ce message contient : le numéro de version du protocole SSL ; le nombre aléatoire : client_random ; l'identificateur de session : session_id ; la liste des suites de chiffrement choisies par le client ; la liste des méthodes de compression choisies par le client. ServerHello obligatoire serveur client Ce message contient : le numéro de version du protocole SSL ; un nombre aléatoire : serveur_random ; l'identificateur de session : session_id ; une suite de chiffrement ; une méthode de compression

5 Handshake Handshake Certificate Optionnel serveur client client serveur Ce message contient le certificat du serveur ou celui du client si le serveur le lui réclame et que le client en possède un. ServerKeyExchange Optionnel serveur client Ce message est envoyé par le serveur que s il ne possède aucun certificat, ou seulement un certificat de signature. CertificateRequest Optionnel serveur client Par ce message, le serveur réclame un certificat au client. ServerHelloDone Obligatoire serveur client Ce message signale la fin de l envoi des messages ServerHello et subséquents. ClientKeyExchange Obligatoire client serveur Ce message contient le PreMasterSecret crypté à l aide de la clé publique du serveur. CertificateVerify Optionnel client serveur Ce message permet une vérification explicite du certificat du client. Finished obligatoire serveur client client serveur Ce message signale la fin du protocole Handshake et le début de l émission des données protégées avec les nouveaux paramètres négociés Handshake Handshake Ouverture d'une session SSLv3 Ouverture d'une connexion Client Serveur Client Serveur Client Hello Serveur Hello Certificate (Serveur Key Exchange) (Certificate Request) Server Hello Done (Certificate) Client Key Exchange (Certificate Verify) ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Client Hello Serveur Hello ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data 19 20

6 La négociation de session TLS La négociation de session TLS 1ère phase : authentification serveur 2ème phase : authentification (optionnelle) du Client Suite à la requête d'un C, le S : envoie son certificat au C liste algos cryptos, qu'il souhaite négocier Le C vérifie validité certificat à l'aide Kpub du CA Si le certificat est valide, le client génère un pré-master secret (PMS) de 48 octets Le PMS servira à dériver le MS (48 octets) PMS est chiffré avec clé publique du S puis transmis à ce dernier. Serveur peut demander au client de s'authentifier en lui demandant son certificat. Client réplique en envoyant ce certificat puis en signant un message avec sa clé privée (ce message contient des informations sur la session et le contenu de tous les échanges précédents) Données échangées par la suite entre C/S sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître. Remarque : Clé publique serveur chiffrement Clé privée du client signature La négociation de session TLS Client Hello heure tirage nbre aléatoire client.random (28 octets) session Id : vide = nouvelle session, renseigné = utiliser session déjà ouverte choix d algorithmes de chiffrement supportés méthode de compression supportés n version du client SSL utilisé Server Hello le serveur sélectionne la version tirage nbre aléatoire : server.random (28 oct) session Id : renseigné = N nouvelle session ou session à réutiliser, vide = session à ne pas mettre en cache algorithme de chiffrement sélectionné méthode de compression à utiliser Si session réutilisée, passer en FINISH Si session réutilisée, passer en FINISH La négociation de session TLS Server certificate envoyé si le serveur doit s authentifier, dès que Server Hello a été envoyé contient une chaîne de certificats X509 v3 (avec le certificat racine en dernier), correspond à l algo utilisé (RSA, DH, ) le client dispose donc de la clé publique du serveur Server key exchange Server key exchange envoyé uniquement si le client n a pas toutes les données nécessaires (ex: le serveur n a pas de certificat) paramètres de la clé de chiffrement (modulo, exposant ) hash MD5/SHA (client.random + server.random+paramètres)

7 La négociation de session TLS Certificate request envoyé uniquement si l authentification du client est requise types de certificats admis noms d autorités de certification reconnues Server hello done le serveur attend une réponse du client Client certificate envoyé uniquement si le serveur a réclamé une authentification du client certificat si le client ne possède pas de certificat, une alerte est envoyée au serveur. Suivant les cas, cela peut faire échouer la négociation 25 La négociation de session TLS N version Pre Master Secret Key Client key exchange dans le cas de l algorithme RSA, le client génère un pre-master secret de 46 octets + 2 octets n version (pour détecter les «rollback attacks») il chiffre ce pre-master secret avec la clé publique du serveur Calcul des clés le pre-master secret, client.random et server.random permettent au client et au serveur de calculer 2 clés de sessions (une pour chaque sens), et 2 clés secrètes à utiliser pour les MACs. RSA Clé publique du serveur Pre Master Secret Key sécurisé Client Key Exchange 26 La négociation de session TLS Certificate verify envoyé si le client a envoyé un certificat qui permet de signer hash MD5 et hash SHA de tous les messages de négociation envoyés jusqu ici Client Finish et Server Finish envoyé après un Change Cipher Spec et donc chiffré avec les nouveaux algorithmes négociés. client et serveur doivent envoyer un Finish et vérifier celui qu il reçoive de la partie opposée. PRF(master_secret,finished_label, Hash MD5 +Hash SHA de tous les messages de négociations envoyés jusqu ici) sur 12 octets, finished_label = client finished ou server finished. TLS : génération des clés Utilisation d une fonction de génération de nombres pseudo aléatoires (PRF) permet de convenir de secrets relativement courts et de générer des clés bien plus longues l utilisation de deux algorithmes de hash différents augmente la sécurité PRF(secret,chaine ASCII,sel)=P_MD5(moitié_secret,chaine+sel) XOR P_SHA(autre moitié_secret,chaine+sel) P_hash(secret,sel)=HMAC_hash(secret,A(1)+sel)+ HMAC_hash(secret,A(2)+sel)+ où A(0)=sel et pour i>0 A(i)= HMAC_hash(secret,A(i-1) 27 28

8 TLS : génération des clés Génération du secret maître à partir de : Pré secret maître établi par le client (client key exchange) des aléas serveur et client de la chaîne ASCII «master_key» effacer le pré secret maître de la mémoire Génération d un bloc de clés à partir de : secret maître des aléas serveur et client de la chaîne ASCII «key expansion» générer un bloc de taille suffisante (PRF) et le découper pour obtenir la clé de scellement client, serveur, clé de chiffrement client et serveur, vecteurs d initialisation client et serveur (chiffrement par blocs) 29 TLS : pile de protocole Handshake authentification mutuelle C/S négociation algos chiffrement, hachage, échange clés symétriques Change Cipher Spec Notif du S que tous messages qui vont suivre message Client Finished seront chiffrés avec clés / algos négociés. Alert Alertes qui peuvent être envoyés par chacunedes parties suite aux evnt qui peuvent subvenir Record sécurité des données HTTP sécurité des autres couches de protocoles TLS Quatre Protocoles TLS Handshake Protocol TLS Modif Cipher spec protocol TLS Record Protocol TCP IP TLS Alert Protocol HTTP 30 ChangeCipherSpec (CCS) Le protocole Record ChangeCipherSpec signale au Record toute modification des paramètres de sécurité, Constitué d un message (1 octet) Reçoit les données des couches supérieures: (Handshake, Alert, CCS,, HTTP, FTP...), et les transmet au protocole TCP. Après application de : Après application de : la fragmentation des données en blocs de taille maximum de 2 14 octets la compression des données, fonction prévue mais non supportée actuellement la génération d un condensât pour assurer le service d intégrité le chiffrement des données pour assurer le service de confidentialité 31 32

9 Le protocole Alert Le protocole Alert (2) Le protocole Alert peut être invoqué: par l application, par exemple pour signaler la fin d une connexion par le protocole Handshake suite à un problème survenu au cours de son déroulement par la couche Record directement, par exemple si l'intégrité d'un message est mise en doute Message Contexte Type bad_certificate échec de vérification d un certificat fatal bad_record_mac réception d un MAC erroné fatal certificate_expired certificat périmé fatal certificate_revoked certificat mis en opposition (révoqué) fatal certificate_unknown certificat invalide pour d autres motifs que ceux précisés précédemment close_notify interruption volontaire de session fatal decompression_failure les données appliquées à la fonction de décompression sont invalides (par exemple, trop longues) handshake_ failure impossibilité de négocier des paramètres satisfaisants fatal illegal_parameter un paramètre échangé au cours du protocole Handshake dépasse les bornes admises ou ne concorde pas avec les autres paramètres no_certificate réponse négative à une requête de certificat avertissement ou fatal unexpected_message arrivée inopportune d un message fatal unsupported_certificate le certificat reçu n est pas reconnu par le destinataire avertissement ou fatal fatal fatal fatal TLS : traitement des données TLS : traitement des données Données applicatives Fragmentation (2 14 octets maxi) Fragment 1 Fragment 2 Compression (ajoute 1024 octets maxi) Compressé Scellement (HMAC) Compressé MAC Chiffrement (ajoute 2048 octets maxi) Fragment Chiffré Fragmentation : frontières messages clients peuvent être déplacées fragments de 2 14 octets au plus Compression (optionnelle) : ajoute au pire 1024 octets sans pertes Sceau : HMAC(MAC_write_secret,seq_num+type de protocole TLS+version TLS+taille du fragment compressé+fragment compressé) + = concaténation Chiffrement : le fragment peut être paddé (chiffrement par blocs) on chiffre le fragment compressé + MAC ajoute au pire 1024 octets Données applicatives Frag 1 Frag 2 Compressé Compressé MAC Fragment Chiffré 35 36

10 TLS : PDU (Protocol Data Unit) de données TLS : protocole d alerte Type Maj Min Taille Données (compressées) MAC chiffré Type de protocole : TLS Cipher Change Protocol (20) TLS Alert Protocol (21) TLS Handshake Protocol (22) données applicatives (23) Version : 3.1 Taille : taille des données chiffrées ( max). Niveau d alerte : avertissement fatal Message : fermeture de session mauvais format de message MAC erroné, erreur de déchiffrement, erreur de décompression overflow (message trop long) mauvais certificat... Niveau PDU alerte Description Var d état d une session TLS Var d état d une connexion TLS Session ID (l'dentifiant de session) séquence aléatoire de 32 octets choisie par le serveur pour identifier session. Peer certificate (le certificat du pair) c'est un certificat X 509 du correspondant (soit pour un serveur ou un client). Compression method Algo de compression utilisé Cipher spec (suite de chiffrement) définit les algorithmes de chiffrement et de hachage MasterSecret clé de 48 octets partagée entre le client et le serveur. Is resumable (le drapeau) flag qui indique si il est possible d'ouvrir de nouvelles connexions sur la session en question Les paramètres qui définissent une connexion SSL sont ceux qui se seront rafraîchis pendant une session lors d'établissement d'une nouvelle connexion : Server_random et Client_random deux nombres aléatoires de 32 octets, générés par le C et le S lors de chaque connexion Server_MAC_write_secret clé secrète utilisé par le serveur pour calculer les MACs Client_MAC_write_secret clé secrète utilisé par le client pour calculer les MACs Server_write_key clé symétrique utilisé par le serveur pour le chiffrement des données. Client_write_key clé symétrique utilisé par le client pour le chiffrement des données. Initialization vectors vecteur d'initialisation pour le chiffrement par bloc en mode CBC (Cipher Bloc Chaining), l'un du coté serveur et l'autre du coté client. Sequence number chaque message est numéroté, l'un pour le S, l'autre par le C, et chacun codé sur 8 octets

11 SSL : charges SSL : liste non exhaustive de serveur Nom de l API Fournisseur Adresse AOLserver 2.3 America Online. Inc Alibaba2.0 Computer Software Manufacturers Apache 1.3 The ApacheGroup Commerce Server/ CI/NET, Inc. Opération Temps de calcul pour le client (ms) Temps de calcul pour le serveur (ms) Total (ms) Enterprise Server 3.0 Novonyx Enterprise Web Secure/VM 1.1 Beyond-Software Incorporated Ouverture d une nouvelle session (Handshake complet) Rafraîchissement d'une session (Handshake simplifié) Ouverture d une nouvelle connexion Temps de calcul pour 16Ko de données (chiffrement ou déchiffrement, élaboration et vérification du MAC) 18,94 16,9 35,85 0,11 0,11 0,22 0,079 0,071 0,15 5,5 5,3 10,8 Internet Information Server 4.0 MicrosoftCorp. Java Server 1.1 Sun Microsystems Lotus Domino Go Webserver IBM NetscapeEnterprise Server Netscape Communications Corp. netscape.com OracleWeb Application Server Oracle Corp Roxen Challenger 1.2b I Idonex SSLava Phaos Technologies WebSite Professional 2.2 O'Reilly Software WebTen 2.1 Tenon Intersystems Zeus Web Application Server Zeus 3 Technology SSL : liste de suite de chiffrement supportée par un serveur Attaques classiques Serveur et Version Apache SSLLeay 08.0 Jigsaw 2.0 Beta 1 Microsoft IIS/4.0 Netscape Entreprise3.0L Netscape Entreprise 3.0F SSLava Beta 1 Suite Export Code RC4-40 MD5 0x03 RC4-128 MD5 0x04 RC4-128 SHA 0x05 RSA RC2 CBC-40 MD5 0x06 DH et DSA DH et RSA DHE et DSA IDEA CBC SHA 0x07 DES40 CBC SHA 0x08 DESCBC SHA 0x09 3DES EDE CBC SHA 0x0A DES40 CBC SHA 0x0B DES CBC SHA 0x0C 3DES EDE CBC SHA 0x0D DES40 CBC SHA 0x0E DES CBC SHA 0x0F 3DES EDE CBC SHA 0x10 DES40 CBC SHA 0x11 DES CBC SHA 0x12 3DES EDE CBC SHA 0x13 Pistes classiques Casser les clefs Attack replay Man in the middle Attaque à clair ouvert Parades de SSL Taille des clefs Nonces (connection id) Certificats servent à passer les clefs Clefs + Aléas DES40 CBC SHA 0x14 DHE et RSA DES CBC SHA 0x15 3DES EDE CBC SHA 0x

12 Sources de vulnérabilité Scénarios d attaque Taille des clefs SSL v2 Certificats SSL v2 : Forcer une faible taille de clef Tous : Diffie-Hellman anonyme SSL v3 : Accepte Finished avant SSL v3 : Envoi de données chiffrées avant réponse serveur au Finished. avant ChangeCipherSpec Implémentations Exemple 1 Exemple 2 Faible clefs Pas de vérification d intégrité CryptoL SSL v2 Forced weak ciphersuite Tiers à l écoute SSL v3 DH anonymous authentification Man in the middle attack CryptoL 47 48

13 Exemple 3 Exemple 4 Phase 1 Phase 2 Envoi de données chiffrées Permet de casser la clef, puis de répondre SSL v3 Send data before finished server? SSL vs TLS? Différences minimes : TLS = «SSL v3.1» ==> basé sur SSL 3.0 Même si à la fois SSL et TLS sont dispo dans la majorité des navigateurs, ils ne s'intorpére pas un seul doit être choisi dans la phase de négociation Mais TLS peut se trensformer en SSL3 si nécessaire TLS Record Protocol utilise HMAC pour sceller les données Avec TLS, taille padding des données «imprévisible» (jusqu à 255 octets), tandis qu avec SSL, cette taille était prévisible (juste ce qui est nécessaire pour être multiple taille du bloc de chiffrement) TLS utilise une fonction de génération pseudo-aléatoire (PRF) là où SSL utilisait des imbrications de hash MD5 et SHA TLS ne supporte pas Fortezza comme algo d échange de clés. SSL vs SSH? SSH programme et protocole de connexion et d'exécution de commande sur ordi accessible depuis un réseau Les connexions SSH doivent être authentifiées propose de nombreuses autres options peut-être utilisé dans un cadre autre que le Web pur : FTP, POP3 / IMAP / SMTP, telnet permet de son côté de créer un "tunnel" entre ces deux applications, qui reste ouvert et disponible même s'il n'y pas d'échange en cours. SSH est une véritable plate-forme de sécurisation pour toutes formes de communications électroniques. SSL / TLS protocole de sécurisation des communications Internet ne requiert aucune authentification côté serveur : celleci est optionnelle, et une connexion peut être anonyme authentification côté client que par échange de clefs publiques se limite au protocole HTTP (en fait HTTPS, qui est HTTP sécurisé par SSL) SSL/TLS n'est utile qu'en cas d'échange entre deux applications permet de sécuriser le transport d'informations via le Web Anciennes versions de SSL : rollback attack étudiée tous les messages de négociation sont scellés (pas en v2.0) 51 52

14 TLS : conclusion Avantages Protocole assez bien pensé et complet Supportés par de nombreux navigateurs et donc + ou - standard Inconvénients On n est pas averti si le certificat utilisé est répudié Lourd? La renégociation de sessions n est pas prévue, or sur un ftp ou un telnet, une session peut rester ouverte très longtemps Les algorithmes de chiffrement négociés peuvent être un peu faibles (RC4-40 bits notamment). Plan SSL SSH IPSec VPN S-MIME PGP Sécurisation des échanges : SSH Sécurisation des échanges : SSH Intro Apperçu (simplifié) du protocole remplacement sécurisé des commandes telnet, rlogin, rsh et rcp d Unix 1. Négociation de la version du protocole Utilise SSL 2. Identification de l hôte distant (RSA) fonctions supplémentaires 3. Négociation de l algorithme de chiffrement (3DES, Blowfish, IDEA,...) authentification par clés publiques 4. Génération et échange d une clé de chiffrement de session tunnels 5. Authentification de l utilisateur Secure ftp (sftp) Implémentations - soit par clé publique / privée - soit par login traditionnel 6. Session établie à partir de cet instant, tous les échanges sont chiffrés la clé de session est générée à l aide du protocole Diffie-Hellman SSH ( OpenSSH (

15 Sécurisation des échanges : SSH Utilisation basique sous Unix UnUtilisateur[~] ssh toto.n7.fr Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'toto.n7.fr' added to the list of known hosts. UnUtilisateur@toto.n7.fr's password: XXXXXX Last login: Wed Aug 7 15:34: from UnUtilisateur.n7.fr Sun Microsystems Inc. SunOS 5.7 Generic October 1998 Sun Microsystems Inc. SunOS 5.7 Generic October 1998 toto[~] Clé publique du serveur non connue Clé publique du serveur récupérée Authentification par pwd Sécurisation des échanges : SSH Configuration la paire de clés est générée grâce à la commande ssh_keygen (ssh-keygen -t rsa) pour générer des clés RSA les clés publiques et privées du serveur sont en général stockées dans /etc/ssh à la 1ère connexion d un utilisateur sur un serveur, la clé publique est récupérée et stockée dans $HOME/.ssh/known_hosts du client le démon s exécutant sur une machine serveur est sshd la paire de clés d un utilisateur se trouve en général dans $HOME/.ssh (fichiers id_rsa et id_rsa.pub) => pour authentification des utilisateurs par clés Sécurisation des échanges : SSH Tunneling Sécurisation des échanges : SSH Tunneling Très utile lorsque l on veut établir une connexion sécurisée avec un serveur POP, IMAP par client[~] ssh -n -f serveurssh -L 1234:serveurimap:143 -N exemple et qu on ne dispose pas d une version de ce serveur intégrant les fonctionnalités SSL Client POP Serveur POP création du tunnel : le port local 1234 est donc redirigé sur le port 143 (IMAP) du serveurimap (la transaction est chiffrée jusqu au serveurssh) 1 Client SSH 1. Le client SSH crée un serveur local 2. Le client SSH transmet les requêtes au serveur SSH 3. Le serveur SSH les redirige vers le vrai serveur 2 Communication chiffrée 3 Serveur SSH client[~] telnet localhost 1234 Trying Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] serveur IMAP4rev at Wed, 7 Aug :45: (CEST) 59 60

16 Sécurisation des échanges : SSH Tunneling - Pour la lecture du courrier, le mieux est bien sûr de créer un tunnel en utilisant comme port local le même port que celui du service (IMAP ou POP), et ensuite de modifier les préférences du lecteur de courrier ( pour le serveur IMAP) 1. création du tunnel : ssh -n -f serveurssh -L 143:serveurimap:143 -N 2. modification des préférences du lecteur de courrier (ici Netscape) le serveur IMAP est la machine locale 61 Sécurisation des échanges : SSH Tunneling : un autre exemple Certains sites ne sont accessibles que depuis certains ordis, serveurs ou domaines très précis. Par exe, pour accéder à l'intranet de l'n7, on doit se connecter depuis l'un des ordinateurs de l'école. Cette contrainte permet d'être certain que seules les personnes autorisées pourront accéder à certaines données, après s'être préalablement identifiées au moyen d'un mot de passe. Mais cet avantage a un inconvénient. Si vous êtes à l'étranger, ou si vous êtes tout simplement chez vous et ne pouvez vous rendre physiquement devant les ordinateurs en question, ces ressources vous sont inaccessibles... Solution? La technique du tunnel SSH : «creuser un tunnel» entre votre connexion et un serveur autorisé pour y faire passer les infos de manière sécurisée Etapes 1. ouvrir une connexion sécurisée avec ce serveur (par ex java, à l'n7) 2. dire à votre navigateur de se brancher sur cette connexion ; 3. vous connecter à des sites comme si vous étiez sur ce serveur. 62 Sécurisation des échanges : SSH Ouvrir le Tunnel Sous Linux toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:3128monlogin@java.n7.fr Sous Windows Sécurisation des échanges : SSH Ouvrir le Tunnel dans l'onglet «SSH» puis Tunnel : 1. Source Port : destination : www-cache.n7.fr: Cliquer sur «Add» dans l'onglet «Session» : 1. Host name (or IP@) : java.n7.fr java.n7.fr www-cache.n7.fr 2. Port : Protocole : SSH 4. Saved sessions : N7 par tunnel SSH 7 par tunnel SSH L3128 www-cache.n7.fr:3128 dans l'onglet «session» 1. cliquer sur «save» 63 64

17 Sécurisation des échanges : SSH Empreinter le Tunnel maintenant que le tunnel est ouvert, on peut l'emprunter Exemple de config avec Firefox Indiquez à votre navigateur que vous voulez utiliser un proxy, en cliquant sur «Manual proxy configuration», puis en tapant localhost comme proxy HTTP, et 3128 comme port : Sécurisation des échanges : SSH Empreinter le Tunnel Exemple de config avec IE Allez dans Options, puis cliquez sur l'onglet Connections ; cliquez sur le bouton «Paramètres réseau», Cochez case «Utiliser un serveur proxy pour votre réseau local», et indiquez d'utiliser l'adresse localhost avec le port 3128 : Sécurisation des échanges : SSH Empreinter le Tunnel Maintenant, le tunnel est ouvert, et votre navigateur est disposé à l'emprunter. Demandez-lui d'aller à l'adresse pour vérifier son bon Sécurisation des échanges : SSH Ouvrir le Tunnel Sous Linux toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:3128monlogin@java.n7.fr Sous Windows fonctionnement. dans l'onglet «SSH» puis Tunnel : Reboucher le tunnel Quand vous empruntez un tunnel, en règle générale, n'oubliez pas d'en sortir Source Port : destination : www-cache.n7.fr: Cliquer sur «Add» Dans le cas d'un tunnel SSH, il suffit pour cela de : 1. retourner dans les options de votre navigateur, et de lui indiquer de ne pas utiliser de proxy. 2. fermer la fenêtre de terminal avec laquelle vous avez ouvert le tunnel. www-cache.n7.fr 67 68

18 Plan SSL SSH IPSec VPN S-MIME PGP IPSec : intro Introduction IPsec vise à sécuriser les échanges de données au niveau de la couche réseau (IP) Un des méthodes permettant de créer des VPN, i.e., relier, de manière sûre, 2 systèmes en s'appuyant sur un réseau existant, lui-même considéré comme non sécurisé. défini par un groupe de travail du même nom à l IETF (Internet Engineering Task Force) Services au niveau réseau IPSec n est pas un protocole fixe (ex: alg de chiffrement) créé en 1992, première version en 1995 intégré de base dans IPV6, doit être explicitement utilisé avec IPV4 Propriétés confidentialité des données et protection contre l analyse du trafic intégrité des données authentification de l origine des données protection contre le rejeu => IPSec n est pas un protocole fixe (les algos de chiffrement et d'authentification à proprement parler sont spécifiés séparément du protocole lui-même.), il s agit d un cadre pour implanter des services de sécurité Composants crypto dans l architecture Internet IPSec : Mécanismes 2 mécanismes de sécurité viennent s ajouter au traitement IP classique l Authentication Header (AH) l Encapsulation Security Payload (ESP) IPv6 : IPSec est supporté en natif dans IPv6; IPv4, le champ Protocol du datagramme est modifié pour indiquer la présence d une des 2 extensions AH=51, ESP=50 AH et ESP contiendront eux-mêmes un champ Next Header qui indiquera le type du protocole (TCP,...) initialement contenu dans le datagramme IP 71 72

19 IPSec : les 2 modes d'échange Description des modes d'ipsec Mode transport les mécanismes de sécurité ne sont appliqués qu aux données de la couche supérieure et les informations relevant d opérations sur la couche IP, telles que contenues dans l entête IP, ne sont pas protégées. Mode tunnel les données de la couche supérieure de même que l en-tête d IP du paquet IP sont protégées grâce à une encapsulation. Il est également possible d'encapsuler une communication IPsec en mode tunnel ou transport dans une autre communication IPsec en mode tunnel, elle-même traitée par une passerelle de sécurité, qui transmet les datagrammes après suppression de leur première enveloppe à Mode Transport : s'intercale entre le protocole réseau (IP) et le protocole de transport (TCP, UDP) ne modifie pas l'en-tête initial Plusieurs variantes Mode Tunnel : remplace les en-têtes IP originaux et encapsule la totalité du paquet IP; IPA externe pourra être celle de la passerelle de sécurité implémentant IPSec, IPB interne sera celle de la machine finale, sur le réseau derrière la passerelle. un hôte traitant à son tour les protections restantes ou à une seconde passerelle de sécurité. Mode Nesting : hybride puisqu'il utilise les 2 modes Encapsuler de l'ipsec dans de l'ipsec Tunneling IPSec IPSec : AH (propriétés 1/2) Tunnel ==> encapsulation datagrammes IP dans d autres... Cela permet de : créer des réseaux privés virtuels (ou VPN). Établir une communication sécurisée (le tunnel) entre des entités éloignées, séparées par un réseau non sécurisé/public (Internet), et ce de manière quasi-transparente. Datagramme IPSec Datagramme IP Datagramme IP Datagramme IP Datagramme IP Partie données du datagramme IPSec Tunnel IPSec propriétés générales des tunnels VPNs : les données transitant sont chiffrées (confidentialité+intégrité) les 2 extrémités sont authentifiées les adresses sources/destinations sont chiffrées (IP dans IPSec) autres qualités :anti-rejeux, empêcher attaques man-in-the-middle assure l intégrité et l authentification de l origine des datagrammes IP Authenicité : AH garantit que datagrammes IP reçus ont effectivement été émis par l'hôte dont l'@ IP est indiquée comme adresse source dans les en-têtes. L'unicité (optionnelle, à la discrétion du récepteur) : AH garantit qu'un datagramme ayant été émis légitimement et enregistré par un attaquant ne peut être réutilisé par ce dernier, les attaques par rejeu sont ainsi évitées. L'intégrité : AH garantit que certains champs du datagramme IP n'ont pas été modifiés depuis leur émission : les données (en mode tunnel, ceci comprend la totalité des champs, y compris les en-têtes, du datagramme IP encapsulé dans le datagramme protégé par AH), version (4 en IPv4, 6 en IPv6), longueur de l'en-tête (en IPv4), longueur totale du datagramme (en IPv4), longueur des données (en IPv6), identification, protocole ou en-tête suivant (ce champ vaut 51 pour indiquer qu'il s'agit du protocole AH), adresse IP de l'émetteur, adresse IP du destinataire 75 76

20 IPSec : AH (propriétés 2/2) IPSec : AH (paramètres) L'intégrité (suite) L'intégrité de celles des options IP qui ne sont pas modifiables pendant le transport est assurée, celle des autres options ne l'est pas. Cependant, la valeur que prendront les champs type de service (IPv4), indicateurs (IPv4), index de fragment (IPv4), TTL (IPv4), somme de contrôle d'en-tête (IPv4), classe (IPv6), flow label (IPv6), et hop limit (IPv6) lors de leur réception n'étant pas prédictible au moment de l'émission, leur intégrité n'est pas garantie par AH. Valeur du compteur utilisée pour détecter les datagrammes d IP rejoués afin d assurer l intégrité des séquences de datagrammes AH n'assure pas la confidentialité : les données sont signées mais pas chiffrées. AH ne spécifie pas d'algorithme de signature particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la Rfc 2402 est tenue de supporter les algorithmes MD5 et SHA l index des paramètres sécurité référence une association de sécurité qui définit l algorithme d authentification choisi, les clés utilisées et les partenaires autorisés à utiliser cette association 78 IPSec : AH (modes) IP AH peut être utilisé selon deux modes : Transport ou Tunnel. Transport : l unique modification apportée au datagramme IP d origine est l inclusion du champ en-tête d authentification. Tunnel : un autre en-tête IP est ajouté avant l en-tête IP d origine. IPSec : AH (vérification) Le traitement à la réception d un datagramme IP protégé par l IP AH consiste à vérifier le champ des données d authentification contenu dans l IP AH en comparant sa valeur au résultat du hachage calculé par le destinataire. Si le champ des données d authentification est valide, l intégrité du datagramme IP est prouvée. L authentification de l origine des données est assurée car seuls l expéditeur et le destinataire d un datagramme ont accès à la fonction de hachage sécurisée à la clé secrète partagée dans le cadre de l association de sécurité correspondante Un attaquant peut exécuter une attaque de rejeu en retransmettant au destinataire de l association de sécurité un datagramme IP qui a déjà été transmis entre les deux entités de l association Si le service optionnel de détection de rejeu est sélectionné par le destinataire, alors il est possible de détecter les datagrammes rejoués en utilisant le champ numéro de séquence de l AH 79 80

21 IPSec : Encapsulation Security Payload (ESP) IPSec : Encapsulation Security Payload (ESP) Contrairement à AH, ESP ne protége pas les en-têtes des datagrammes IP utilisés pour transmettre la communication. Seules les données sont protégées. En mode transport, ESP assure : Confidentialité : la partie données des datagrammes IP transmis est chiffrée. Authentification de l'origine des données (optionnelle) : la partie données des datagrammes reçus ne peut avoir été émise que par l'hôte avec lequel a lieu l'échange IPsec, qui ne peut s'authentifier avec succès que s'il connaît la clef associée à l'esp l'absence d'authentification nuit à la confidentialité Unicité (optionnelle, à la discrétion du récepteur): protection contre rejeux Integrité des données (optionnelle) : les données n'ont pas été modifiées depuis leur émission 81 En mode tunnel, ces garanties s'appliquent aux données du datagramme dans lequel est encapsulé le trafic utile, donc à la totalité (en-têtes et options inclus) du datagramme encapsulé. En mode tunnel, deux avantages supplémentaires apparaissent: La confidentialité, limitée, des flux / traffic car il permet aux passerelles de sécurité de cacher l identité des hôtes source et de destination ainsi que la taille réelle des datagrammes IP. Attaquant qui sniffe données transitant par un lien ne peut pas déterminer quel volume de données est transféré entre deux hôtes particuliers. e.g., si la communication entre deux sous-réseaux est chiffrée à l'aide d'un tunnel ESP, le volume total de données échangées entre ces deux sous-réseaux est calculable par cet attaquant, mais pas la répartition de ce volume entre les différents systèmes de ces sous-réseaux. La confidentialité des données, si elle est demandée, s'étend à l'ensemble des champs, y compris les en-têtes, du datagramme IP encapsulé dans le datagramme protégé par ESP) 82 IPSec : ESP ESP ( mode) ne spécifie pas d'algorithme de signature ou de chiffrement particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la Rfc 2406 est tenue de supporter l'algorithme de chiffrement DES en mode CBC, et les signatures à l'aide des fonctions de hachage MD5 et SHA-1 IPSec : ESP Portée de la confidentialité et de l'authentification en mode Transport & Tunnel Données d'authentification Mode tunnel 83 En mode Transport, l en-tête du diagramme IP sont à texte clair. Si tout le datagramme qui inclut infos du protocole doit aussi être protégé ==> utiliser mode Tunnel Il permet en effet que les passerelles de sécurité, agissant comme noeuds intermédiaires entre les hôtes source et de destination finaux, mettent en oeuvre le protocole IP ESP en encapsulant le datagramme IP d origine échangé entre la source et la destination avec un autre en-tête IP utilisé uniquement sur le chemin protégé entre ces passerelles. 84

22 IPSec : Différences AH // ESP ESP en mode Transport, l en-tête du diagramme IP (@source sont à texte clair Si tout datagramme qui inclut infos du protocole doit être protégé ==> utiliser ESP en mode Tunnel ESP mode Tunnel permet que les passerelles de sécurité, agissant comme noeuds intermédiaires entre hôtes source et dest finaux, mettent en oeuvre le protocole IP ESP en encapsulant le datagramme d origine échangé entre source & dest avec un autre en-tête IP utilisé uniquement sur le chemin protégé entre ces passerelles. Contrairement au champ données d auth. AH, le champ données d auth. ESP est optionnel et l authentification fournie ne couvre que les champs de l en-tête ESP, de la charge ESP et du remplissage d u datagramme. L en-tête IP (celui d origine dans le mode Transport ou le nouveau enmode Tunnel) n est jamais protégé par le service d authentification ESP. Dans les cas où l intégrité et la confidentialité des données de tout le datagramme IP sont obligatoires, il est donc recommandé d utiliser IP ESP en association à IP AH. 85 IPSec : calcul données d'auth. L auth. fourni par AH et ESP est basé sur une fonction de hachage sécurisée Les données d authentification peuvent être calculées de deux manières : EK(H(M)) où : E : fonction chiffrement utilisant alg symétrique ou asymétrique K : clé secrète partagée par source/dest dans cas d un algo symétrique et la clé secrète privée de source dans le cas d un algo asymétrique H : condensat de message calculé avec MD5 ou SHA-1 en appliquant fonction hachage (H) sur une association du message (M) et de la valeur secrète (K) partagée par source et destination. H(K, M, K), K étant lke secret partagé HMAC(K, M) = H(K P1, H(K P2, M)) où P1 et P2 sont deux chaînes de bits constantes et représente l opération d ou-exclusif bit par bit. 86 IPSec : Internet Key Exchange (IKE) IPSec : Internet Key Exchange (IKE) Les mécanismes (AH et ESP) utilisent des paramètres (algos chiffrement, clefs, mécanismes sélectionnés) sur lesquels les tiers communiquants doivent se mettre d accord (les clés doivent être échangées de façon sure!) (le champ SPI référence une entrée dans une base de données où sont stockées ces informations pour une communication donnée, Configuration manuelle possible mais peu réaliste, - sûre pour réseau grande taille ==> configuration dynamique : protocole IKE (Internet Key Exchange) => se charge de l échange des clés mais aussi de la gestion de tous les paramètres relatifs à la sécurisation des échanges Parmi ses avantages figure le mode agressif (pas obligatoire), qui permet d'accélérer la négociation, au prix de la protection d'identité. L'identité est toutefois protégée dans le cas d'une négociation IKE authentifiée à l'aide de signatures à clef publique. Deux manières d'échanger des clefs sont abondamment utilisées : les clefs pré-partagées, les certificats X.509 dans ce dernier cas, deux systèmes d'adresses initialement inconnues pourront protéger leurs échanges => nécessite une authentification des tiers par secret partagé ou par échange de clés publiques (possibilité d utiliser des certificats) => plusieurs clés sont ensuite générées : pour AH (authentification des paquets), pour ESP (chiffrement des paquets) 87 88

23 IPSec : Association de sécurité (SA) La Rfc 2401 (Security Architecture for the Internet Protocol) décrit le protocole IPsec au niveau le plus élevé. En particulier, elle indique ce qu'une implémentation est censée permettre de configurer en termes de politique de sécurité c'est-à-dire quels échanges IP doivent être protégés par IPsec et, le cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable d'utiliser IPsec doit être présente une SPD (security policy database), Les protections offertes par Ipsec sont basées sur des choix définis dans SPD permet de préciser la politique de sécurité à appliquer au système (selon choix administrateur) IPSec : Association de sécurité (SA) Afin de stocker et de manipuler l'ensemble paramètres gérés par IKE et utilisés par mécanismes sécurisation ==> IPsec a recours à notion SA (security association). une SA est une structure de données qui regroupe l'ensemble des paramètres de sécurité associés à une communication donnée Chaque SA est identifiée de manière unique par un SPI, IP de destination de broadcast ou de multicast), un protocole (AH ou ESP). Les SA actives sont regroupées dans une SAD (security association database). La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non-ipsec. Les données de la SA sont trop importantes pour pouvoir être transportées in extenso dans chaque header ==> Chaque entrée de cette base de données est identifiée par un SPI (security parameters index) unique (32 bits) IPSec : Association de sécurité (SA) Les plus importants de ces termes sont : SPD base de données définissant la politique de sécurité (protocole,...) SA une entrée de la SPD SAD liste des SA actives (en cours d'utilisation) Les règles de la SPD doivent pouvoir, si l'adminsitrateur du système le souhaite, dépendre des paramètres suivants : adresse ou groupe d'adresses IP de destination adresse ou groupe d'adresses IP source nom du système (DNS complète, nom X.500 distingué ou général) protocole de transport utilisé (typiquement, TCP ou UDP) nom d'utilisateur complet, comme foo@bar.net (pas obligatoire) importance des données (pas obligatoire sur certains types d'implémentations) ports source et destination (UDP et TCP seulement) Certains paramètres (ID U, Protocole transport, ports srce/dest) peuvent être illisibles à cause d'un éventuel chiffrement ESP au moment où ils sont traités, auquel cas la valeur de la SPD les concernant peut le préciser 91 IPSec : architecture Trafic sortant Lorsque "couche" Ipsec reçoit data à envoyer, elle cconsulte BD politiques (SPD) pour savoir comment traiter ces données. Si SPD indique que trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour SA correspondante et va consulter SAD. Si SA nécessaire existe, elle est utilisée pour traiter le trafic en question. Sinon, Ipsec fait appel à IKE pour établir une nouvelle SA avec caractéristiques requises Trafic entrant Lorsque Ipsec reçoit paquet en provenance du réseau, elle examine l'en-tête pour savoir si ce paquet s'est vu appliquer un ou plusieurs services Ipsec et si oui, quelles sont références de SA Consulte SAD pour connaître param à utiliser pour vérification et/ou déchiffrement. Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l'association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. 92