Dans cet article, nous abordons les principales raisons pour lesquelles TLS impacte les performances de vos services numériques. Commençons par enfoncer des portes ouvertes : la sécurisation de vos applications web doit être l’une de vos principales préoccupations et priorités lors du déploiement de nouveaux services numériques !
C’est évidemment de la plus haute importance pour protéger vos services ainsi que les utilisateurs, mais c’est aussi depuis très longtemps l’un des facteurs de votre score SEO.
Sécuriser un service numérique, c’est :
- assurer la confidentialité des données transmises grâce au cryptage
- vérifier l’identité (potentiellement des deux côtés de la communication) via un process us d’authentification
- assurer l’intégrité des données transmises par des techniques de « hashing »
Le protocole standard utilisé pour fournir ces fonctionnalités est TLS.
Introduction de TLS
TLS (Transport Layer Security) est une évolution du protocole SSL (Secured Socket Layer), initialement développé par Netscape dans les années 90. Voici un résumé de l’évolution de TLS :
| Version du protocole | Date | Standard RFC |
| TLS 1.0 | Janvier 1999 | Première version IETF : RFC 2246 |
| TLS 1.1 | Avril 2006 | RFC 4346 |
| TLS 1.2 | Août 2008 | RFC 5246 |
| TLS 1.3 | Mars 2018 | RFC 8446 |
TLS a été initialement développé sur des protocoles fiables comme TCP, permettant aux protocoles des couches supérieures (HTTP, email, messagerie instantanée, …) de fonctionner en toute sécurité. Ce n’était donc pas destiné à être utilisé uniquement pour les transactions web, mais HTTP est bien sûr l’application la plus connue qui s’appuie dessus.
Sécuriser les transactions web par HTTPS
L’IETF (Internet Engineering Task Force) et l’IAB (Internet Architecture Board) ont publié des conseils aux développeurs et aux concepteurs de protocoles qui encouragent fortement l’adoption de HTTPS.
À partir de HTTP/2, le protocole TLS 1.2 ou supérieur est requis ! Vous ne pourrez donc jamais exécuter HTTP/2 en version HTTP non protégée.
De plus, TLS a également été adapté pour fonctionner sur des protocoles de datagrammes comme UDP. Le protocole DTLS (Datagram Transport Layer Security), défini dans la RFC 6347, est basé sur le protocole TLS. Cela fait de TLS également le protocole de sécurité de choix pour les transactions HTTP/3.
Utilisation de TLS sur HTTP: les défis de performance
Avant que le client et le serveur web puissent commencer à communiquer des données en toute sécurité, ils doivent négocier la manière dont ils sécuriseront la session. Le client et le serveur doivent :
- négocier la version du protocole TLS à utiliser
- choisir la suite de chiffrement
- vérifier les certificats si nécessaire
Tout d’abord, ce processus de négociation ajoute une surcharge CPU des deux côtés de la communication. Heureusement, grâce aux dernières versions TLS optimisées ainsi qu’aux composants matériels modernes, cela n’est plus considéré comme un problème majeur.
Concentrons-nous donc uniquement sur le deuxième facteur de performance, c’est-à-dire le délai supplémentaire introduit par les allers-retours réseau supplémentaires requis…
Comme vous pouvez le voir, un processus de négociation TLS traditionnel nécessite deux allers-retours complets.
Prenant l’exemple d’une communication entre New York et Sydney, le délai supplémentaire introduit sera typiquement compris entre 400 et 600 ms !
Comme vous pouvez l’imaginer, ces allers-retours supplémentaires peuvent vraiment affecter les performances web globales.
Comment minimiser l’impact de performance de TLS
Vous pouvez actionner deux facteurs principaux afin de minimiser l’impact sur les performances de TLS sur vos communications. Vous pouvez:
- améliorer les performances du réseau
- réduire le nombre d’allers-retours nécessaires pour initialiser TLS
Comment améliorer la performance réseau?
Il existe essentiellement deux façons de réduire le temps nécessaire pour envoyer des données d’un point à un autre.
La première consiste à améliorer les performances du réseau lui-même. De toute évidence, la vitesse de la lumière est la limite physique que vous ne pouvez pas dépasser… Mais les composants réseau eux-mêmes influencent d’autres aspects de la transmission réseau, comme le traitement et la sérialisation, ainsi que la mise en file d’attente.
Les réseaux de mauvaise qualité conduisent également souvent à des taux de retransmission de paquets élevés, qui à leur tour affectent les performances du réseau.
La deuxième façon de réduire le délai de transmission des données est d’héberger les ressources numériques au plus près des utilisateurs. Une distance plus petite signifie une latence plus faible. Des techniques telles que la mise en cache des ressources ou l’utilisation de fournisseurs de CDN (Content Delivery Network) doivent être envisagées pour garantir des performances de services numériques appropriées, indépendamment de l’emplacement des utilisateurs.
Comment réduire le nombre d’allers-retours requis?
L’établissement d’une session TLS nécessite généralement 2 allers-retours complets. Et si vous pouviez modifier la structure de ce processus TLS afin de réduire le nombre d’allers-retours ? Eh bien, il existe des techniques pour y parvenir.
Rétablissement de session TLS
Dans le cas où le client a déjà communiqué avec le serveur, il pourra peut-être réutiliser les paramètres déjà négociés pour de nouvelles sessions sécurisées. Dans un tel cas, comme illustré ci-dessous, cela réduit le processus d’établissement TLS à un seul aller-retour.
Technique « False Start »
La technique « False Start » est une extension de protocole TLS qui permet au client et au serveur de commencer à transmettre des données d’application cryptées lorsque la négociation n’est que partiellement terminée.
Dans ce cas, dès que le client envoie la clé de chiffrement au serveur, il n’attend pas la réponse avant de transmettre des données effectives.
La plupart des navigateurs actuels prennent en charge cette technique « False Start », mais ce n’est pas le cas de tous les serveurs.
Perfect Forward Secrecy (PFS)
Pendant des années, le standard RSA a été le mécanisme d’échange de clés dominant dans la plupart des déploiements TLS. Mais RSA présente une faiblesse de sécurité majeure : la même paire de clés publique-privée est utilisée à la fois pour authentifier le serveur et pour chiffrer la clé de session symétrique envoyée au serveur. En revanche, l’échange de clés Diffie-Hellman permet au client et au serveur de négocier un secret partagé sans le communiquer explicitement lors de la prise de contact.
De plus, Diffie-Hellman peut être utilisé pour générer une nouvelle clé symétrique éphémère dans le cadre de chaque échange de clé et supprimer la clé précédente. Ainsi, même si une clé de session est compromise, elle ne peut pas être utilisée pour déchiffrer les sessions précédentes…
« Perfect Forward Secrecy » signifie combiner la technique False Start avec le mécanisme d’échange de clés Diffie-Hellman.
Pourquoi est-ce important du point de vue des performances ? Eh bien, de nombreux navigateurs permettent certaines optimisations de protocole uniquement lorsque PFS est disponible. Un exemple important est le processus d’établissement de session 1-RTT avec TLS False Start. Vous voyez donc à quel point la sécurité et les performances vont parfois de pair.
TLS 1.3
TLS 1.3 a été publié en août 2018 sous RFC 8446.
Par rapport à son homologue TLS 1.2, il introduit de nouvelles fonctionnalités pour améliorer la sécurité ainsi que les performances des communications sécurisées.
Tout d’abord, le processus d’établissement de session TLS 1.3 ne nécessite qu’un aller-retour.
La reprise d’une session TLS est également beaucoup plus rapide avec TLS 1.3 car ce protocole prend en charge la reprise « 0-RTT » ! Cela est dû au fait que TLS 1.3 nécessite Diffie Hellman comme mécanisme d’échange de clés. RSA a été supprimé en raison des problèmes de sécurité mentionnés précédemment. Dans TLS 1.3, un client peut envoyer des données sur le premier message au serveur en exploitant les clés pré-partagées (PSK) de la session précédente, donc 0-RTT.
Importance du monitoring TLS
La sécurisation des communications web par TLS est aujourd’hui incontournable. C’est à ce point vrai que les protocoles les plus récents HTTP/2 et HTTP/3 rendent l’utilisation de TLS obligatoire ! Mais la sécurisation des communications a un impact sur les performances. L’impact ne dépend pas seulement des conditions du réseau (qualité du réseau et distance entre le client et les ressources numériques), mais aussi de la version TLS utilisée car chaque version successive est accompagnée d’améliorations possibles des performances. Et la version TLS utilisée dépend non seulement de la configuration du serveur, mais aussi des capacités des clients (navigateur).
Comme expliqué dans cet article, déployer vos ressources numériques au plus près de vos utilisateurs permet vraiment d’améliorer les performances. Vous y parviendrez généralement en contractant des services d’hébergement avec des fournisseurs de CDN. Mais tous les fournisseurs de CDN n’offrent pas le même niveau de capacités en termes de prise en charge des protocoles HTTP(S) et de fonctionnalités TLS. En d’autres termes, ce que vous gagnez en performance d’un côté peut l’être au détriment de ladite performance de l’autre côté.
Ainsi, lors de la surveillance du temps de négociation TLS et des erreurs relatives potentielles, vous devriez être en mesure de corréler ces données avec les ressources ciblées ainsi que les clients. Voici des exemples de questions auxquelles vous devriez être en mesure de répondre :
- Où se trouvent les ressources numériques (quel fournisseur de CDN, …) ?
- Quel(s) est/sont le(s) protocole(s) HTTP utilisé(s) pour les récupérer ?
- Existe-t-il des problèmes de performances en fonction de l’emplacement des utilisateurs, des appareils utilisés et/ou du navigateur utilisé ?
- Existe-t-il des erreurs spécifiques affectant les utilisateurs ? Pour quelle(s) ressource(s) ? Quelle région du monde ?
La capture d’écran ci-dessous est un exemple concret. L’établissement de la session TCP pour récupérer la ressource correspondante à l’aide de HTTP/2 prend 81 ms, tandis que la sécurisation de la session via TLS prend 288 ms !
TLS a définitivement un impact sur les performances.
Si vous voulez en savoir plus sur la façon dont vous pouvez suivre l’expérience numérique de bout-en-bout des applications modernes, continuez votre lecture ici…
