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 protocole SSL était développé à l'origine par Netscape. L'IETF, en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.

TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

Le protocole est très largement utilisé, sa mise en œuvre est facilitée du fait que les protocoles de la couche application, comme HTTP, n'ont pas à être profondément modifiés pour utiliser une connexion sécurisée, mais seulement implémentés au-dessus de SSL/TLS, ce qui pour HTTP a donné le protocle HTTPS.

Un groupe de travail spécial de l'IETF a permis la création du TLS et de son équivalent en mode UDP, le DTLS. Depuis qu'il est repris par l'IETF, le protocole TLS a connu trois versions, TLS v1.0 en 1999, TLS v1.1 en 2006 et TLS v1.2 en 2008.

Présentation[modifier | modifier le code]

Au fur et à mesure qu'Internet se développait, de plus en plus de sociétés commerciales se mirent à proposer des achats en ligne pour les particuliers. L'offre se mit à croître régulièrement, mais le chiffre d'affaires dégagé par le commerce électronique resterait modeste tant que les clients n'auraient pas une confiance suffisante dans le paiement par carte bancaire. Une des façons de sécuriser ce paiement fut 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 : 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 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[1]. 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[2] : SSL 1.0. Cette première spécification du protocole développé par Netscape resta théorique et ne fut jamais mise en œuvre[3].
  • 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[4].

Protocole TLS[modifier | modifier le code]

Le protocole TLS n'est pas structurellement différent de la version 3 de SSL, mais des modifications dans l'utilisation des fonctions de hachage font que les deux protocoles ne sont pas directement interopérables. Cependant TLS, comme SSLv3, intègre un mécanisme de compatibilité ascendante avec les versions précédentes, c'est-à-dire qu'au début de la phase de négociation, où le client et le serveur négocient la « meilleure » version du protocole disponible par tous deux. Pour des raisons de sécurité, détaillées dans la RFC 6176 parue en 2011, la compatibilité de TLS avec la version 2 de SSL est abandonnée[5].

La génération des clés symétriques est un peu 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 :
  • Avril 2006 (RFC 4346[11]) : publication de la norme TLS 1.1.
  • Août 2008 (RFC 5246[12]) : publication de la norme TLS 1.2.
  • Mars 2011 (RFC 6176[13]) : abandon de la compatibilité avec SSLv2 pour toutes les versions de TLS

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.

Il existe une extension pour Firefox, maintenue conjointement par le projet Tor et l'EFF depuis 2010[14], qui permet d'étendre l'usage du SSL/TLS sur certains sites. Elle active le SSL sur les pages où ce protocole est normalement désactivé. Ceci ne peut évidemment fonctionner que si le site en question supporte déjà le SSL [15].

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). Des applications web peuvent utiliser 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 fourni pas un dispositif matériel (carte à puce, token USB). Cette solution permet d'offrir des mécanismes d'authentification forte.

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[16],[17],[18], 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

La sécurité est réalisée d'une part par un chiffrement asymétrique, comme le chiffrement RSA, qui permet, après authentification de la clef publique du serveur, la constitution d'un secret partagé entre le client et le serveur, d'autre part par un chiffrement symétrique (beaucoup plus rapide que les chiffres asymétriques), comme l'AES, qui est utilisé dans la phase d'échange de données, les clefs de chiffrement symétrique étant calculées à partir du secret partagé. Une fonction de hachage, comme SHA-1, est également utilisée, entre autres, pour assurer l'intégrité et l'authentification des données (via par exemple HMAC).

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.
  • Olivier Levillain, 2012, SSL/TLS : état des lieux et recommandations, ANSSI 2012, lire en ligne.

Articles connexes[modifier | modifier le code]