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

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 est indispensable pour empêcher les acteurs malveillants d'accéder aux données importantes. La conception même d'Internet implique que les données transitent par une multitude de sites ; la possibilité d'intercepter des paquets d'informations importantes pendant leur acheminement à travers le monde est donc bien réelle. L'utilisation d'un protocole de chiffrement permet d'assurer que seul le destinataire prévu est en mesure 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

En savoir plus sur le protocole SSL/TLS gratuit de Cloudflare.

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.

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.

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.

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.

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.

À 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 évaluer 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 RDC, le RTT supplémentaire se concrétise par une augmentation de la latence et une augmentation 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.

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 (contrairement aux nouvelles sessions). 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.

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.

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 entraîne un certain nombre de compromis en matière de sécurité. Afin de surmonter le risque lié à un type d'attaque appelé « attaque par rejeu », un service de réseau CDN peut mettre en œuvre des restrictions concernant les 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 RDC 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 data centers et une forte capacité en termes de bande passante, un réseau RDC 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.