Dans notre article précédent ‘Quel impact le protocole TLS a-t-il sur la performance ?‘, nous avons spécifiquement abordé l’impact du processus d’établissement de session TLS sur les performances des services numériques. Nous avons également expliqué certaines techniques que vous pouvez utiliser pour minimiser cet impact. comme utiliser « False Start », « Perfect Forward Secrecy » ou utiliser la dernière version de TLS 1.3.
Dans cet article, nous poursuivons notre sujet TLS en examinant des facteurs de performance plus subtils. Nous abordons en particulier l’impact des certificats sur les performances.
Pourquoi utiliser des certificats ?
Dans les communications HTTPS, les certificats permettent aux deux pairs de valider leur identité. Lorsqu’il est utilisé dans le navigateur du client, ce mécanisme d’authentification lui permet de vérifier que le serveur est bien celui qu’il prétend être. Cela permet d’éviter de nombreuses menaces de sécurité Web centrées sur le client. De plus, le serveur peut aussi éventuellement vérifier l’identité du client (lors de l’utilisation d’un proxy par exemple).
Comment fonctionne l’authentification du serveur ?
Voici le principe général de fonctionnement de l’établissement d’une session TLS:
- Le client (navigateur) envoie une requête au serveur, demandant l’accès à un service numérique via HTTPS. Dans le cas où le même serveur (donc une adresse IP unique) héberge différents services correspondant à des certificats distincts, le client peut spécifier le service requis via une extension SSL appelée SNI (Server Name Identifier).
- Le serveur accuse réception de la demande et délivre le certificat du service correspondant pour prouver son identité.
- Le client vérifie l’identité du serveur en demandant à une autorité de certification – CA (Certificate Authority) de valider son certificat.
- Une fois que le client a validé le certificat, il envoie une clé secrète au serveur. Ensuite, les deux pairs chiffrent tous les flux de communication ultérieurs. Bien entendu, le client n’envoie pas la clé secrète en clair. Au lieu de cela, elle est chiffrée avec la clé publique du serveur contenue dans le certificat, de sorte que le serveur est le seul à pouvoir déchiffrer cette clé secrète en utilisant sa clé privée (principe PKI).
La validation de l’identité du serveur nécessite des étapes supplémentaires. Cela explique pourquoi l’utilisation de certificats a un impact sur les performances.
La « chaîne de confiance » – exemple de kadiska.com
Lorsque le navigateur vérifie l’authenticité du certificat du serveur, il le fait en suivant ce qu’on appelle la « chaîne de confiance ». Pour expliquer ce concept, prenons l’exemple de notre site Kadiska.
Lorsque vous naviguez sur https://kadiska.com, notre serveur fournit à votre navigateur son certificat :
Comme vous pouvez le voir, notre certificat de serveur Web a été signé par Let’s Encrypt, qui à son tour a été signé par Digital Signature Trust Co. Chaque navigateur contient par défaut une liste d’autorités de certification de confiance. Dans notre cas, Digital Signature Trust Co est déjà considérée comme une autorité de confiance par le navigateur :
La chaîne de confiance signifie que si le certificat d’un serveur a été signé par un serveur intermédiaire A qui à son tour a été signé par une autorité de certification, cela signifie que vous pouvez faire confiance au serveur intermédiaire A (l’ami de mon ami est aussi mon ami, non ? ).
Tout a l’air super et facile. Mais malheureusement, une question importante demeure : ‘Comment être sûr qu’un certificat authentique est encore valable aujourd’hui ?’ Peut-être que la clé privée du serveur a été compromise et que l’autorité de certification a révoqué le certificat correspondant pour éviter toute menace de sécurité. La liste des certificats validés dans votre navigateur ne sera pas mise à jour par magie !
Ainsi, pour comprendre l’impact sur les performances du processus de vérification de la validité du certificat d’un serveur, approfondissons un peu le processus de vérification de la révocation de certification et les moyens de l’optimiser.
Comment vérifier une révocation de certificat ?
Il existe différentes manières de vérifier si un certificat a été révoqué.
La liste de révocation – Certificate Revocation List (CRL)
Comme son nom l’indique, la CRL est une liste de certificats révoqués. Elle a été définie par la RFC 5280. Chaque autorité de certification maintient et publie périodiquement une liste des numéros de série des certificats révoqués. Quiconque tente de vérifier un certificat peut alors télécharger la liste de révocation, la mettre en cache et vérifier la présence d’un numéro de série particulier à l’intérieur. S’il est présent, il a été révoqué.
Cette façon de vérifier la révocation des certificats est loin d’être optimale. Les principales limites sont :
- La liste de révocation ne fait que s’allonger. Donc sa récupération sera de plus en plus pénible (davantage de données à transférer sur le réseau et à stocker localement). L’utilisation de certificats TLS dans ce cas a donc un impact sur les performances.
- Il n’existe aucun mécanisme pour notifier les navigateurs lorsque la liste est mise à jour. Ainsi, si le navigateur utilise son cache local pour vérifier la validité d’un certificat, vous n’êtes jamais sûr que ce certificat soit toujours valide si la CRL a été récemment mise à jour.
- La nécessité de récupérer la dernière liste CRL de l’autorité de certification peut bloquer la vérification du certificat. Cela peut ajouter une latence importante à la négociation TLS.
Le protocole OCSP (Online Certificate Status Protocol)
Le protocole OCSP a été défini dans la RFC 2560. Il résout la plupart des limitations de la liste de révocation de certificats en permettant une vérification en temps réel du statut auprès d’une autorité de certification pour un certificat spécifique.
Malheureusement, cela introduit également de nouveaux défis.
Du point de vue de la sécurité, ce processus OCSP peut porter atteinte à la confidentialité du client car l’autorité de certification sait sur quels sites le client va surfer.
Mais plus important encore, ce processus peut avoir un impact important sur les performances. Tout d’abord, une requête OCSP est effectuée via une nouvelle connexion TCP. Cela implique un RTT supplémentaire, donc un délai, pour établir cette connexion. Ensuite, le client doit attendre la réponse de l’autorité de certification. En attendant que ce processus soit terminé, le client gèle le processus d’établissement de session TLS, ce qui ajoute des délais. Pire encore, une recherche DNS peut être requise au cas où le client n’aurait pas le nom de domaine complet du CA dans son cache. Encore un retard !
L’agrafage OCSP (« OCSP stapling »)
L’agrafage OCSP a été défini dans la RFC 6066, sous l’extension TLS « Certificate Status Request », ainsi que dans la RFC 5019.
Le principe est assez simple. Au lieu de laisser le client faire la demande de vérification de l’état d’un certificat, le serveur effectue cette vérification pour le client. Le résultat de la validation du certificat est ensuite « agrafé » dans le cadre du premier message de négociation TLS renvoyé au client. Le client doit simplement vérifier la réponse agrafée pour valider le certificat.
Cela résout tous les problèmes soulevés avec le processus OCSP standard (pas de problème de confidentialité du client, pas d’impact sur les performances).
Ouiii ! Nous avons résolu tous les problèmes. Enfin, les certificats TLS n’ont pas d’impact sur les performances… Hmmm, peut-être pas.
La taille du message « Record » TLS
L’équilibre entre surcharge (overhead) et latence
Toutes les données applicatives délivrées via TLS sont transportées dans des messages appelés « records ». Ils définissent un format spécifique qui inclut les données elles-mêmes (maximum 16 Ko par bloc de données), et selon le chiffrement choisi, de 20 à 40 octets de surcharge pour l’en-tête, MAC (Message-Authentication Code) et le remplissage facultatif (pour les chiffrements basés sur des blocs).
- Du point de vue du serveur, des messages plus volumineux signifient une surcharge CPU et d’octets inférieure en raison du formattage des messages et de la vérification MAC.
- Du point de vue du réseau cependant, des enregistrements plus volumineux signifient des tampons TCP plus importants. En cas de dégradations du réseau (perte de paquets par exemple), cela signifie également une latence supplémentaire. En effet, tous les paquets formant un message volumineux devront être livrés et réassemblés par la couche TCP avant d’être traités par la couche TLS et livrés à l’application.
En conclusion, les petits messages entraînent une surcharge, les gros messages entraînent une latence. Il n’y a pas de valeur « optimale » pour la taille de message . Au lieu de cela, la meilleure stratégie consiste à ajuster dynamiquement la taille des messages.
La taille du message « Record » et l’état de connexion TCP
L’un des meilleurs moyens d’optimiser la taille des messages est de prendre en compte l’état de la connexion TCP.
Lorsqu’une nouvelle connexion TCP est établie, la quantité de paquets pouvant être envoyés avant que le récepteur ne doive accuser réception est déterminée par la fenêtre de congestion TCP initiale (CWND). Cette dernière augmente dynamiquement si aucune perte de paquets n’est détectée, de sorte qu’un nombre « optimal » de paquets peut être envoyé à la fois sans acquittement, en fonction des conditions du réseau (bande passante disponible et qualité du réseau). Atteindre la fenêtre de congestion implique d’attendre un ACK, ce qui ajoute du RTT, donc de la latence !
Ainsi, lorsque la connexion est nouvelle et que la fenêtre de congestion TCP est faible, ou lorsque la connexion est inactive depuis un certain temps, la taille du message doit être suffisamment petite pour tenir exactement dans un segment TCP. Lorsque la fenêtre de congestion de la connexion est importante et si nous transférons un flux volumineux (par exemple, une vidéo en continu), la taille du message TLS peut être augmentée pour couvrir plusieurs segments TCP afin de réduire le formattage et la surcharge CPU sur le client et le serveur.
Certains serveurs implémentent un dimensionnement dynamique des messages pour éviter d’encombrer la CWDN. Ils augmentent la taille maximale de message une fois la session établie. D’autres vous permettent de spécifier la taille de message maximale que vous souhaitez autoriser.
La taille du message « Record » et le processus d’établissement TLS
Ainsi, lorsqu’une connexion TCP est établie, s’assurer que les premiers messages TLS ne dépassent pas la CWND initiale garantit les meilleures performances. Alors faisons-le ! Eh bien, même si cela semble évident, la réalité peut être différente.
N’oubliez pas que la négociation TLS suit la négociation TCP. Pendant le processus de négociation TLS, le serveur renvoie la chaîne de certificats de confiance au client. Cette chaîne de confiance doit éviter tout manque. Si l’un des serveurs intermédiaires n’est pas mentionné dans la liste, le navigateur devra le demander via une connexion TCP supplémentaire. Cela entraînera bien sûr une latence supplémentaire !
Prenons un exemple concret :
La profondeur moyenne de la chaîne de certificats est de 2 à 3. La taille moyenne des certificats est d’environ 1 à 1,5 Ko. Cette taille ne prend pas en compte la surcharge de réponse d’agrafage OCSP supplémentaire…
Les systèmes plus anciens peuvent encore avoir une CWND initiale de 4 segments TCP… Fonctionnant sur une infrastructure Ethernet avec un MTU de 1.500 octets, vous voyez à quelle vitesse vous pouvez dépasser cette CWND en envoyant uniquement la chaîne de confiance des certificats, générant ainsi un RTT supplémentaire, donc ajout de latence !
La plupart des systèmes modernes prendront en charge 10 segments TCP en tant que CWND initiale, mais c’est quelque chose à surveiller.
Que retenir?
Aujourd’hui, vous ne pouvez pas vous permettre de déployer des services numériques sans protéger vos ressources ainsi que les utilisateurs qui s’y connectent. TLS est le protocole de choix pour cela. Mais l’utilisation d’éléments tels que les certificats a un impact sur les performances.
Les systèmes modernes peuvent garantir que l’impact sur les performances TLS soit réduit au strict minimum. En plus de l’évolution intrinsèque des performances matérielles, des techniques supplémentaires vous aident à augmenter les performances pour un résultat optimal. Il y en a des évidentes, comme l’utilisation de TLS 1.3 pour réduire le nombre de RTT requis, ou l’adoption de la technique False Start pour envoyer des données le plus rapidement possible. Mais d’autres peuvent avoir un impact négatif sur les performances en ayant des effets secondaires non évidents. La congestion de la CWND initiale en fait partie.
La première étape pour minimiser l’impact sur les performances TLS sur vos services numériques consiste à le mesurer et à corréler les valeurs avec des paramètres tels que le protocole HTTP utilisé. La capture d’écran ci-dessous montre un exemple de performances TLS pour se connecter à un service numérique spécifique. Vous pouvez clairement voir comment l’adoption de HTTP/3 (qui nécessite l’utilisation de TLS 1.3) améliore considérablement les performances globales de TLS par rapport à l’utilisation de HTTP/1.1. Le processus de négociation TLS prend 153 ms en HTTP/3 contre 324 ms en HTTP/1.1.
Pour faire suite à cet article, je vous invite à jeter un œil à nos capacités en termes de suivi des utilisateurs réels ici.
