Transport Layer Security (TLS)

Introduction

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 a été 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 :

• 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 du client (mais dans la réalité celle-ci est souvent assurée par le serveur).

Le protocole est très largement utilisé, sa mise en œuvre est facilitée par le 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 protocole 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. Un premier brouillon de TLS v1.3 est sorti en 2014.

1. Présentation

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 restait modeste tant que les clients n’avaient 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 clé ou d’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.

2. Protocole SSL

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 troncature1. 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 : SSL 1.0. Cette première spécification du protocole développé par Netscape resta théorique et ne fut jamais mise en œuvre3.
• Février 1995 : publication de la norme SSL 2.0, première version de SSL réellement utilisée. Elle fut également la première implémentation de SSL bannie, en mars 2011 (RFC 6176).
• 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 61014. Le protocole est banni en 2014, à la suite de la publication de la faille POODLE, ce bannissement est définitivement ratifié en juin 2015 (RFC 7568).

3. Protocole TLS

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, 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ée5.

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) : 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 :
• Octobre 1999 (RFC 2712) : Ajout du protocole Kerberos à TLS ;
• Mai 2000 (RFC 2817 et RFC 2818) : Passage à TLS lors d’une session HTTP 1.1 ;
• Juin 2002 (RFC 3268) : Support du système de chiffrement AES par TLS.
• Avril 2006 (RFC 4346) : Publication de la norme TLS 1.1.
• Août 2008 (RFC 5246) : Publication de la norme TLS 1.2.
• Mars 2011 (RFC 6176) : Abandon de la compatibilité avec SSLv2 pour toutes les versions de TLS.
• Avril 2014 : 1er brouillon pour TLS 1.36.
• Juin 2015 (RFC 7568) : Abandon de la compatibilité avec SSLv2 et SSLv3.
• Octobre 2015 : Nouveau brouillon de TLS 1.37

4. Spécifications techniques

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 IMAP, 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 clé 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 chiffrements asymétriques), comme l’AES, qui est utilisé dans la phase d’échange de données, les clés 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).

5. Support par les navigateurs

La plupart des navigateurs web gèrent TLS 1.0. Les navigateurs supportant par défaut la dernière version TLS 1.1 et TLS 1.2 sont :

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

6. Authentification par certificat numérique

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 par un dispositif matériel (carte à puce, token USB). Cette solution permet d’offrir des mécanismes d’authentification forte.

7. Principe de fonctionnement dans les navigateurs web

Lorsqu’un utilisateur se connecte à un site web qui utilise TLS, les étapes suivantes ont lieu :

1. Le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS.
2. Le serveur envoie au client son certificat : celui-ci contient sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact…) ainsi qu’une signature numérique sous forme de texte chiffré.
3. Le navigateur du client tente de déchiffrer la signature numérique du certificat du serveur en utilisant les clés publiques contenues dans les certificats des autorités de certifications (AC) intégrés par défaut dans le navigateur.
4. Si l’une d’entre elles fonctionne, le navigateur web en déduit le nom de l’autorité de certification qui a signé le certificat envoyé par le serveur. Il vérifie que celui-ci n’est pas expiré puis envoie une demande OCSP à cette autorité pour vérifier que le certificat du serveur n’a pas été révoqué.
5. Si aucune d’entre elles ne fonctionne, le navigateur web tente de déchiffrer la signature numérique du certificat du serveur à l’aide de la clé publique contenue dans celui-ci.
   1. En cas de réussite, cela signifie que le serveur web a lui-même signé son certificat. Un message d’avertissement s’affiche alors sur le navigateur web, prévenant l’utilisateur que l’identité du serveur n’a pas été vérifiée par une autorité de certification et qu’il peut donc s’agir potentiellement d’un site frauduleux.
   2. En cas d’échec, le certificat est invalide, la connexion ne peut pas aboutir.
6. Le navigateur du client génère une clé de chiffrement symétrique (à la différence des clés privés et publiques utilisés par les certificats qui sont asymétriques), appelée clé de session, qu’il chiffre à l’aide de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur.
7. Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée.
8. Le client et le serveur commencent à s’échanger des données en chiffrant celles-ci avec la clé de session qu’ils ont en commun. On considère à partir de ce moment que la connexion TLS est alors établie entre le client et le serveur.
9. Une fois la connexion terminée (déconnexion volontaire de l’utilisateur ou si durée d’inactivité trop élevée), le serveur révoque la clé de session.

Optionnel : si le serveur nécessite également que le client s’authentifie, le client lui envoie son propre certificat en même temps que la clé de session. Le serveur procède alors comme détaillé au point n°3 pour vérifier que le certificat du client est valide.

En téléchargeant les livres du Guide Linux vous encouragez son auteur !

8. Letsencrypt

Source : Let’s Encrypt

Source de l’image

https://letsencrypt.org/ (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet.

En septembre 2016, plus de 10 millions de certificats ont été délivrés. En février 2017, Let’s encrypt était utilisé par 13,70% du total des domaines français enregistrés. Le 30 août 2017, Let’s Encrypt dépasse les 50 millions de noms de domaine sécurisés selon PlanetHoster. En avril 2018, Let’s encrypt fournit 51,21 % des certificats TLS. En décembre 2019, Let’s encrypt fournit 54,67 % des certificats TLS. Le 27 février 2020, Let’s Encrypt a annoncé avoir émis un milliard de certificats. En mai 2021, Let’s Encrypt déclare avoir émis 158 millions de certificats actifs (non expirés).

Le projet vise à généraliser l’usage de connexions sécurisées sur l’internet. En supprimant la nécessité de paiement, de la configuration du serveur web, des courriels de validation et de gestion de l’expiration des certificats, le projet est fait pour réduire de manière significative la complexité de la mise en place et de la maintenance du chiffrement TLS. Sur un serveur GNU/Linux, l’exécution de seulement deux commandes est censée être suffisante pour paramétrer le chiffrement HTTPS, l’acquisition et l’installation de certificats, et ceci en quelques dizaines de secondes.

Le protocole défi-réponse utilisé pour automatiser les inscriptions à cette nouvelle autorité de certification est appelé Automated Certificate Management Environment (ACME) (RFC 8555). Les processus de validation sont effectués à de multiples reprises sur des chemins réseaux séparés. La vérification des entrées DNS est réalisée de plusieurs points géographiques afin de rendre les attaques d’usurpation DNS plus difficiles à réaliser. Les interactions de l’ACME sont basées sur l’échange de documents JSON sur des connexions HTTPS. Une ébauche des spécifications est disponible sur GitHub, et une version a été soumise à l’Internet Engineering Task Force comme proposition pour un standard Internet.

Un logiciel de gestion de certificats en Python et sous licence Apache appelé “certbot​” s’installe sur le client (le serveur web d’un inscrit). Ce programme réclame le certificat, effectue le processus de validation de domaine, installe le certificat, configure le chiffrement HTTPS dans le serveur HTTP et dans un second temps, renouvelle le certificat. Après l’installation, l’exécution d’une simple commande suffit à obtenir l’installation d’un certificat valide. Des options additionnelles, comme l’agrafage OCSP ou HTTP Strict Transport Security, peuvent également être activées. Le paramétrage automatique ne s’effectue initialement qu’avec Apache et Nginx, mais d’autres “plug-ins” peuvent être utilisés.