Protocole SSL/TLS et réseau CDN | Sécurité des réseaux CDN

Les stratégies d'atténuation des vulnérabilités mises en œuvre par les réseaux CDN s'appuient sur un protocole de chiffrement SSL/TLS adéquat et des équipements physiques spécialisés dans ce domaine. Explorez ce guide consacré aux réseaux CDN.

Objectifs d’apprentissage

Cet article s'articule autour des points suivants :

  • Comprendre le fonctionnement du protocole SSL/TLS au sein d'un réseau CDN
  • Explorer les différentes options d'optimisation d'un réseau CDN pour le protocole SSL/TLS
  • Étudier de quelle manière un réseau CDN peut améliorer un certificat SSL/TLS obsolète
  • Découvrir comment un réseau CDN peut contribuer à l'atténuation des attaques DDoS

Copier le lien de l'article

Quels sont les risques de sécurité envers un réseau CDN ?

Comme tous les réseaux exposés à Internet, les réseaux CDN doivent se prémunir contre les attaques de l'homme du milieu, les violations de données et les tentatives de saturation du réseau du serveur d'origine ciblé au moyen d'attaques DDoS. Un réseau CDN peut mettre en œuvre plusieurs stratégies pour atténuer les vulnérabilités, notamment le protocole de chiffrement SSL/TLS approprié et des équipements physiques spécialisés dans le chiffrement.

Qu'est-ce que le chiffrement SSL/TLS ?

Le protocole de chiffrement TLS (Transport Layer Security) permet de chiffrer les données envoyées sur Internet. Issu du SSL (Secure Sockets Layer), le premier protocole de chiffrement web, il a été largement adopté pour corriger la plupart des failles de sécurité du protocole précédent. Pour des raisons historiques, le secteur continuer d'employer ces deux termes de manière quelque peu interchangeable. Tout site web visité dont l'adresse commence par https:// plutôt que par http:// s'appuie sur le protocole TLS/SSL pour ses communications entre le navigateur et le serveur.


L'adoption de bonnes pratiques en matière de chiffrement s'avère nécessaire pour empêcher les acteurs malveillants d'accéder aux données importantes. La conception même d'Internet impliquant que les données transitent par divers points, la possibilité d'intercepter les paquets d'informations importantes lors de leur circulation à travers le monde s'avère très réelle. L'utilisation d'un protocole de chiffrement permet de s'assurer que seul le destinataire prévu est capable de décoder et de lire les informations, tout en empêchant les intermédiaires de décoder le contenu des données transférées.

Le protocole TLS s'articule autour de trois éléments :

  1. Authentification : la possibilité de vérifier la validité des identifications fournies
  2. Chiffrement : la capacité de brouiller les informations envoyées d'un hôte à un autre
  3. Intégrité : la faculté de détecter la falsification et la manipulation

Qu'est-ce qu'un certificat SSL ?

Pour activer le protocole TLS, un site a besoin d'un certificat SSL et d'une clé correspondante. Les certificats sont des fichiers contenant des informations sur le propriétaire d'un site et la moitié publique d'une paire de clés asymétriques. Une autorité de certification (CA) signe numériquement le certificat afin de garantir l'exactitude des informations contenues par ce dernier. En vous fiant au certificat, vous estimez que l'autorité de certification a bien accompli son devoir de vérification préalable et lui accordez votre confiance en la matière.

Graphique représentant une erreur SSL/TLS

Les systèmes d'exploitation et les navigateurs disposent généralement d'une liste d'autorités de certification auxquelles ils font implicitement confiance. Si un site web présente un certificat signé par une autorité de certification ne figurant pas dans cette liste, le navigateur avertit le visiteur du risque qu'il encourt.


Les certificats et la manière dont ils sont mis en œuvre peuvent également être évalués de manière indépendante en fonction de leur force, de leur capacité de prise en charge des protocoles et d'autres caractéristiques. Ces évaluations peuvent évoluer avec le temps, à mesure que de nouvelles améliorations deviennent disponibles ou que d'autres facteurs entraînent une réduction du niveau de sécurité général du modèle de mise en œuvre d'une certification. Un serveur d'origine s'appuyant sur un modèle de sécurité SSL plus ancien et de qualité inférieure se révélera généralement moins bien noté, vulnérable et donc plus susceptible d'être compromis.


Un réseau CDN présente l'avantage supplémentaire d'offrir une sécurité aux visiteurs des propriétés hébergées sur son réseau à l'aide d'un certificat fourni par le CDN. Comme les visiteurs se connectent uniquement au réseau CDN, l'utilisation d'un certificat plus ancien ou moins sécurisé pour la communication entre le serveur d'origine et le réseau CDN n'affectera pas l'expérience du client.

Schéma décrivant le SSL/TLS autosigné

D'un point de vue pratique, ce type de sécurité plus faible entre serveur et périphérie représente toujours une vulnérabilité et devrait être évité, en particulier compte tenu de la facilité de mise à niveau de la sécurité d'un serveur d'origine à l'aide du chiffrement gratuit de l'origine.

Schéma décrivant le SSL/TLS autosigné

Une sécurité appropriée se révèle également importante pour la recherche organique, car le chiffrement des propriétés web améliore le référencement Google.


Une connexion SSL/TLS fonctionne différemment d'une connexion TCP/IP traditionnelle. Une fois les étapes initiales de la connexion TCP effectuées, un échange séparé se produit pour établir la connexion sécurisée. Cet article fera référence à l'appareil demandant la connexion sécurisée sous le nom de « client » et à l'appareil offrant la connexion sécurisée sous le nom de « serveur », comme dans le cas d'un utilisateur chargeant une page web chiffrée à l'aide du protocole SSL/TLS.

La négociation TCP/IP s'effectue tout d'abord, en 3 étapes :

  1. Le client envoie un paquet SYN au serveur afin d'initier la connexion.
  2. Le serveur répond ensuite à ce paquet initial avec un paquet SYN/ACK, afin d'accuser réception de la communication.
  3. Enfin, le client renvoie un paquet ACK pour accuser réception du paquet provenant du serveur. Après avoir terminé cette séquence d'envoi et de réception de paquets, la connexion TCP est ouverte et capable d'envoyer et de recevoir des données.
Schéma de la connexion TCP en trois temps

Une fois la négociation TCP/IP effectuée, la procédure de connexion avec chiffrement TLS commence. Les processus détaillés à l'œuvre lors de l'établissement d'une connexion TLS dépassent le cadre de ce guide. Nous nous concentrerons plutôt sur l'objectif principal de la négociation et le temps requis pour mener à bien ce processus.

D'un point de vue général, la connexion TLS s'effectue en trois étapes principales :

  1. Le client et le serveur négocient les versions TLS et le type de code de chiffrement à utiliser dans la communication.
  2. Le client et le serveur prennent des mesures pour assurer une communication mutuellement authentique.
  3. L'échange d'une clé à utiliser dans les futures communications chiffrées a lieu.

Chacune des étapes impliquées dans les négociations TCP/IP et TLS est représentée de manière visuelle dans le schéma ci-dessous. Gardez à l'esprit que chaque flèche représente une communication distincte qui doit se déplacer physiquement entre le client et le serveur. Comme le nombre total de messages aller-retour augmente lors de l'utilisation du chiffrement TLS, le temps de chargement des pages web s'allonge lui aussi.

Schéma de la négociation SSL/TLS

À titre indicatif, l'établissement d'une connexion TCP demande environ 50 ms, tandis que la négociation TLS peut prendre près de 110 ms. Ces durées résultent en grande partie du temps nécessaire pour envoyer les données dans les deux sens entre le client et le serveur. Le concept de temps aller-retour (RTT), c'est-à-dire le temps nécessaire pour que les informations circulent d'un appareil à un autre et vice-versa, peut être utilisé pour quantifier le « coût » de la création d'une connexion. Si cette durée n'est pas optimisée (et en l'absence d'un réseau CDN), le RTT supplémentaire se concrétise par une augmentation de la latence et un allongement du temps de chargement pour les utilisateurs finaux. Heureusement, un certain nombre d'optimisations peuvent être apportées au processus afin de réduire le temps de chargement total et le nombre de trajets aller-retour.

Comment améliorer la latence SSL ?

Les optimisations SSL peuvent permettre de réduire le RTT et d'améliorer le temps de chargement des pages. Découvrez trois moyens d'optimiser une connexion TLS :


Reprise de session TLS : un réseau CDN peut maintenir une connexion entre le serveur d'origine et le réseau CDN ouverte plus longtemps en reprenant la même session pour les requêtes supplémentaires. Le fait de maintenir la connexion active permet d'économiser le temps passé à renégocier la connexion entre le réseau CDN et le serveur d'origine lorsque le client a besoin de récupérer du contenu non mis en cache auprès du serveur d'origine. Tant que le serveur d'origine reçoit des requêtes supplémentaires pendant la durée de vie de la connexion au réseau CDN, les visiteurs supplémentaires arrivant sur le site connaîtront une latence plus faible.

infographie décrivant la reprise de session en temps réel

Le coût général d'une reprise de session revient à moins de la moitié du coût d'établissement d'une connexion TLS complète, principalement du fait que la reprise de session ne demande qu'un aller-retour, tandis que la négociation TLS complète en requiert deux. De plus, contrairement aux nouvelles sessions, la reprise de session ne nécessite pas de grandes opérations arithmétiques de champ fini. Le coût processeur pour le client se révèle donc pratiquement négligeable par rapport au coût d'une négociation TLS complète. Pour les utilisateurs mobiles, l'amélioration des performances résultant de la reprise de session se traduit par une expérience de navigation beaucoup plus réactive et plus économe en matière d'autonomie de batterie.

infographie décrivant la reprise de session en temps processeur

Activation de la fonctionnalité TLS False Start : lorsqu'un visiteur consulte le site pour la première fois, la procédure de reprise de session mentionnée ci-dessus ne présente aucune utilité. La fonctionnalité TLS False Start (Faux départ) permet à l'expéditeur d'envoyer des données d'application sans devoir réaliser une négociation TLS complète.

Schéma de la négociation SSL/TLS avec False Start

La fonctionnalité False Start ne modifie pas le protocole TLS lui-même, mais uniquement le moment auquel les données sont transférées. Une fois l'échange de clé initié par le client, le chiffrement peut être assuré et le transfert de données commence. Cette modification diminue le nombre total d'allers-retours, en réduisant ainsi la latence requise de 60 ms.


Reprise avec zéro aller-retour (0-RTT)  : l'option 0-RTT permet la reprise de la session sans ajouter de latence RTT à la connexion. La reprise des connexions utilisant le protocole TLS 1.3 et l'option 0-RTT permet d'améliorer la vitesse de connexion, conduisant à une expérience plus rapide et plus fluide sur les sites web que les utilisateurs visitent régulièrement. Ce surplus de vitesse se remarque tout particulièrement sur les réseaux mobiles.


L'option 0-RTT représente une amélioration efficace, mais s'accompagne nécessairement de quelques compromis en matière de sécurité. Afin de surmonter le risque d'attaque connue sous le nom d'« attaque par rejeu », un service CDN peut mettre en place des restrictions au niveau des types de requêtes HTTP et des paramètres autorisés. Pour en savoir plus, consultez l'article de présentation de l'option 0-RTT.

Protection du réseau CDN contre les attaques DDoS

Les attaques par déni de service distribué (DDoS) constituent l'une des failles de sécurité les plus importantes des propriétés web résidant sur l'Internet moderne. Au fil du temps, les attaques DDoS ont augmenté en taille et en complexité, les pirates utilisant de nos jours des botnets pour diriger leur trafic hostile sur les sites web ciblés. Un vaste réseau CDN correctement configuré présente l'avantage potentiel de l'échelle à titre de facteur de protection contre les attaques DDoS. Avec un nombre suffisant d'emplacements de datacenters et une forte capacité en termes de bande passante, un réseau CDN se montrerait tout à fait capable d'encaisser et d'atténuer une quantité de trafic hostile entrant susceptible de surcharger facilement le serveur d'origine visé.


D'autres mesures sont également à votre disposition pour sécuriser une connexion TLS. Apprenez-en davantage sur le réseau CDN Cloudflare et la procédure à suivre pour se tenir informé de l'évolution des attaques TLS en cliquant sur les liens correspondants. Vérifiez comment utiliser le protocole HTTPS de manière appropriée sur votre site web dans le Centre de diagnostic Cloudflare.