Glasnost

GNUTLS

GNUTLS (GNU Transport Layer Security) est une bibliothèque offrant une API pour la gestion de protocoles de communication sécurisés. Elle est écrite en ANSI C et implémente les protocoles TLS 1.0 et SSL 3.0. La bibliothèque est distribuée sous une licence GNU Lesser GPL.

Ses caractéristiques principales sont :

GNUTLS offre également une API pour OpenSSL. La bibliothèque comporte trois parties : une partie concernant le protocole TLS, une partie dédiée à la gestion des certificats et une partie cryptographie.

Fonctionnement de TLS

TLS (Transport Layer Security) succède à SSL (Secure Sockets Layer Protocol). TLS 1.0 est un protocole en couches : une couche "Record Protocol", une couche "Handshake Protocol" et une couche "Alert Protocol" :

+-----------------------------------------+
| Application | TLS Handshake | TLS Alert |
|   Protocol  |    Protocol   |  Protocol |
+-----------------------------------------+
|            TLS Record Protocol          |
+-----------------------------------------+
|            Couche de transport          |
+-----------------------------------------+

La couche transport

TLS ne dépend d'aucune couche de transport en particulier. Il suffit que la couche de transport soit fiable.

Le Record Protocol

Cette couche permet la communication sécurisée. Elle est utilisée par les autres protocoles et se trouve au-dessus de la couche de transport. Le Record Protocol offre le cryptage symétrique des données, le controle d'authenticité et la compression (optionnelle).

Ce protocole utilise des algorithmes de cryptage tels que 3DES, AES ou ARC4(128). Les algorithmes de compression supportés sont ZLIB et LZO.

L'Alert Protocol

Cette couche permet d'échanger des signaux entre les interlocuteurs. Ces signaux sont principalement destinés à informer des causes d'un échec. Certains signaux sont utilisés en interne par TLS, les autres sont destinés à la couche Application.

Le TLS Handshake Protocol Ce protocole est géré par la couche Application (votre programme). Ce protocole permet la négociation des paramètres de cryptage et d'authentification. La couche Application doit indiquer les paramètres requis pour la connection.

Extensions de TLS

Ces extensions concernent :

Les méthodes d'authentification

Les méthodes d'authentification suivantes sont supportées par TLS :

Authentification par certificat X.509

Cette méthode d'authentification fait partie des métodes d'identification par certificats. Les certificats X.509 contiennent des paramètres publics, un algorithme pour la clé publique de l'utilisateur et la signature de l'Autorité de Certification.

Le protocole X.509 est basé sur un modèle de certification hiérarchique (Hierarchical Trust Model). Dans ce modèle, les Autorités de Certification certifient les entités. Elles peuvent aussi certifier d'autres Autorités de Certification.

  +-----------+
  | CA racine |
  +-----+-----+
        |
   +----+-----+
   |          |
   V          V
+------+   +------+
| CA 1 |   | CA 2 |
+--+---+   +---+--+
   |           |
   |       +---+---+
   |       |       |
   V       V       V
   _       _   +---------+
  ( )     ( )  | Serveur |
  /|\     /|\  |   web   |
   |       |   +---------+
  / \     / \
  Anne  Bernard

Authentification par clé OpenPGP

Cette méthode d'authentification est aussi une méthode d'authentification par certificat. Les méthodes d'échange disponibles sont RSA, RAS_EXPORT, DHE_RSA et DHE_DSS.

La méthode de certification d'OpenPGP est basée sur un modèle "Web of Trust", c'est à dire un système décentralisé de "représentants" (introducers). OpenPGG permet à n'importe qui de signer la clé publique d'une autre personne. Lorsque Anne signe la clé de Bernard, elle "représente" Bernard pour toutes les personnes qui lui font confiance. Si une personne fait confiance à Anne en tant que "représentant", alors Anne est dans l'esprit de cette personne un "représentant fiable" (trusted introducer).


+---------+<......       +---------+
|  Anne   |<---+ :  +----|  Eric   |
+---------+    | :  |    +---------+
  ^     |      | :  v      ^     ^
  |     |    +--------+    |     :
  |     |    | David  |    |     :
  |     |    +--------+    |     :
  |     v                  |     : 
+---------+              +---------+
| Bernard |<-------------| Charles |
+---------+              +---------+

   |                :
   | Représente     : Fait confiance
   v                v

Certaines notions sont importantes dans ce modèle : Anne ne peut signer la clé de Bernard que si elle est certaine que la clé appartient bien à Bernard. Sinon, elle fera croire (induement) à David que la clé appartient à Bernard. David à également la responsabilité de savoir à qui il fait confiance. Ce modèle est très similaire à la vie réelle.

Charles, bien qu'il ait signé la clé de Bernard (car il sait d'une manière ou d'une autre que la clé lui appartient bien), n'accorde pas sa confiance à Bernard en tant que représentant. Charles choisit d'accorder sa confiance à Éric pour une certaine raison. Une (mauvaise) raison possible est qu'il est trop paresseux et signe les clés des autres sans être certain qu'elle leur appartient. Il y a donc une notion de resposabilité individuelle au sein de ce modèle.

Il faut faire la différence entre la confiance au propriétaire (ownertrust) et la validité. Ce ne sont pas des synonymes.

La confiance au propriétaire indique quel degré de confiance on peut accorder à sa signature. Même si trois signatures ou plus affirment que la clé est valide, il est possible que nous n'ayons aucune confiance dans le propriétaire et que, par conséquent, on n'accorde aucune confiance à la signature qu'il a faite. Il existe différents niveaux de confiance :

Par exemple, il nous faut au moins trois signatures marginales ou une signature "confiance" pour valider une clé. La confiance totale n'est utilisée que lorsque l'on est le propriétaire de la clé publique et que nous possédons également la clé privée.

Au cours du porcessus de controle d'une clé, TLS vérifie tout d'abord si la clé n'est pas désactivée. Si l'on ne fait aucune confiance à la clé, les contrôles s'achèvent.

Si la confiance est au moins marginale, toutes les signatures sont contrôlées pour établir la validité de la clé.

Authentification anonyme

L échange de clés anonymes est crypté, mais il n'y a aucune indication de l'identité de l'interlocuteur. Ce type d'identification est vulnérable et donc déconseillé. Il peut cependant être utile lorsqu'il n'y a eu aucun échange préalable entre les interlocuteurs ou lorsqu'un anonymat total est requis.

Authentification SRP

Il s'agit d'une authentification par mot de passe, les deux interlocuteurs étant identifiés par la connaissance d'un mot de passe commun. SRP n'utilise pas le mot de passe complet, mais calcule un "vérificateur" à partir du mot de passe utilisateur. Ceci évite les attaques pouvant résulter du vol d'un fichier de mots de passe.

L'avantage de cette méthode est que le seveur n'a pas besoin de conserver le mot de passe utilisateur. Ce type de protection est similaire au fichier "passwd" d'Unix, où le contenu du fichier ne mets pas en danger la sécurité du système s'il est révélé.

Références

GNUTLS