Le protocole SSL La scurisation des changes sur

  • Slides: 15
Download presentation
Le protocole SSL La sécurisation des échanges sur Internet Becher Gérard - Greyc -

Le protocole SSL La sécurisation des échanges sur Internet Becher Gérard - Greyc - Université de Caen

Pourquoi SSL ? • Éliminer l'écoute sur le réseau par des parties non autorisées

Pourquoi SSL ? • Éliminer l'écoute sur le réseau par des parties non autorisées : – captation de mots de passe, de n° de carte bancaire, etc. • Assurer la confidentialité et l'intégrité des données – contrefaçons, fraudes diverses • Permettre l'authentification du serveur – empêcher qu'un serveur se fasse passer pour un autre ou s'intercale entre un serveur et un client ("man in the middle"). 9/17/2021 Becher Gérard - Greyc - Université de Caen 2

Qu'est-ce que SSL ? • Un protocole de sécurisation des données circulant sur Internet

Qu'est-ce que SSL ? • Un protocole de sécurisation des données circulant sur Internet : – confidentialité des données – authentification du serveur, – intégrité des données • Secure Socket Layer : – Le plus répandu des protocoles de sécurisation des échanges – Utilisé de façon transparente par de nombreuses applications ou protocoles (http, ftp, pop, smtp, imap, …) 9/17/2021 Becher Gérard - Greyc - Université de Caen 3

Historique • été 1994 : première version de SSL – intégrée dans le navigateur

Historique • été 1994 : première version de SSL – intégrée dans le navigateur Mosaic par Netscape • fin 1994 : deuxième version de SSL – intégrée dans Netscape Navigator • hiver 1995 : SSL v 3. 0 – élimine des défauts de la version antérieure • mai 1996 : standardisation – l'Internet Engineering Task Force (IETF) adopte SSL en tant que standard • janvier 1999 : TLS (Transport Layer Security) – SSL est renommé TLS – TLS v 1. 0 est une extension de SSL v 3. 0 9/17/2021 Becher Gérard - Greyc - Université de Caen 4

Architecture • Couche optionnelle se situant entre les couches d'application et de transport (TCP)

Architecture • Couche optionnelle se situant entre les couches d'application et de transport (TCP) • Permet d'éviter des changement significatifs aux protocoles applicatifs existants (HTTP, FTP, …) • L'application s'interface avec SSL comme avec TCP • Pour TCP, SSL est une application qui utilise ses services 9/17/2021 Becher Gérard - Greyc - Université de Caen 5

Caractéristiques Ø Authentification – – authentification du serveur obligatoire authentification du client facultative Prend

Caractéristiques Ø Authentification – – authentification du serveur obligatoire authentification du client facultative Prend place à l'ouverture de la session Utilise un échange de certificats X 509 v 3 Ø Confidentialité – algorithmes de chiffrement symétriques – Le client et le serveur ont chacun leur propre clé secrète qu'elle partage avec l'autre – algorithmes : DES, 3 DES, RC 2, RC 4, … Ø Intégrité – calcul d'une empreinte (MAC) interdisant la modification d'un fragment de message, sa suppression ou l'insertion d'un faux fragment. 9/17/2021 Becher Gérard - Greyc - Université de Caen 6

Quatre sous-protocoles • Handshake : – authentification des parties et négociation des algorithmes de

Quatre sous-protocoles • Handshake : – authentification des parties et négociation des algorithmes de chiffrement et de hachage • Record : – protection des données des applications et des messages des autres sousprotocoles grâce aux paramètres négociés durant le Handshake • Change. Cipher. Spec : – signale à la couche Record toute modification des paramètres • Alert : – signale les erreurs survenant dans les messages 9/17/2021 Becher Gérard - Greyc - Université de Caen 7

Le Handshake Le client Commence la session Le serveur ØIndique la version SSL Øgénère

Le Handshake Le client Commence la session Le serveur ØIndique la version SSL Øgénère un nombre aléatoire Øtransmet les chiffrements supportés Confirme ØChoisit la version SSL Øgénère un nombre aléatoire Øchoisit l’algorithme de chiffrement Øenvoie son certificat X 509 Le client vérifie le certificat : ü vérifie la date d’expiration ü vérifie le certificat à l’aide de la clé publique de l’autorité de certification ü vérifie que le nom de domaine présent dans le certificat est identique au nom de domaine du serveur 9/17/2021 Becher Gérard - Greyc - Université de Caen 8

Établissement d'un canal sécurisé Le client établit le canal sécurisé Le serveur • génère

Établissement d'un canal sécurisé Le client établit le canal sécurisé Le serveur • génère le Pre. Master. Secret • chiffre le Pre. Master. Secret avec la clé publique du serveur et l'envoie • Le client génère les clés de session : ØIl génère le Master. Secret à partir du Pre. Master. Secret et des nombres aléatoires client_random et server_random ØIl calcule les mêmes clés secrètes que le serveur (à partir du Master. Secret et des nombres aléatoires) 9/17/2021 • Le serveur génère les clés de session : ØIl déchiffre le Pre. Master. Secret ØIl génère le Master. Secret ØIl calcule les clés secrètes : üclés de chiffrement üvecteurs d'initialisation üclés de hachage Becher Gérard - Greyc - Université de Caen 9

Le protocole Change. Cipher. Spec • Une fois le canal sécurisé établi, le protocole

Le protocole Change. Cipher. Spec • Une fois le canal sécurisé établi, le protocole Change. Cipher. Spec entre en action : – Client et serveur envoient le message Change. Cipher. Spec pour indiquer à l'autre l'entrée en vigueur des paramètres de chiffrement négociés – chaque couche Record en est informée et modifie ses paramètres pour pouvoir déchiffrer les données émises par son homologue • Les couches Handshake du client et du serveur émette le message Finished qui est un condensât de tous les messages déjà envoyés, ceci pour déjouer certaines attaques de subtilisation 9/17/2021 Becher Gérard - Greyc - Université de Caen 10

Le protocole Record v Côté émetteur : Ø fragmentation les données en blocs de

Le protocole Record v Côté émetteur : Ø fragmentation les données en blocs de 16 k – 5 octets d'entête Ø compression des données (non encore implémenté) Ø génération d’une empreinte (MAC) pour assurer l'intégrité Ø rajoute éventuellement des caractères de bourrage Ø chiffrement du résultat avec la clé de session Ø ajoute un entête indiquant : ü l'origine du message (Handshake, Alert, CSS, HTTP, …) , ü la version SSL ü la longueur des données encapsulées v Côté récepteur : Ø déchiffrement Ø vérification de l'intégrité Ø décompression Ø réassemblage des données 9/17/2021 Becher Gérard - Greyc - Université de Caen 11

Un bloc de données entête fragment de données MAC bourrage lgr bourrage type version

Un bloc de données entête fragment de données MAC bourrage lgr bourrage type version longueur 5 taille multiple de la taille des blocs de chiffrement Ø Le calcul du MAC (Message Authentication Code) inclut le numéro du fragment et une clé secrète dérivée du Master. Secret Ø Le MAC est chiffré avec les données Ø Conséquences : ü impossible d'insérer un faux fragment ü impossible de supprimer un fragment 9/17/2021 Becher Gérard - Greyc - Université de Caen 12

Le protocole Alert • Indique les changements d'état • Génère des messages suite à

Le protocole Alert • Indique les changements d'état • Génère des messages suite à une erreur quelconque – simples avertissements – erreurs fatales provoquant la fermeture immédiate de la session • Faiblesse du protocole SSL : une certaine fragilité aux attaques de type "déni de service" 9/17/2021 Becher Gérard - Greyc - Université de Caen 13

Les clés de session Ø La clé maître (Master. Secret) est une emprunte mêlant

Les clés de session Ø La clé maître (Master. Secret) est une emprunte mêlant MD 5 et SHA, appliquée trois fois, avec en entrée : – la clé Pre. Master. Secret qui a été transmise de façon sécurisée – les nombres aléatoires des Client. Hello et Server. Hello – les chaînes "A", "BB", "CCC" Ø Une connection SSL v 3. 0 utilise quatre clés de 128 bits, toutes dérivées de la clé maître : – deux clés secrètes de chiffrement (une pour le serveur, une pour le client) – deux clés secrètes pour rendre confidentiel le calcul des MAC : une pour le serveur, une pour le client 9/17/2021 Becher Gérard - Greyc - Université de Caen 14

Optimisations Ø Le déroulement complet du Handshake est très pénalisant. NB. Une page web,

Optimisations Ø Le déroulement complet du Handshake est très pénalisant. NB. Une page web, 10 images = 11 connexions SSL ! Ø Optimisation : le client et le serveur maintiennent un cache indexé par un identificateur de session (ID) – Client. Hello : le client envoie l'ID au serveur – Server. Hello : • l'ID est dans le cache du serveur : confirme l'ID, pas d'échange de certificats, ni de clés • l'ID n'est pas dans le cache : protocole complet Ø Apache/mod_ssl : cache dans /var/run/ssl_cache. db (à effacer si on change le certificat du serveur). 9/17/2021 Becher Gérard - Greyc - Université de Caen 15