Aller au contenu principal

1. Introduction

Le protocole Transport Layer Security (TLS) Version 1.2 est spécifié dans [RFC5246]. Cette spécification inclut le cadre pour les extensions à TLS, les considérations dans la conception de telles extensions (voir Section 7.4.1.4 de [RFC5246]), et les considérations IANA pour l'allocation de nouveaux points de code d'extension ; cependant, elle ne spécifie aucune extension particulière autre que les algorithmes de signature (voir Section 7.4.1.4.1 de [RFC5246]).

Ce document fournit les spécifications pour les extensions TLS existantes. Il s'agit, pour la plupart, de l'adaptation et de l'édition de matériel provenant du RFC 4366, qui couvrait les extensions TLS pour TLS 1.0 (RFC 2246) et TLS 1.1 (RFC 4346).

1.1. Extensions spécifiques couvertes​

Les extensions décrites ici se concentrent sur l'extension de la fonctionnalité fournie par les formats de message du protocole TLS. D'autres questions, telles que l'ajout de nouvelles suites de chiffrement, sont reportées.

Les types d'extension définis dans ce document sont :

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), trusted_ca_keys(3),
    truncated_hmac(4), status_request(5), (65535)
} ExtensionType;

Plus précisément, les extensions décrites dans ce document :

  • Permettent aux clients TLS de fournir au serveur TLS le nom du serveur qu'ils contactent. Cette fonctionnalité est souhaitable afin de faciliter les connexions sécurisées aux serveurs qui hébergent plusieurs serveurs 'virtuels' à une seule adresse réseau sous-jacente.

  • Permettent aux clients et serveurs TLS de négocier la longueur maximale de fragment à envoyer. Cette fonctionnalité est souhaitable en raison de contraintes de mémoire chez certains clients et de contraintes de bande passante sur certains réseaux d'accès.

  • Permettent aux clients et serveurs TLS de négocier l'utilisation d'URL de certificats clients. Cette fonctionnalité est souhaitable afin de conserver la mémoire sur les clients contraints.

  • Permettent aux clients TLS d'indiquer aux serveurs TLS quelles clés racine d'autorité de certification (CA) ils possèdent. Cette fonctionnalité est souhaitable afin d'éviter plusieurs échecs de poignée de main impliquant des clients TLS qui ne peuvent stocker qu'un petit nombre de clés racine CA en raison de limitations de mémoire.

  • Permettent aux clients et serveurs TLS de négocier l'utilisation de codes d'authentification de message (MAC) tronqués. Cette fonctionnalité est souhaitable afin de conserver la bande passante dans les réseaux d'accès contraints.

  • Permettent aux clients et serveurs TLS de négocier que le serveur envoie au client des informations sur l'état du certificat (par exemple, une réponse du protocole OCSP (Online Certificate Status Protocol) [RFC2560]) pendant une poignée de main TLS. Cette fonctionnalité est souhaitable afin d'éviter d'envoyer une liste de révocation de certificats (CRL) sur un réseau d'accès contraint et donc d'économiser de la bande passante.

Les clients et serveurs TLS peuvent utiliser les extensions décrites dans ce document. Les extensions sont conçues pour être rétrocompatibles, ce qui signifie que les clients TLS qui prennent en charge les extensions peuvent communiquer avec des serveurs TLS qui ne les prennent pas en charge, et vice versa.

Notez que tous les messages associés à ces extensions qui sont envoyés pendant la poignée de main TLS DOIVENT être inclus dans les calculs de hachage impliqués dans les messages "Finished".

Notez également que toutes les extensions définies dans ce document ne sont pertinentes que lorsqu'une session est initiée. Un client qui demande la reprise d'une session ne sait généralement pas si le serveur acceptera cette demande, et par conséquent il DEVRAIT envoyer les mêmes extensions que s'il ne tentait pas de reprise. Lorsqu'un client inclut un ou plusieurs des types d'extension définis dans un client hello étendu tout en demandant la reprise de session :

  • L'extension d'indication du nom du serveur PEUT être utilisée par le serveur pour décider de reprendre ou non une session comme décrit dans la Section 3.

  • Si la demande de reprise est refusée, l'utilisation des extensions est négociée normalement.

  • Si, d'autre part, l'ancienne session est reprise, alors le serveur DOIT ignorer les extensions et envoyer un server hello ne contenant aucun des types d'extension. Dans ce cas, la fonctionnalité de ces extensions négociée lors de l'initiation de la session d'origine est appliquée à la session reprise.

1.2. Conventions utilisées dans ce document​

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].

Dernière mise à jour le