a presentation of TSL and SSL: historical review, mecanism and limitations.

1. 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

2. Plan
I. Définition
II. Historique
III. Environnement
IV. Architecture
V. Fonctionnement et structure des messages

3. 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.

4. 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.

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

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

7. 3- Diagramme de cas d'utilisation :

8. IV- Architecture
Le 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.

9. 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.

10. 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.

11. V- Fonctionnement et Structure des messages
1- Diagramme de séquence :

12. 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.

13. 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

14. 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 ;

15. Server Certificate
ce 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;

16. 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;

17. 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;

18. Change Cipher Spec Protocol
Le 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;

19. Finished
Le 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;

20. Conclusion :
Les caractéristiques de SSL/TLS sont donc :
- L'indépendance vis à vis des couches inférieures et
supé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.

21. Merci pour votre attention
^_^