Transport Layer Security

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis StartTLS)
Aller à : navigation, rechercher

Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet. Le SSL était développé à l'origine par Netscape. Le brevet de Netscape pour le SSL a été racheté en 2001 par l'IETF, qui en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). Par abus de langage, on parle de SSL pour désigner indifféremment SSL ou TLS.

TLS fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité suivants :

  • l'authentification du serveur ;
  • la confidentialité des données échangées (ou session chiffrée) ;
  • l'intégrité des données échangées ;
  • de manière optionnelle, l'authentification ou l'authentification forte du client avec l'utilisation d'un certificat numérique ;
  • la spontanéité, c'est-à-dire qu'un client peut se connecter de façon transparente à un serveur auquel il se connecte pour la première fois ;
  • la transparence, qui a contribué certainement à sa popularité : les protocoles de la couche d'application n'ont pas à être modifiés pour utiliser une connexion sécurisée par TLS. Par exemple, le protocole HTTP est identique, que l'on se connecte à un schème http ou https.

Le groupe de travail correspondant à l'IETF a permis la création du TLS et de son équivalent en mode datagramme, le DTLS. Depuis son rapatriement par l'IETF, le protocole TLS a vécu deux révisions subséquentes : TLS v1.1 en 2006 et TLS v1.2 en 2008.

Présentation[modifier | modifier le code]

Avec le développement d'Internet, de nombreuses sociétés commerciales commencent à proposer des achats en ligne pour les particuliers. L'offre se met à croître régulièrement, mais le chiffre d'affaires dégagé par le commerce électronique restera encore modeste, tant que les clients n'auront pas une confiance suffisante dans le paiement par carte bancaire. Une des façons de sécuriser ce paiement est d'utiliser des protocoles d'authentification et de chiffrement tels que SSL. La session chiffrée est utilisée pour empêcher un tiers d'intercepter des données sensibles transitant par le réseau : numéro de carte lors d'un paiement par carte bancaire, mot de passe lorsque l'utilisateur s'identifie sur un site…

Avec un système SSL, la sécurité a été sensiblement améliorée et les risques pour le client grandement réduits, comparés à l'époque où le paiement par internet était encore une technologie émergente. Bien que, comme tout système de chiffrement, le SSL/TLS ne pourra jamais être totalement infaillible, le grand nombre de banques et de sites de commerce électronique l'utilisant pour protéger les transactions de leurs clients peut être considéré comme un gage de sa résistance aux attaques malveillantes.

En 2009, TLS est utilisé par la plupart des navigateurs Web. L'internaute peut reconnaître qu'une transaction est chiffrée à plusieurs signes :

  • L'URL dans la barre d'adresse commence par https et non http (https://...) ;
  • Affichage d'une une clé ou un cadenas, dont l'emplacement varie selon le navigateur[1] : généralement à gauche de la barre d'adresse mais aussi dans la barre inférieure de la fenêtre ;
  • Les navigateurs peuvent ajouter d'autres signes, comme par exemple le passage en jaune de la barre d'adresse (cas de Firefox).

Il existe quelques cas très spécifiques où la connexion peut être sécurisée par SSL sans que le navigateur n'affiche ce cadenas, notamment si le webmaster a inclus la partie sécurisée du code HTML au sein d'une page en http ordinaire, mais cela reste rare. Dans la très grande majorité des cas, l'absence de cadenas indique que les données ne sont pas protégées et seront transmises en clair.

Historique[modifier | modifier le code]

Protocole SSL[modifier | modifier le code]

La première version de SSL parue, la SSL 2.0, possédait un certain nombre de défauts de sécurité, parmi lesquels la possibilité de forcer l'utilisation d'algorithmes de chiffrement plus faibles, ou bien une absence de protection pour la prise de contact et la possibilité pour un attaquant d'exécuter des attaques par troncature[2]. Les protocoles PCT 1.0, puis SSL 3.0, furent développés pour résoudre la majeure partie de ces problèmes, le second devenant rapidement le protocole le plus populaire pour sécuriser les échanges sur Internet.

  • 1994[3] : SSL 1.0. Cette première spécification du protocole développé par Netscape resta théorique et ne fut jamais mise en œuvre[4].
  • Février 1995 : publication de la norme SSL 2.0, première version de SSL réellement utilisée.
  • Novembre 1996 : SSL 3.0, la dernière version de SSL, qui inspirera son successeur TLS. Ses spécifications sont rééditées en août 2008 dans la RFC 6101[5].

Protocole TLS[modifier | modifier le code]

Malgré le peu de différences entre SSL version 3 et TLS version 1 (qui correspond à la version 3.1 du mécanisme SSL), les deux protocoles ne sont pas interopérables. TLS a tout de même mis en place un mécanisme de compatibilité ascendante avec SSL. En outre, TLS diffère de SSL pour la génération des clés symétriques. Cette génération est plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues des faiblesses en cryptanalyse.

  • Janvier 1999 (RFC 2246[6]) : publication de la norme TLS 1.0. TLS est le protocole développé par l'IETF pour succéder au SSL. Plusieurs améliorations lui sont apportées par la suite :

Mise en œuvre du TLS[modifier | modifier le code]

Support par les navigateurs[modifier | modifier le code]

La plupart des navigateurs web gèrent parfaitement SSL 2.0, SSL 3.0 et TLS 1.0 (ce dernier n'étant pas activé par défaut sous Internet Explorer 6). Les navigateurs supportant par défaut la dernière version TLS 1.2 sont:

  • Google Chrome 30 et suivant ;
  • Mozilla Firefox 27 et suivant ;
  • Microsoft Internet Explorer 11 et suivant ;
  • Opera 17 et suivant ;
  • Apple Safari 7 et suivant.

Une extension pour Firefox est maintenue conjointement par le projet Tor et l'EFF depuis 2010 pour activer d'office, sur le navigateur de l'internaute qui l'a installée, le SSL/TLS sur les certains sites qui en sont dépourvus[13].

Authentification par certificat numérique[modifier | modifier le code]

Dans la majorité des cas, l'utilisateur authentifie le serveur TLS sur lequel il se connecte. Cette authentification est réalisée par l'utilisation d'un certificat numérique X.509 délivré par une autorité de certification (AC). Mais de plus en plus d'applications web utilisent maintenant l'authentification du poste client en exploitant TLS. Il est alors possible d'offrir une authentification mutuelle entre le client et le serveur. Le certificat client peut être stocké au format logiciel sur le poste client ou au format matériel (carte à puce, token USB) pour augmenter la sécurité du lien TLS. Cette solution permet d'offrir des mécanismes d'authentification forte.

Sécurisation du protocole[modifier | modifier le code]

Le protocole TLS permet de créer un tunnel entre un ordinateur et un serveur. Ce tunnel sécurisé permet un échange d'informations en contournant les dispositifs de sécurité installés pour un serveur ou un ordinateur. Passant outre les systèmes de protection il est alors possible que des actions malveillantes soient menées au travers du point d'entrée du tunnel. Afin de limiter les risques, il est techniquement possible de filtrer les contenus d'un tunnel TLS par la mise en place d'un dispositif qui authentifie le client et le serveur. Deux tunnels sont alors mis en place, un depuis le client vers le dispositif d'authentification et le second du dispositif vers le serveur. Ce système permet alors une analyse et une sécurisation transparente des contenus transférés par le tunnel TLS[14].

Attaques[modifier | modifier le code]

En 2001, Serge Vaudenay découvre une attaque par canal auxiliaire contre SSL. Cette attaque profite d'une mauvaise implémentation du remplissage qui est utilisé lorsque les entrées ont une taille variable. Le mode de chiffrement CBC (cipher block chaining) consiste à diviser les données en plusieurs blocs de même taille et à les chiffrer de manière chaînée (le résultat précédent est utilisé lors du chiffrement suivant). L'attaque de Vaudenay utilise les temps de réponse des serveurs en cas d'erreurs lors du remplissage. Avec un peu de chance, il est possible de découvrir les dernières données qui ont été envoyées et de les récupérer. L'attaque est toutefois inopérante avec un chiffrement de type RC4 et n'est valable que sous certaines conditions. Elle a malgré tout été utilisée avec succès contre certains « webmails » qui envoient plusieurs fois les mêmes données. À la suite de cette attaque, le standard a été mis à jour. Cette attaque est maintenant totalement dépassée et ne peut plus du tout être utilisée.

En mars 2014, une grave faille est découverte : Heartbleed, introduite par erreur dans une mise à jour d'OpenSSL réalisée deux ans plus tôt. Cette faille a été largement médiatisée, y compris dans les médias généralistes[15],[16],[17], comme l'avait été notamment le ver I love you en 2000.

Article détaillé : Heartbleed.

Le 15 octobre 2014, une équipe de recherche chez Google a identifié une faille dans la conception de SSLv3 permettant de déchiffrer le contenu. Cette attaque a été nommée POODLE pour Padding Oracle On Downgraded Legacy. Elle est présente uniquement dans SSLv3.

Article détaillé : POODLE.

Spécifications techniques[modifier | modifier le code]

modèle OSI              pile de protocoles                
7 - couche application HTTP, SMTP, FTP, SSH, IRC, SNMP, SIP ...
6 - couche de présentation
5 - couche de session TLS, SSL,SSH-user, NetBIOS
4 - couche de transport TLS, SSL,TCP, UDP, SCTP, RTP, DCCP ...
3 - couche réseau IPv4, IPv6, ARP, IPX ...
2 - couche de liaison Ethernet, 802.11 WiFi, Token ring, FDDI, ...
1 - couche physique Câble, fibre optique, ondes radio...

Dans la pile de protocole TCP/IP, SSL se situe entre la couche application (comme HTTP, FTP, SMTP, etc.) et la couche transport TCP.
Son utilisation la plus commune reste cependant en dessous de HTTP. Le protocole SSL est implémenté par la couche session de la pile, ce qui a deux conséquences :

  • pour toute application existante utilisant TCP, il peut exister une application utilisant SSL. Par exemple, l'application HTTPS correspond à HTTP au-dessus de SSL ;
  • une application SSL se voit attribuer un nouveau numéro de port par l'IANA. Par exemple HTTPS est associé au port 443.
  • dans certains cas, le même port est utilisé avec et sans SSL. Dans ce cas, la connexion est initiée en mode non chiffré. Le tunnel est ensuite mis en place au moyen du mécanisme StartTLS. C'est le cas, par exemple des protocoles de mails IMAP et SMTP ou LDAP

Le chiffrement est réalisé d'une part par un chiffrement asymétrique qui va permettre une authentification, comme l'algorithme RSA ; et, d'autre part, par un chiffrement symétrique, plus léger à réaliser, comme le AES, qui va assurer la transmission des informations. On y adjoint une fonction de hachage, comme le SHA-1, pour s'assurer que les données sont transmises sans être corrompues.

Notes et références[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (en) Eric Rescorla, SSL and TLS, Designing and Building Secure Systems, Addison Wesley, 2001.

Articles connexes[modifier | modifier le code]