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

( Télécharger le fichier original )
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

III.2.4. ISAKMP et le protocole Record de SSL/TLS 8

La dernière étape de notre architecture est le chiffrement de toutes les données échangées par le protocole Record de SSL/TLS.

Nous proposons un mécanisme simple qui ne nécessite aucun changement au niveau du protocole Record. En effet, ce dernier est activé lorsque les deux entités reçoivent les messages CCS (Change Cipher Spec) durant le dernier échange du protocole Handshake de SSL/TLS.

III.2.5. ISAKMP et TLS Extensions

Le RFC 3546 (TLS Extensions) propose une nouvelle extension au protocole SSL/TLS vers de nouvel environnement. Ce travail a renforcé notre proposition et a résolu tous les problèmes de compatibilité des clients SSL/TLS qui veulent négocier ISAKMP à la place du Handshake de SSL/TLS et des serveurs SSL/TLS qui ne soutiennent pas cette option et vice versa.

III.2.6. Procédure pour la définition de nouvelles extensions

La nouvelle extension que nous proposons dans ce chapitre et dans le chapitre suivant respecte la procédure de définition de nouvelles extensions avec TLS Extensions. Nous relevons ci-dessous certains points qui devraient être pris en considération par ce protocole :

v' Les extensions doivent être définies de telle sorte que chaque extension envoyée par le client soit connue par le serveur. Ce dernier répond avec une extension du même type. Dans le cas oü le serveur n'accepte pas l'extension, un message d'erreur est envoyé. En général, les messages d'erreurs ALERT de SSL/TLS devraient être envoyés au serveur. Un champ dans l'extension du serveur est envoyé au client ;

1' Les extensions doivent éviter toute attaque qui force a l'utilisation (ou a la non utilisation) d'une caractéristique particulière manipulant les messages Handshake. Ceci est vrai si les extensions sont ajoutées au message Finished de SSL/TLS. Les développeurs du protocole doivent être conscients que ces extensions ne changent pas le sens des messages envoyés dans le Handshake de SSL/TLS.

III.2.6.1. Négociation de l'échange ISAKMP

Afin de permettre à un client TLS de négocier un échange ISAKMP au lieu du Handshake standard de TLS, un nouveau type d'extension devrait être ajouté aux messages ExtendedClientHello et ExtendedServerHello.

III.2.6.2. Gestion des erreurs

Elle définit de nouveaux types d'erreurs pour l'usage avec ISAKMP et TLS. Les deux nouvelles alertes définies sont : unpresentjsakmp_sa et unrecognized_spi_value. Ces alertes ne doivent être envoyées qu'à la suite de l'utilisation de TLS Extension entre le deux communicants.

1' unsupportjsakmp_sa : cette alerte est envoyée par le serveur si le client demande l'ouverture d'une négociation TLS SA avant l'établissement d'une association de sécurité ISAKMP ;

1' unrecognized_spi_value : cette alerte est envoyée par le serveur s'il ne reconnaît pas l'identificateur de la phase envoyé par le client.

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








"En amour, en art, en politique, il faut nous arranger pour que notre légèreté pèse lourd dans la balance."   Sacha Guitry