Ce billet fait partie d'une série en 10 volets : #1, #2, #3, #4, #5, #6, #7, #8, #9 et #10.
Notes de lecture de Transport Layer Security (TLS).
Le livre date de 2013 et la partie consacrée à TLS met le focus sur TLS 1.2. Les techniques d'optimisation varient en fonction de la version du protocole. Je ne vais pas reprendre ici les conseils de performance de l'auteur mais plutôt donner une vue d'ensemble de TLS qui permettra d'aller creuser au besoin.
TLS
Le protocole SSL développé à l'origine par Netscape a été normalisé par l'IETF et rebaptisé TLS (Transport Layer Security).
Il vise à chiffrer les données en transit entre un client et un serveur afin d'empêcher l'écoute, l'altération ou la falsification des messages.
Il est mis en œuvre la plupart du temps au-dessus de TCP, ce qui permet aux protocoles situés au-dessus (HTTP, e-mail, messagerie instantanée etc.) de fonctionner sans modifications.
La dernière version du protocole en date est TLS 1.3 (voir l'article de Stéphane Bortzmeyer), elle commence à être bien implémentée et règle des faiblesses des versions précédentes.
Le protocole TLS est subdivisé en 2 sous protocoles :
- le handshake protocol
- le record protocol
Chiffrement, authentification et intégrité
Le protocole TLS est conçu pour fournir trois services essentiels à toutes les applications s'exécutant au-dessus de lui : chiffrement, authentification et intégrité.
Pour établir un canal de transfert de données sécurisé, chaque partie doit s'entendre sur les suites de chiffrement (ciphersuites) qui seront utilisées et les clés utilisées pour chiffrer les données. C'est le rôle du TLS Handshake.
Pendant le TLS Handshake, le protocole permet également aux deux parties d'authentifier leur identité. Ça permet au client de vérifier que le serveur est bien celui qu'il prétend être sur la base d'une chaîne de confiance établie.
Le protocole TLS fournit également son propre mécanisme d'encapsulation et signe chaque message avec un message authentication code (MAC). Chaque fois qu'un message TLS est envoyé, une valeur MAC est générée et jointe, et le destinataire peut vérifier la valeur MAC envoyée pour assurer l'intégrité et l'authenticité d'un message.
Les navigateurs Web prennent en charge une variété de suites de chiffrement, sont capables d'authentifier le client et le serveur, et effectuent de manière transparente le contrôle d'intégrité des messages.
TLS Handshake
TLS utilise une combinaison de techniques de chiffrement : un algorithme de chiffrement asymétrique est utilisé pour établir une session client-serveur sécurisée et un algorithme de chiffrement symétrique est utilisé pour échanger des informations.
Les étapes exactes du TLS handshake varient en fonction de la version du protocole, du type d'algorithme d'échange de clés utilisé et des suites de chiffrement supportées par les deux parties.
Les objectifs du TLS handshake sont :
- de décider de la version du protocole à utiliser (TLS 1.2, 1.3, etc.)
- de décider de la suite de chiffrement à utiliser
- d'authentifier l'identité du serveur grâce à sa clé publique et son certificat
- de générer des clés pour utiliser le chiffrement symétrique pour la session
Pour entrer dans le détail, vous pouvez lire :
- What Happens in a TLS Handshake?
- The Illustrated TLS 1.2 Connection
- The Illustrated TLS 1.3 Connection
Une fois la poignée de main terminée, les données de l'application peuvent être envoyées.
On se retrouve avec encore plus de latence avant de pouvoir échanger des données en https :
- un lookup DNS
- un aller-retour de latence pour le TCP three-way handshake
- deux allers-retours de latence pour le TLS handshake en TLS 1.2 (un seul en TLS 1.3)
Il existe plusieurs techniques plus ou moins bien implémentées pour limiter cette latence, dont l'extension TLS False Start, TLS Session Resumption ou 0-RTT en TLS 1.3.
Server Name Indication (SNI)
SNI est une extension du protocole TLS permettant au client d'indiquer le hostname avec lequel il tente de démarrer une négociation TLS. Le serveur est capable d'inspecter le hostname SNI envoyé, de sélectionner le certificat approprié et de compléter la poignée de main TLS. Le serveur peut avoir plusieurs certificats pour la même adresse IP et peut mutualiser l'hébergement HTTPS.
Certains anciens navigateurs (IE sous Windows XP et Android 2.2 notamment) ne supportent pas SNI. Pour fournir TLS à de tels clients, il faut une adresse IP dédiée par hôte.
Chaîne de confiance et autorités de certification
Si le chiffrement permet des échanges sécurisés, la décision d'approuver ou non une clé publique reste basée sur la confiance.
Tout va bien tant que les deux parties se connaissent et ont pu échanger leurs clés. Ça se complique quand il y a des intermédiaires.
Alice est une amie de Bob. Elle reçoit un message de Charlie, qu'elle n'a jamais rencontré, mais qui prétend être un ami de Bob. Pour prouver qu'il est ami avec Bob, Charlie a demandé à Bob de lui signer sa clé publique. Alice vérifie d'abord la signature de Bob sur la clé de Charlie avant de vérifier celle de Charlie.
Une chaîne de confiance a été établie. La chaîne de confiance fait référence au certificat et à la façon dont il est relié à une autorité de certification de confiance.
Le navigateur suit le même processus et fait confiance aux certificats spécifiés manuellement ou aux autorités de certification racine de confiance dont la liste est intégrée aux systèmes d'exploitation ou aux navigateurs.
Le processus pour devenir autorité de certification racine varie et peut se durcir suite aux fiascos de ces dernières années.
Révocation de certificat
L'émetteur d'un certificat devra parfois le révoquer, par exemple en cas de compromission de la clé privée du certificat ou de l'autorité de certification elle-même.
Les certificats contiennent des instructions sur la façon de vérifier s'ils ont été révoqués, voir :
Record Protocol
Les données échangées pendant une session TLS utilisent le record protocol :
- le record protocol prend les données à transmettre
- les données à transmettre sont fragmentée en blocs
- chaque bloc est authentifié via MAC ou HMAC
- les données dans chaque bloc sont chiffrées en fonction de la suite retenue
Les données chiffrées sont ensuite passée à la couche TCP pour le transport.
La taille des blocs fragmentés est limitée, et cette limite varie en fonction des versions du protocole TLS.
Proxies, intermédiaires, TLS et nouveaux protocoles sur le Web
Le succès d'HTTP a créé un vaste écosystème d'intermédiaires : serveurs de cache, pare-feux etc.
Et ils sont parfois "stupidement" configurés comme diraient certains ce qui pose problème quand on tente de s'écarter du protocole HTTP/1.x de quelque manière que ce soit.
Les protocoles récents comme WebSocket ou HTTP/2 doivent s'appuyer sur un tunnel HTTPS pour contourner ces intermédiaires et fournir un modèle de déploiement fiable : le tunnel obscurcit les données à tous les intermédiaires.
En pratique TLS est le moyen le plus fiable de déployer un nouveau protocole en présence d'un grand nombre d'intermédiaires.
Joint