CDN SSL/TLS | CDN security

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

For illustrative purposes it can be said the TCP handshake takes about 50ms, the TLS handshake may take about 110ms. This is largely a result of the time it takes for data to be sent both ways between the client and server. The idea of round-trip time (RTT), which is the amount of time it takes for information to travel from one device to another and back again, can be used to quantify how “expensive” a connection is to create. If left unoptimized and without the use of a CDN, additional RTT represents an increase in latency and a reduction in load time for end-users. Luckily, there are optimizations that can be made to improve total load time and reduce the number of trips back and forth.

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

The overall cost of a session resumption is less than 50% of a full TLS handshake, mainly because session resumption only costs one round-trip while a full TLS handshake requires two. Additionally, a session resumption does not require any large finite field arithmetic (new sessions do), so the CPU cost for the client is almost negligible compared to that in a full TLS handshake. For mobile users, the performance improvement by session resumption means a much more reactive and battery-life-friendly surfing experience.

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

One of the most substantial security vulnerabilities of web properties on the modern Internet is the use of distributed denial-of-service (DDoS) attacks. Over time DDoS attacks have increased in size and complexity, with attackers utilizing botnets to target websites with attack traffic. A large and properly configured CDN has the potential benefit of scale as a protective factor against DDoS; by having enough data center locations and sizable bandwidth capabilities, a CDN is able to withstand and mitigate an amount of incoming attack traffic that would easily overwhelm the targeted origin server.

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.