openssl ssl pki crypto

par julien - aout 2005

Secure Socket Layer est un protocole légèrement supérieur à la couche 4 du modéle OSI. Il a pour objectif, tel qu'il est définit dans la RFC 2246, de fournir la confidentialité et l'intégrité des données entre deux applications en communication.

La version actuelle de SSL est la 3.1, connue sous le nom de TLS (Transport Layer Security). Ce changement de nom marque le rachat du brevet SSL par l'IETF, appartenant initialement à Netscape. Nous parlerons donc plutôt de TLS que de SSL, cette nouvelle appelation risquant fort de supplanter la première dans les années qui viennent.

TLS utilise, évidemment, le chiffrement pour crypter les données transitant dans les datagrammes. Nous allons voir quels types de chiffrement sont utilisés et comment ils fonctionnent.

Pour transporter toutes les informations indispensables à TLS et, comme nous le verrons plus tard, aux PKI, les certificats aux formats X.509 sont utilisés. La notion de certificat, que l'on peut comparer à l'idée de carte d'identité, et les particularitées de ces certificats seront étudiés dans le 4éme paragraphe.

La plus importante particularité de TLS est qu'il est transparent ! Nous allons voir comment au cours du paragraphe 4 et on finira gentillement tout ca sur une petite conclusion et une bonne clope ;)

heuuuuuuuu…. on me dit dans l'oreillette que FUMER TUE ! alors yora que la conclusion…désolé

La nécessité de chiffrer les communications est presque aussi ancienne que l'invention de la roue.. L'un des algorithmes les plus anciens est l'algorithme de Cesar (voir Asterix et Cléopatre pour une biographie de cet illustre personnage). Cesar, donc, avais besoin de transmettre des messages sans que son contenu ne soit lisible de l'ennemi. Le procédé qu'il utilisa alors relève de la cryptographie dite symétrique car la clé qui sert à crypter le message permet également de le décrypter.

exemple : prenons un nombre entier quelconque pour etre la clé: 5 prenons l'alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ et décalons le de la longueur de la clé: VWXYZABCDEFGHIJKLMNOPQRSTU

maintenant, il suffit d'écrire un message avec l'alphabet initial puis de le transposer dans notre alphabet secondaire:

BIENVENUE SUR LINUXWALL

B est la deuxiéme lettre de l'alphabet conventionnel, donc on le remplace par la deuxième lettre de notre alphabet modifié B → W I → D etc etc …

aussi bien que notre message devient: WDZIQZIPZ NPM GDIPSRVGG

Complétement chiffré et incompréhensible pour qui ne connais pas la clé ! Enfin, presque incompréhensible… En fait, ce système de chiffrement rudimentaire souffre de faiblesse majeures:

1. La quantité de lettres dans un mot n'est pas modifiée par le chiffrement 2. On peut trouver la clé en repérant les lettre qui reviennent fréquemment dans une langue

En effet, dans la langue Française, la lettre qui doit réapparaitre le plus souvent est le “E”. Et bien, essayez de repérer la lettre qui revient le plus souvent dans notre message codé: Il y en a en fait deux: “I” et “Z”. Une fois que l'on à celà, on suppose que “I” veut dire “E”, ce qui nous fait une clé de 4. On tente le décryptage… et ca ne marche pas ! Donc on teste avec Z=E et donc une clé de 5 et la ça fonctionne ! l'algorithme est cassé…..

Bien évidemment, nous parlons ici d'un algorithme enfantin pour notre époque, mais si vous avez compris le principe qui s'applique ici, alorsvous avez compris la cryptographie symétrique. Les informations nécessaires à celle-ci sont toujours les memes:

1. une seule clé qui crypte et décrypte
2. un message
3. un algorithme

On retrouve, dans la catégorie des algos symétriques, des monstres comme AES256 qui est le plus utilisé et également le plus sûr aujourd'hui. Ce dernier utilise des clés de 256 bits, soit un chiffre de longueur 1.157920892373162*10^77….. on est loin du 5 de tout à l'heure :p

La force de cette classe d'algorithme est qu'ils sont rapides ! On peut donc chiffrer une grande quantité d'informations rapidement, ce qui est plutôt indispensable quand on souhaite chiffrer des flux HTTP !!! Mais ils ne sont pas parfait, et le fait d'utiliser une seule clé pour crypter et décrypter induit un problème majeur:

Comment envoyer la clé au destinataire pour qu'il puisse décrypter ???

C'est la qu'intervienne les algorithmes asymétriques.

A la différence du système que nous venons de voir, les algorithmes asymétriques fonctionnent avec DEUX clés. L'une sert à crypter, l'autre à décrypter. Et ce sans notion d'ordre !

On va essayer d'y voir plus clair:

Imaginez une porte qui posséde une serrure mais deux clés: une verte et une rouge.

Si on utilise la clé verte pour fermer la porte, alors la clé rouge permet de l'ouvrir, et inversement. MAIS : il est complétement impossible d'ouvrir la porte avec la clé qui l'a fermée… étrange non ?

Et bien voilà la principale propriété des algorithmes asymétrique, également nommé algorithmes à clé publique. Si on se transpose dans le monde informatique, voilà ce que ça donne:

Nous avons un message M que nous souhaitons chiffrer. Nous disposons de deux clés. Prenons l'une d'entre elles au hasard et nous la nommerons clé PRIVEE.

L'autre clé deviens alors la clé PUBLIQUE.

Donc, nous avons notre message M et une clé privée. Combinons le tout avec un algorithme comme RSA (+ d'infos: http://jvehent.free.fr/taf/rsa/rsa.html) et nous obtenons une message crypté C.

Ce message, qui a été chiffré avec notre clé privée, ne peut être déchifré que grâce à la clé publique !

Sur le réseau Internet, les clés publique sont diffusés publiquement ! Ce qui nous permet d'envoyer des messages chiffrés avec une clé privée et qu'une personne 'lambda' qui souhaite en déchiffrer le contenu puisse le faire en récupérant la clé publique sur des serveurs prévus à cet effet.

MAIS QUEL INTERET ? me direz-vous…Et bien, si le directeur du FBI veut m'envoyer un message super important, pas secret mais super important, je dois posséder un moyen pour m'assurer que c'est bien LUI qui me l'envoie ! Cette méthode, nous venons de la voir.

Nous avons chiffré un message M avec une clé Privée, la définition de privée est qu'elle n'appartient qu'a une personne et que seule cette personne peut l'utiliser. Ainsi, en chiffrant un message avec une clé privée, nous assurons le destinataire que ce message à bien été émis par le propriétaire de ladite clé privée.

Ca vas toujours ? (j'en vois qui dorment dans le fond là… menfin !!)

A l'inverse, si je veux envoyer un message SECRET au directeur du FBI, je dois posséder un moyen pour que personne d'autre que lui ne lise son contenu. Et bien, nous l'avons ce moyen ! Nous possédons la clé publique de cette personne. En chiffrant un message avec cette clé publique, seul le propriétaire de la clé privée correspondante pourra déchiffrer le message.

Si on se transpose de nouveau dans le contexte de TLS, nous revenons à notre problématique de transmission de la clé unique pour l'algorithme symétrique. Dans ce cas, entre un client et un serveur, le client n'a qu'à envoyer une clé publique au serveur. Ce dernier chiffre la clé symétrique avec la clé publique et renvoie le paquet. Le client le reçoit, déchiffre le paquet avec sa clé privée et récupére la clé symétrique pour chiffrer la transaction.

Bein oui, mais pourquoi ne pas utiliser directement le chiffrement asymétrique entre le serveur et le poste plutot que d'avoir 36000 algorithmes différents ?

C'est bien, yen a au moins un qui suis :) Et bien en fait, les algorithmes asymétriques effectuent des opérations sur des nombres premiers qui deviennent vites trés gourmandes en ressources processeur. De fait, chiffrer un flux HTTP avec un algorithme comme RSA augmente énormément les temps de latences et consomment beaucoup de ressources. C'est pourquoi ces algorithmes sont uniquement utilisés pour l'échange des clés nécessaires à des techniques moins gourmandes.

Un certificat numérique est une sorte de “carte d'identité” d'une entité informatique. Le certificat numérique d'un serveur va évidemment contenir la clé publique de celui-ci mais également un certain nombre de champs, d'attributs, reliés à son identité. La structure même de l'Internet ne permet pas de distribuer efficacement des clés tout en s'assurant que la prétendu clé d'un serveur appartient bien à celui-ci.

Le modéle de certificats X.509 permet de pallier à cette déficience en ajoutant l'identité à la clé. Le modéle X.509 est en fait un ensemble de champs, qu'ils soient obligatoires ou optionnels. Pour simplifier l'explication, nous allons observer directement un certificat. Il est disponible en intégralité à l'adresse: https://webmail.microgate.fr/public/webmail-signed-cert.pem et sinon en voici un extrait:

 Certificate:
  Data:
      Version: 3 (0x2)
      Serial Number: 3 (0x3)
      Signature Algorithm: sha1WithRSAEncryption
      Issuer: C=FR, ST=Indre-et-Loire, L=Tours, O=Resgate Security 
 Department, CN=authority.microgate.fr/emailAddress=security@microgate.fr
      Validity
          Not Before: May 13 15:33:45 2005 GMT
          Not After : May 11 15:33:45 2015 GMT
      Subject: C=FR, ST=Indre-et-Loire, L=Tours, O=Resgate Security
 Department, CN=webmail.microgate.fr/emailAddress=security@microgate.fr
      Subject Public Key Info:
          Public Key Algorithm: rsaEncryption
          RSA Public Key: (2048 bit)
              Modulus (2048 bit):
                  00:b4:bf:b6:d0:e6:af:30:5e:5f:a4:b8:6c:01:37:
                  0e:81:e4:c5:11:6e:08:e8:05:24:0d:30:ef:94:35:

C'est le certificat d'un serveur que j'ai mis en production récemment. En observant les champs, on retrouve:

1.Version la version de X.509

2.Serial Number un numéro de série

3.Signature Algorithm les algos qui ont signés le certificat

4.Issuer l'autorité qui a signé le certificat

5.Validity la période de validité

6.Subject le propriétaire du certificat

7.Subject Public Key Info des infos concernant la clé publique

8. etc etc…….

Je ne rentre pas trop dans les détails car à force de voir des certifs., tous ces champs vous sembleront évidents ! Il faut juste ne pas vous inquiéter si l'idée d'“autorité qui a signé le certificat” ne vous évoque rien, car nous n'en avons pas encore parlé. Ce sera dans un autre chapitre.

La signature de l'algorithme est en fait une empreinte (de type MD5 ou SHA1) qui est ensuite chiffrée avec la clé privée de l'autorité. Comme nous l'avons vu précedemment, ce procédé permet de savoir que l'autorité a bien vérifié le certificat elle-même.

Alors maintenant que vous avez vu tout celà, vous devez vous demander à quoi ça sert ?

Et bien imaginez que nous n'utilisions pas les certificats. Je vais tranquillement acheter un truc sur le net, j'arrive sur une page HTTPS et là mon navigateur me dit que le serveur veut utiliser la clé bf:b6:d0:e6:af:30:5e:5f pour chiffrer la communication… Bon, moi je suis pas chiant, je veux bien mais j'ai quand même un doute, elle vient d'oû cette clé ? Parce que rien ne me dit que bf:b6:d0:e6:af:30:5e:5f n'a pas été émise par un hacker qui fait un “man-in-the-middle” dans ma petite conversation avec le serveur de la banque !!!

Voilà oû interviennent les certificats X.509 ! Ils permettent de savoir à qui appartient une clé, qui l'a vérifié et qui l'utilise.

La structure complète du protocole TLS est décrite dans la RFC 2246. Voici comment il y est présenté: “Le rôle principal de TLS est de fournir la confidentialité et l'intégrité des données entre deux applications en communications. Le protocole est composé de deux niveaux: TLS Record Protocol et TLS Handshake Protocol.”

Si l'on se réfère à la modélisation OSI, voici comment se situe TLS:

  +---------------------+
  |     APPLICATION     |7
  +---------------------+
  |    PRESENTATION     |6
  +---------------------+                +----------------------+
  |      SESSION        |5               |TLS Handshake Protocol|
  +---------------------+ <============={+----------------------+
  |      TRANSPORT      |4               |TLS Record Protocol...|
  +---------------------+                +----------------------+
  |      RESEAUX        |3
  +---------------------+
  |      LIAISON        |2
  +---------------------+
  |      PHYSIQUE       |1
  +---------------------+

rappelons briévement le rôle de chaques couche:

1. le media (cable, fibre optique, onde hertzienne)
2. la couche Medium Access Control (MAC)
3. la couche IP ou s'effectue aussi le routage
4. les protocoles comme TCP ou UDP qui transporte les données
5. plus flou dans leurs rôles, on y mélange tout ce qui concerne les ouvertures de sessions comme l'arrivée des données applicatives

Les données applicatives qui devrais normalement être encapsulées dans des paquets TCP/IP vont d'abord etre transformées par les couches du protocol TLS, puis continuer leurs chemin comme si de rien n'était. TLS est un protocole transparent pour le reste de l'infrastructure réseau.

La poignée de mains ! Ce protocol à pour objectif de permettre au serveur et au client de s'authentifier l'un l'autre puis de négocier un algorithme de chiffrement et une clé cryptographique avant que l'application ne transmette son premier octet. Ce protocole posséde trois propriétés importantes:

1. les participants sont authentifiés en utilisant un algorithme asymétrique
2. la négociation de la clé symétrique est sécurisée. Ceci pour prévenir des attaques de types man-in-the-middle.
3. la négociation est sûre. un intrus ne peut pas modifier les informations de néfociation sans être repéré par une des parties.

Nous pouvons donc, grâce à ce protocole, établir des communications privées. Mais pour celà, les messages constituant une sessions de handshake TLS doivent être présentés dans un ordre bien précis; dans le cas contraire il en résulte une erreur fatale d'un des deux systèmes.

Voici comment se passe le handshake, dans l'ordre chronologique de haut en bas:

  +----------------+                                    +----------------+
  |                |< - - - - - - - - - - -CLIENT HELLO-|1               |
  |                |-SERVER HELLO - - - - - -  - - - - >|2               |
  |                |-CERTIFICATE - - - - - - - - - - - >|3               |
  |    S           |-CERTIFICATE REQUEST - - - - - - - >|4               |
  |    E           |-SERVER KEY EXCHANGE - - -  - - - ->|5      C        |
  |    R           |-SERVER HELLO DONE- - - - - - - - ->|6      L        |
  |    V           |<- - - - - - - - - - - -CERTIFICATE-|7      I        |
  |    E           |<- - - - - - - -CLIENT KEY EXCHANGE-|8      E        |
  |    U           |<- - - - - - - - CERTIFICATE VERIFY-|9      N        |
  |    R           |<- - - - - - - - CHANGE CIPHER SPEC-|10     T        |
  |                |<- - -  - - - - - - CLIENT FINISHED-|11              |
  |                |-CHANGE CIPHER SPEC- - - - - - - - >|12              |
  |                |-SERVER FINISHED - - - - - - - - - >|13              |
  |                |< - - - - - ENCRYPTED DATA - - - - >|14              |
  +----------------+                                    +----------------+

et voici les explications des messages envoyés:

* CLIENT HELLO

envoi de la version maximale supportée (TLS = 3.1), de la suite d'algorithmes supportés (par ordre de préférence décroissant) et une valeur aléatoire de 32 octets.

* SERVER HELLO

choix de la version, de la suite d'algorithmes (Cipher Suite) et d'une valeur aléatoire.

Ci-dessous, un paquet “SERVER HELLO” sniffé via ethereal lors d'un handshake pour HTTPS

    Handshake Protocol: Server Hello
          Handshake Type: Server Hello (2)
          Length: 70
          Version: TLS 1.0 (0x0301)
          Random.gmt_unix_time: Mar 13, 2005 19:31:22.000000000
          Random.bytes
          Session ID Length: 32
          Session ID (32 bytes)
          Cipher Suite: **TLS_RSA_WITH_AES_256_CBC_SHA** (0x0035)

en gras, on vois la suite de chiffrement choisie

* CERTIFICATE (optionnel)

envoi d'une chaine de certificats par le serveur. Le premier certificat est celui du serveur, le dernier est celui de l'autorité de certification (voir chapitre 3)

* CERTIFICATE REQUEST (optionnel)

demande un certificat au client pour l'authentifier

* SERVER KEY EXCHANGE (optionnel)

message complémentaire pour l'échange des clés. Ce message contient la clé publique du serveur utilisée par le client pour chiffrer les informations de clé de session

* SERVER HELLO DONE

fin des émissions du serveur

* CERTIFICATE (optionnel)

certificat éventuel du client si le serveur demande une authentification

* CLIENT KEY EXCHANGE

le client produit un secret pré-maître (encrypted pre-master key) et le crypte avec la clé publique du certificat du serveur. Ces informations sont chiffrées une deuxième fois avec la clé publique du serveur (et non la clé publique du certificat du serveur) reçue dans le message SERVER KEY EXCHANGE.

* CERTIFICATE VERIFY (optionnel)

message contenant une empreinte (hash) signée numériquement et créé à partir des informations de clé et de tous les messages précédents. Ce message permet de confirmer au serveur que le client possède bien la clé privée correspondant au certificat client (message 7)

* CHANGE CIPHER SPEC

passage du client en mode chiffrée avec la clé master comme clé symétrique

* CLIENT FINISHED

fin des émissions du client, ce message est chiffré à l'aide des paramètres de la suite de chiffrement.

* CHANGE CIPHER SPEC

passage du serveur en mode chiffrée avec la clé master

* SERVER FINISHED

confirmation au client du passage en mode chiffré. Ce message est chiffré à l'aide des paramètres de la suite de chiffrement

* ENCRYPTED DATA

le tunnel TLS est établit, c'est maintenant le TLS Record Protocol qui prend le relais pour chiffrer les données.

Le niveau inférieur de TLS. C'est lui qui encapsule les message et assure confidentialité et intégrité. Voyons les étapes:

  +----------------------------------------------------------------------+
  ||             DONNEES                                                ||
  ||                       APPLICATIVES                                 ||
  +----------------------------------------------------------------------+
     /                         /
    /                         /
   /                         /
  /                         /
  +------------------------+
  |     FRAGMENT= F.1      |                                           (1)
  +------------------------+
               | |
                V
  +-----------------------------+
  |COMPRESSION {F.1} = C{F.1}   |                                      (2)
  +-----------------------------+
                         ^^^=======>=>=>=>======> +------------------+
                                                  | HASH de C{F.1}   | (3)
                         vvv=======<=<=<=<======< +------------------+
  +--------------------------------+
  |C{F.1} (+) HASH de C{F.1} = M.1 |                                   (4)
  +--------------------------------+
               | |
                V
  +-------------------------------------+
  | CHIFFREMENT SYMETRIQUE {M.1} = Mc.1 |                              (5)
  +-------------------------------------+
               | |
                V
  +-----------++---------------------------------+
  ||  HEADER  ||            Mc.1                 |                     (6)
  +-----------++---------------------------------+
               | |
                V
  /=====================\
  [   PASSAGE  COUCHE   ]
  [       TRANSPORT     ]                                              (7)
  \=====================/

Etape 1

Les blocs de données applicatives sont découpés en fragments de 16Ko (2^14 octets) maximum

Etape 2

Le fragment subit une compression (facultative). Si les blocs sont trés courts, cette compression peut augmenter la taille du bloc initial. Toutefois, la longueur du contenu ne peut être augmentée de plus de 1024 octets.

Etape 3

Une empreinte est prise de C.1 (le fragment compressé). L'algorithme qui prend cette empreinte est choisi dans le message “Cipher Suite” du Handshake. Ici, il s'agit de SHA.

Etape 4

L'empreinte est ajoutée à la suite de C.1 et donne le message M.1

Etape 5

Le message M.1 est chiffré par l'algorithme symétrique (ici il s'agit d'AES 256, voir Cipher Suite) en utilisant la clé symétrique échangée lors du handshake. La résultante est le message Mc.1, crypté !

Etape 6

Un en-tête de 5 octets est ajouté. Le champ “Type” de cet en-tête définit le type du protocole de niveau supérieur au Record Protocol. Les types sont les suivants:

  Valeur   -   Protocole
  -------------------------------------------------
  20         -   ChangeCipherSpec Protocol
  21         -   Alert Protocol
  22         -   Handshake Protocol
  23         -   Application Protocol

Nous n'avons pas étudié, et n'étudierons pas, les protocole 20 et 21 mais leurs noms suffit à comprendre leurs fonctions respectives.

Etape 7

Le message est transmis à la couche Transport de l'émetteur, la plupart du temps il s'agit du protocole TCP.

Pfiou ! c'est fini :) Il n'y a pas grand chose de trés attrayant dans ce chapitre mais ces bases sont importantes pour comprendre la suite. Et encore, la plupart des informations ci-dessus ne sont que trés épurées et si vous souhaitez en savoir plus… ba go google !!! Toutefois, maintenant que les bases sont posées, nous pouvons attaquer une première mise en pratique: Apache SSL ! enjoy et rendez-vous page suivante.

~~DISCUSSION~~