CDN SSL / TLS | Sécurité CDN

Les stratégies CDN pour atténuer les vulnérabilités incluent un chiffrement SSL/TLS approprié et du matériel de chiffrement spécialisé. Explorer le guide CDN.

Share facebook icon linkedin icon twitter icon email icon

Sécurité CDN

Objectifs d’apprentissage

Après avoir lu cet article, vous pourrez :

  • Comprendre comment fonctionne le CDN SSL/TLS
  • Explorer les optimisations CDN pour SSL/TLS
  • Voir comment un CDN peut améliorer un certificat SSL/TLS obsolète
  • Apprendre comment un CDN peut aider à atténuer les attaques DDoS

Quels sont les risques de sécurité pour un CDN ?

Comme tous les réseaux exposés à Internet, les CDN doivent se prémunir contre attaques de l'homme au milieu , les atteintes à la protection des données et les tentatives de saturation du réseau du serveur d'origine ciblé à l'aide d'attaques DDoS. Un CDN peut utiliser plusieurs stratégies pour atténuer les vulnérabilités , y compris le chiffrement SSL/TLSapproprié et un matériel de chiffrement spécialisé.

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

Le TLS (Transport Layer Security) est un protocole de chiffrement de données envoyées sur Internet. Le TLS est né du SSL (Secure Sockets Layer), le premier protocole de chiffrement web largement adopté pour corriger la plupart des failles de sécurité du protocole précédent. L'industrie utilise toujours les termes de façon quelque peu interchangeable pour des raisons historiques. Tout site web que vous visitez en commençant par https:// plutôt que http // utilise le TLS/SSL pour la communication entre le navigateur et le serveur.


De bonnes pratiques de chiffrement sont nécessaires pour empêcher les acteurs malveillants d'accéder à des données importantes. Parce que l'Internet est conçu de telle manière que les données transitent à travers de nombreux endroits, il est possible d'intercepter des paquets d'informations importantes lorsqu'ils circulent à travers le monde. Grâce à l'utilisation d'un protocole de chiffrement, seul le bon destinataire est capable de décoder et de lire les informations alors que les intermédiaires ne pourront pas décoder le contenu des données transférées.

Le protocole TLS est conçu pour fournir trois composants :

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

Qu'est-ce qu'un certificat SSL ?

Pour activer le TLS, un site a besoin d' un certificat SSL et 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 pour vérifier que les informations qu'il contient sont correctes. En faisant confiance au certificat, vous vous fiez à l'autorité de certification qui a fait son devoir de diligence raisonnable.

SSL/TLS error graphic

Les systèmes d'exploitation et les navigateurs ont généralement 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 non fiable, le navigateur avertit le visiteur du risque qu'il encourt.


Les certificats et la façon dont ils sont implémentés peuvent également être évalués de manière indépendante en fonction de leur force, de la prise en charge des protocoles et d'autres caractéristiques. Les évaluations peuvent changer avec le temps, à mesure que de nouvelles implémentations améliorées deviennent disponibles ou que d'autres facteurs entraînent une réduction de la sécurité globale d'une implémentation de certification. Si un serveur d'origine possède une ancienne implémentation de sécurité SSL de qualité inférieure, il sera généralement moins bien noté et pourra être vulnérable à la compromission.


Un CDN a l'avantage supplémentaire de fournir 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. Étant donné que les visiteurs se connectent uniquement au CDN, un certificat plus ancien ou moins sécurisé utilisé entre le serveur d'origine et le CDN n'affectera pas l'expérience du client.

SSL/TLS self-signed diagram

D'un point de vue pratique, cette sécurité de serveur à serveur plus faible représente toujours une vulnérabilité et devra être évitée, en particulier compte tenu de la facilité avec laquelle il est possible de mettre à niveau la sécurité d'un serveur d'origine en utilisant le chiffrement gratuit.

SSL/TLS self-signed diagram

Une sécurité appropriée est également importante pour la recherche organique. Les propriétés web chiffrées améliorent le classement de la recherche 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 en tant que client et à l'appareil servant la connexion sécurisée en tant que serveur, comme c'est le cas avec un utilisateur chargeant une page web chiffrée avec le SSL/TLS.

Tout d'abord, le handshake TCP/IP est effectué 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.
TCP 3-way handshake diagram

Une fois la négociation TCP/IP effectuée, le handshake du chiffrement TLS commence. Les processus détaillés qui entrent dans l'implémentation d'un handshake TLS dépassent le cadre de ce guide. Nous nous concentrerons plutôt sur l'objectif principal du handshake et le temps requis pour effectuer le processus.

D'un point de vue général, un handshake TLS se compose de trois composants principaux :

  1. Le client et le serveur négocient les versions TLS et le type de chiffre de chiffrement à utiliser dans la communication.
  2. Le client et le serveur prennent des mesures pour assurer une communication mutuellement authentique.
  3. Une clé est échangée pour être utilisée dans les futures communications chiffrées.

Dans le schéma ci-dessous, chacune des étapes impliquées dans un handshake TCP/IP et un handshake TLS sont représentés. Gardez à l'esprit que chaque flèche représente une communication distincte qui doit se déplacer physiquement entre le client et le serveur. Étant donné que le nombre total de messages dans les deux sens augmente lors de l'utilisation du chiffrement TLS, les temps de chargement de page web s'allongent.

SSL/TLS handshake diagram

À titre indicatif, le handshake TCP prend environ 50 ms, le handshake TLS peut prendre environ 110 ms. Ces durées résultent en grande partie au temps nécessaire pour que les données soient envoyées dans les deux sens entre le client et le serveur. Le 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 ce que « coûte » la création d'une connexion.S'il n'est pas optimisé et sans l'utilisation d'un CDN, un RTT supplémentaire représente 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 afin de réduire le temps de chargement total et le nombre de trajets aller-retour.

Comment améliorer la latence SSL ?

Les optimisations du SSL peuvent réduire le RTT et améliorer le temps de chargement de pages. Voici 3 façons d'optimiser une connexion TLS :


Reprise de session TLS - un CDN peut maintenir une connexion entre le serveur d'origine et le réseau CDN plus longtemps en reprenant la même session pour des requêtes supplémentaires. Le fait de garder la connexion active permet d'économiser le temps passé à renégocier la connexion entre le 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 que la connexion au CDN est maintenue, les visiteurs supplémentaires sur le site connaîtront une latence plus faible.

session resumption real time infographic

Le coût global d'une reprise de session est inférieur à 50 % d'un handshake TLS complet, principalement parce que la reprise de session ne coûte qu'un aller-retour alors qu'un handshake TLS complet en nécessite deux. De plus, une reprise de session ne nécessite pas de grandes opérations arithmétiques de champ fini (ce qui n'est pas le cas des nouvelles sessions), donc le coût CPU pour le client est presque négligeable par rapport à celui d'un handshake TLS complet. Pour les utilisateurs mobiles, l'amélioration des performances grâce à la reprise de session se traduit par une expérience de navigation beaucoup plus réactive et plus économe en batterie.

session resumption CPU time infographic

Activer TLS False Start - lorsqu'un visiteur consulte le site pour la première fois, la reprise de session mentionnée ci-dessus ne sera pas utile. Le TLS False Start permet à l'expéditeur d'envoyer des données d'application sans un handshake TLS complet.

SSL/TLS False Start handshake diagram

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


Reprise avec délai d'aller retour de zéro (0-RTT) - Le 0-RTT permet la reprise de la session sans ajouter de latence RTT à la connexion. Pour la reprise des connexions utilisant TLS 1.3 et 0-RTT, la vitesse de connexion est améliorée, ce qui procure une expérience web plus rapide et plus fluide pour les sites web que les utilisateurs visitent régulièrement. Cette augmentation de vitesse est particulièrement visible sur les réseaux mobiles.


Le 0-RTT est une amélioration efficace, mais qui ne va pas sans quelques compromis en matière de sécurité. Pour surmonter le risque de ce qu'on appelle une attaque de relecture, un service CDN peut implémenter une restriction sur le type de requêtes HTTP et les paramètres autorisés. Pour en savoir plus, consultez une introduction au 0-RTT.

Protection CDN contre les attaques DDoS

L'une des failles de sécurité les plus importantes des propriétés web sur l'Internet moderne est l'utilisation d'attaques par déni de service distribué (DDoS). Au fil du temps, les attaques DDoS ont augmenté en taille et en complexité, avec l'utilisation de botnets pour diriger le trafic d'attaque sur les sites web ciblés. Un vaste CDN correctement configuré présente l'avantage potentiel de l'échelle comme facteur de protection contre les DDoS. En disposant de suffisamment d'emplacements de datacenters et des capacités de bande passante importantes, un CDN est capable de supporter et d'atténuer une quantité de trafic d'attaque entrant qui submergerait facilement le serveur d'origine ciblé.


D'autres mesures peuvent être prises pour sécuriser une connexion TLS. En savoir plus sur le CDN Cloudflare et comment rester au courant des attaques TLS. Consultez votre site web pour une utilisation HTTPS appropriée dans le Centre de diagnostic Cloudflare.