Faculté des Sciences de Tunis: Département des Sciences de l'Informatique

Les protocoles SSL/TLS

Section : IF4 IRSA

Proposé par : Mme H. Kaffel Ben Ayed

Réalisé par : Haifa Rafiaa FTIRICH

Nada HELAOUI

Oussama JABNOUN

Meriem MEJHED MKHININI

08/05/2015

Plan

I. DéfinitionII. HistoriqueIII. EnvironnementIV. ArchitectureV. Fonctionnement et structure des messages

I- Definition :

TLS, abréviation de Transport Layer Security, est un protocole qui garantit la vie privée et l'intégrité des données entre les applications client / serveur de communication sur Internet. Il assure qu'aucun tiers ne peut espionner ou altérer les messages echangés.

II- Historique

Le protocole TLS est le successeur de la Secure Sockets Layer (SSL) qui a été développé par Netscape. La première version du protocole a été testée par l'éditeur en interne, mais c'est la deuxième version (SSL v2) qui a été publiquement diffusée en 1994.

Le développement de ce protocole a été repris par l'IETF au sein du groupe TLS (Transport Layer Security).

Le protocole TLS v1.0 a été normalisé en 1999 par l'IETF dans la RFC 2246 (cf. section Documentation) et présente quelques évolutions mineures par rapport à la version SSL v3. Actuellement la version utilisée est TLSv1.2 . Ces protocoles ne sont pas compatibles mais la plupart des serveurs et des navigateurs web peuvent mettre en œuvre les deux protocoles.

III- Environnement

1- Modèle en couche :Le positionnement du protocole SSL dans le modèle OSI peut être schématisé comme suit :

2- Utilisateurs :TLS offre ses services aux protocoles de la couche application :

3- Diagramme de cas d'utilisation :

IV- ArchitectureLe protocole TLS / SSL peut être divisée en deux couches. La

première couche est constituée du protocole d'application (the application protocol) et les trois sous-Handshake protocoles (the three Handshake sub-protocols): le Protocole Poignée de main (the Handshake Protocol), le protocole Spec Change Cipher ( the Change Cipher Spec Protocol), et le Protocole d'alerte (the Alert Protocol). La deuxième couche est le protocole d'enregistrement ou « Record Protocol ». La figure suivante illustre les différentes couches et de leurs composants.

1- Le protocole Handshake :Les trois sous-protocoles du Handshake sont :

a- Handshake : utilisé pour négocier les informations de session(ID de session, les certificats homologues, la spécification de chiffrement à utiliser, l'algorithme de compression à utiliser, un secret partagé pour générer des clés..) entre le client et le serveur.

b- Change Cipher Spec : modifie le matériel de chiffrement(données brutes qui sont utilisées pour créer des clés pour une utilisation cryptographique) qui est utilisé pour le cryptage entre le client et le serveur. Ce sous-protocole se compose d'un message unique pour informer l'autre partie de la session TLS/SSL que l'émetteur veut changer la collection des clés. La clé est determinée à partir des informations échangées par le handshake.

c- Alert : utilise des messages pour indiquer un changement d'état ou une condition d'erreur à l'hôte. Une liste complète peut être trouvée dans le RFC 2246 . Les alertes sont couramment envoyées lorsque : la connexion est fermée, un message non valide est reçu, un message ne peut pas être déchiffré, l'utilisateur annule l'opération.

2-Le Protocole Record :

Le protocole Record reçoit et crypte les données à partir de la couche d'application et le remet à la couche de transport. Ensuite, il prend les données, les fragmente à une taille appropriée pour l'algorithme cryptographique, les compresse (ou, pour les données reçues, les décompresse), applique un MAC ou HMAC puis chiffrer ( déchiffrer) les données en utilisant les informations négociées au cours du protocole Handshake.

V- Fonctionnement et Structure des messages1- Diagramme de séquence :

2- SSL et TLS proposent les fonctionnalités suivantes :

a- Authentification - Le client doit pouvoir s'assurer de l'identité du serveur. Depuis SSL 3.0, le serveur peut aussi demander au client de s'authentifier. Cette fonctionnalité est assurée par l'emploi de certificats.

b-Confidentialité - Le client et le serveur doivent avoir l'assurance que leur conversationne pourra pas être écoutée par un tiers. Cette fonctionnalité est assurée par un algorithme de chiffrement.

c-Identification et intégrité - Le client et le serveur doivent pouvoir s'assurer que les messages transmis ne sont ni tronqués ni modifiés (intégrité), qu'ils proviennent bien de l'expéditeur attendu. Ces fonctionnalités sont assurées par la signature des données.

3-Structures des messages:HELLOCLIENT :

Quand un client se connecte pour la première fois à un serveur, il est nécessaire d'envoyer le ClientHello comme son premier message.Le client peut également envoyer un ClientHello en réponse à une HelloRequest ou de sa propre initiative afin de renégocier les paramètres de sécurité dans une connexion existante

struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1> };} ClientHello

HelloServer

struct {

ProtocolVersion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

CompressionMethod compression_method;

select (extensions_present) {

case false:

struct {};

case true:

Extension extensions>0..2^16-1<;

};

} ServerHello ;

Server Certificatece message suivra toujours immédiatement le message

ServerHello.

Ce message transmet la chaîne de certificats du serveur vers le client.

Le certificat doit être appropriée pour l'algorithme d'échange de clé de la suite de chiffrement négocié et toutes les extensions négociés.

Structure du message:

opaque ASN.1Cert<1..2^24-1>;

struct {

ASN.1Cert certificate_list<0..2^24-1>;

} Certificate;

ServerHelloDone

Le message d'ServerHelloDone est envoyé par le serveur pour indiquer la fin de la ServerHello et messages associés. Après l'envoi de ce message, le serveur va attendre une réponse du client.

Ce message signifie que le serveur se fait en envoyant des messages à soutenir l'échange de clés, et le client peut procéder à sa phase de l'échange de clés.

Structure du message:

struct { } ServerHelloDone;

Client Key Exchange Message

Ce message est toujours envoyé par le client. Il doit suivre immédiatement le message de certificat client, si elle est envoyée. Sinon, il DOIT être le premier message envoyé par le client après avoir reçu le message d'ServerHelloDone. Avec ce message, le code secret préliminaire est fixé, soit par transmission directe du secret RSA crypté ou par la transmission de paramètres Diffie-Hellman qui permettront de chaque côté se mettre d'accord sur le même secret préliminaire.

Structure du message : Le choix des messages dépend de la méthode d'échange de clé a été sélectionné

struct { select (KeyExchangeAlgorithm) {

case rsa:

EncryptedPreMasterSecret;

case dhe_dss:

case dhe_rsa:

case dh_dss:

case dh_rsa:

case dh_anon:

ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange;

Change Cipher Spec ProtocolLe protocole de spec changement de chiffrement existe pour signaler les transitions dans les stratégies de chiffrement. Le protocole consiste en un seul message, qui est crypté et compressé sous le (pas en attente) l'état actuel de la connexion. Le message se compose d'un seul octet de valeur 1.Le message est envoyé par ChangeCipherSpec la fois le client et le serveur d'avertir le destinataire que les enregistrements suivants seront protégés en vertu de la CipherSpec nouvellement négocié et touches.

struct {

enum { change_cipher_spec(1), (255) } type;

} ChangeCipherSpec;

FinishedLe message Terminé est le premier protégé par les

algorithmes juste négociés, les clés et secrets. Les destinataires des messages finis doivent vérifier que le contenu est correct. Une fois un côté a envoyé son message Terminé et reçu et validé le message fini de ses pairs, il peut commencer à envoyer et recevoir des données d'application sur la connexion.

Structure du message:

struct {

opaque verify_data[verify_data_length];

} Finished;

Conclusion :Les caractéristiques de SSL/TLS sont donc :

- L'indépendance vis à vis des couches inférieures etsupérieures

- Le fonctionnement en mode Client/Serveur

- L'assurance aux deux parties d'une transaction authentifiée (certificats), privée (cryptage) identifiée et intègre (MAC).

L'âge de SSL lui confère une maturité certaine et d'une longue expérience. Malgré ses défaillances au niveau de l'authentification, son utilisation est très répandue et cela prouve sa robustesse. Son évolutivité, ainsi que son évolution lui promettent un bel avenir.

Merci pour votre attention^_^