WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Etude des protocoles de sécurité dans le réseau internet


par Fils NZALANKUMBU DIALEMBA
Institut supérieur de techniques appliquées Kinshasa - Ingénieur en informatique appliquée 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

V.3.5.2. Architecture

SSL/TLS est conçu pour se servir de TCP afin de fournir un service sécurisé de bout en bout fiable. SSL/TLS n'est pas un simple protocole, mais plutôt constitué de deux couches de protocole.

Record fournit des services de sécurité de base à divers protocoles de couche supérieure.

La deuxième couche est composée de deux sous protocoles :

1' Le protocole de poignée de main (Handshake Protocol) : ce protocole permet d'authentifier les parties en jeu et d'assurer un mécanisme sécurisé pour la gestion des clés ;

1' Le protocole de changement des spécifications de chiffrement (Change Cipher Spec protocol, CCS) : ce protocole comprend un seul et unique message. Son but est d'activer pour la session SSL courante les algorithmes, les clés et les nombres aléatoires durant la phase d'initialisation (la phase Handshake). Ceci en passant ces informations au protocole Record ;

1' Le protocole d'alerte (Alert Protocol) : ce protocole spécifie les messages d'erreur envoyés entre les clients et les serveurs. Les messages sont de deux types : le premier contient les messages d'erreurs fatales (Fatal Error) et le deuxième, les alertes ou les messages d'erreur non fatale (Warning Error). 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.

La Figure V.11 illustre l'Architecture de SSL/TLS.

Fig. V.11. Architecture de SSL/TLS V.3.6. Protocole Handshake

Le protocole Handshake est la partie la plus complexe de SSL/TLS. Il permet l'échange des paramètres de sécurité (nombres aléatoires, liste des algorithmes de chiffrement, de hachage, etc.) entre le client et le serveur avant que les données applicatives ne soient transmises. Il permet aussi l'authentification des

deux communicateurs. Cependant, dans la plupart des cas, le serveur est uniquement authentifié. Ce protocole peut opérer en deux formes : soit il établit un échange complet avec la négociation des paramètres de sécurité (le Handshake complet), soit il essaye d'utiliser une ancienne session SSL/TLS déjà négociée (Handshake abrégé).

V.3.6.1. Handshake Complet

La figure V.12 illustre l'échange initial nécessaire pour établir une connexion complète entre le client et le serveur.

Le client commence l'échange SSL/TLS en envoyant le message ClientHello qui contient un nombre aléatoire (R1), un identificateur de session (S_ID), une liste des algorithmes de compression (compression_list) et une suite de chiffrement (cipher_list). Notons que le nombre aléatoire est une concaténation entre le temps système en format Unix et un nombre aléatoire.

Le serveur répond en envoyant le message ServerHello contenant un nombre aléatoire (R2), un identificateur non nul de session et une suite choisie des algorithmes de chiffrement et de hachage. Le serveur envoie également un certificat X.509 contenant sa clé publique pour s'authentifier. Ensuite, le client vérifie la clé publique du serveur et génère un nombre aléatoire sur 48 octets connu sous le nom du pre_master_secret. Le client chiffre le pre_master_secret avec la clé publique du serveur et l'envoie dans le message ClientKeyExchange.

A la réception de ces messages, le serveur déchiffre le pre_master_secret en utilisant sa clé privée. C'est à ce moment là que le client et le serveur peuvent calculer un secret partagé, le master_secret, à partir des nombres aléatoires R1 et R2 et du pre_master_secret. Ce secret servira par la suite à la dérivation des clés de chiffrement et de déchiffrement dans les connexions SSL/TLS. Le dernier échange achève l'instauration d'une connexion sûre. Les deux entités échangent les messages finished contenant le hachage de l'ensemble des messages et des paramètres négociés.

La Figure V.12 illustre l'Handshake SSL/TLS.

Fig. V.12. Handshake SSL/TLS

Si le certificat client est exigé par le serveur (le serveur envoie le message CertificateRequest), alors le client répond en envoyant le message CertificateVerify contenant sa signature sur toutes les informations échangées avec le serveur. Même si l'authentification par certificat X.509 et par clés RSA reste la plus utilisée pour l'authentification des serveurs SSL/TLS, ces derniers peuvent avoir d'autres méthodes d'authentification telles que l'authentification par des valeurs DH Anonymes (un nombre premier, un nombre qui lui est relativement premier et la clé publique DH du serveur), des valeurs DH temporaires (les paramètres DH et une signature), un échange RSA (où le serveur n'a qu'une clé RSA pour signer et établir une clé RSA temporaire) ou finalement par Fortezza (norme de sécurité du gouvernement américain). Parmi toutes ces méthodes, l'échange du DH temporaire reste le plus sûr.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy