Sécurité du CDN

⌚: 8 minutes

Les stratégies de CDN pour atténuer les vulnérabilités comprennent un cryptage SSL/TLS approprié et du matériel de cryptage spécialisé. Découvrez le guide CDN.

Quels sont les risques pour la sécurité d’un CDN ?

Comme tous les réseaux exposés à internet, les CDN doivent se prémunir contre les attaques « man-in-the-middle« , les violations de données et les attaques DDoS. Un CDN peut avoir plusieurs stratégies pour atténuer les vulnérabilités, notamment un cryptage SSL/TLS adéquat et du matériel de cryptage spécialisé.

Qu’est-ce que le cryptage SSL/TLS ?

La couche transport de sécurité (TLS) est un protocole de cryptage des données envoyées sur Internet. Le TLS est issu du Secure Sockets Layer (SSL), le premier protocole de cryptage du web largement adopté, afin de corriger la plupart des failles de sécurité du protocole précédent. Le secteur utilise toujours ces termes de manière quelque peu interchangeable pour des raisons historiques. Tout site web que vous visitez en commençant par https:// plutôt que http:// utilise TLS/SSL pour la communication entre un navigateur et un serveur.

Des pratiques de cryptage appropriées sont nécessaires pour empêcher les mauvais acteurs d’accéder à des données importantes. L’internet étant conçu de telle manière que les données sont transférées à travers de nombreux endroits, il est possible d’intercepter des paquets d’informations importantes lorsqu’ils se déplacent à travers le monde. Grâce à l’utilisation d’une clé de cryptage, seul le destinataire prévu est capable de décoder et de lire les informations et les intermédiaires sont empêchés de décoder le contenu des données transférées.

Le protocole TLS est conçu pour fournir 3 composantes :

1. Authentification – La capacité de vérifier la validité des identifications fournies
2. Chiffrement – Capacité à obscurcir les informations envoyées d’un hôte à un autre
3. Intégrité – La capacité à 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 d’une clé correspondante. Les certificats sont des fichiers contenant des informations sur le propriétaire d’un site et la partie 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 êtes certain que l’autorité de certification a son travail de vérification.

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 non fiable, le navigateur avertit le visiteur que quelque chose pourrait se passer.

Les certificats et la façon dont ils sont mis en œuvre peuvent également être évalués de manière indépendante en fonction de leur solidité, du soutien du protocole et d’autres caractéristiques. Les évaluations peuvent changer avec le temps, à mesure que de nouvelles et meilleures implémentations 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 moindre qualité, il sera généralement moins bien noté et peut être vulnérable aux compromis.

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 en utilisant un certificat fourni par le CDN. Comme 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. D’un point de vue pratique, cette sécurité de serveur à serveur plus faible représente toujours une vulnérabilité et devrait être évitée, surtout compte tenu de la facilité avec laquelle il est possible de mettre à niveau la sécurité d’un serveur d’origine en utilisant le cryptage d’origine gratuit.

Une sécurité adéquate est également importante pour la recherche organique ; des propriétés web cryptées permettent un meilleur classement sur la recherche Google.

Une connexion SSL/TLS fonctionne différemment d’une connexion TCP/IP traditionnelle. Une fois que les étapes initiales de la connexion TCP ont été réalisées, un échange séparé a lieu pour établir la connexion sécurisée. Dans le présent article, le dispositif qui demande la connexion sécurisée est le client et celui qui la sert est le serveur, comme c’est le cas pour un utilisateur qui charge une page web cryptée avec SSL/TLS.

La poignée de main TCP/IP se fait d’abord en 3 étapes :

4. Le client envoie un paquet SYN au serveur afin d’initier la connexion.
5. Le serveur répond alors à ce paquet initial par un paquet SYN/ACK, afin d’accuser réception de la communication.
6. Enfin, le client renvoie un paquet ACK pour accuser réception du paquet en provenance du serveur. Une fois cette séquence d’envoi et de réception de paquets terminée, la connexion TCP est ouverte et peut envoyer et recevoir des données.

Une fois que la poignée de main TCP/IP a eu lieu, la poignée de main de cryptage TLS commence. Les processus détaillés qui sous-tendent la mise en œuvre d’une poignée de main TLS dépassent le cadre de ce guide. Nous nous concentrerons plutôt sur l’objectif principal de la poignée de main et sur le temps nécessaire pour mener à bien le processus.

Une poignée de main TLS se compose de trois éléments principaux :

7. Le client et le serveur négocient les versions TLS et le type de chiffrement cryptographique à utiliser dans la communication.
8. Le client et le serveur prennent des mesures pour assurer une communication mutuellement authentique.
9. Une clé est échangée pour être utilisée dans les futures communications cryptées.

À titre d’exemple, on peut dire que la poignée de main TCP prend environ 50 ms, la poignée de main TLS peut prendre environ 110 ms. Cela est dû 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. La notion de temps aller-retour (RTT), qui correspond au temps nécessaire pour que l’information passe d’un appareil à l’autre et vice-versa, peut être utilisée pour quantifier le « coût » d’une connexion. Si elle n’est pas optimisée et sans l’utilisation d’un CDN, une RTT supplémentaire représente une augmentation de la latence et une réduction du temps de chargement pour les utilisateurs finaux. Heureusement, des optimisations peuvent être faites pour améliorer le temps de charge total et réduire le nombre de trajets aller-retour.

Comment améliorer la latence du SSL ?

Les optimisations SSL peuvent réduire la RTT et améliorer le temps de chargement des pages. Voici 3 des façons dont une connexion TLS peut être optimisée :

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 demandes supplémentaires. Le maintien de la connexion permet d’économiser le temps passé à renégocier la connexion entre le CDN et le serveur d’origine lorsque le client a besoin d’une récupération d’origine non mise en cache. Tant que le serveur d’origine reçoit des demandes supplémentaires pendant que la connexion au CDN est maintenue, les visiteurs supplémentaires du site bénéficieront d’une latence moindre.

Le coût global d’une reprise de session est inférieur à 50 % d’une poignée de main TLS complète, principalement parce que la reprise de session ne coûte qu’un aller-retour alors qu’une poignée de main TLS complète en nécessite deux. En outre, une reprise de session ne nécessite pas de calculs arithmétiques à champ fini (les nouvelles sessions le font), de sorte que le coût du processeur pour le client est presque négligeable par rapport à celui d’une poignée de main TLS complète. Pour les utilisateurs de téléphones portables, l’amélioration des performances par la reprise de session signifie une expérience de navigation beaucoup plus réactive et plus conviviale pour la batterie.

Activer le faux départ TLS – lorsqu’un visiteur consulte le site pour la première fois, la reprise de session mentionnée ci-dessus ne sera pas utile. Le faux départ TLS permet à l’expéditeur d’envoyer les données de la demande sans une poignée de main TLS complète.

Le faux départ ne modifie pas le protocole TLS lui-même, il modifie seulement le moment où les données sont transférées. Une fois que le client commence l’échange de clés, le cryptage peut être assuré et le transfert de données commence. Cette modification réduit le nombre total d’allers-retours, ce qui réduit la latence requise de 60 ms.

Zero Round Trip Time Resumption (0-RTT) – Le 0-RTT permet la reprise de la session sans ajout de latence RTT à la connexion. Pour les connexions reprises à l’aide de TLS 1.3 et 0-RTT, la vitesse de connexion est améliorée, ce qui permet une expérience web plus rapide et plus fluide pour les sites web que les utilisateurs visitent régulièrement. Cette augmentation de la vitesse est particulièrement sensible sur les réseaux mobiles.

L’O-RTT est une amélioration efficace, mais elle ne va pas sans quelques compromis en matière de sécurité. Pour surmonter le risque de ce que l’on appelle une attaque par rediffusion, un service CDN peut mettre en place des restrictions sur le type de requêtes HTTP et les paramètres autorisés.

Capacités du CDN contre les attaques DDoS

L’une des plus importantes vulnérabilités de sécurité des propriétés web sur Internet est l’utilisation des attaques DDoS. Au fil du temps, elles ont augmenté en taille et en complexité, les attaquants utilisant des réseaux de botnets pour cibler les sites web ayant un trafic approprié. Un CDN de grande taille et correctement configuré présente l’avantage potentiel de l’échelle comme facteur de protection contre les DDoS ; en ayant suffisamment d’emplacements de centres de données et des capacités de bande passante importantes, un CDN est capable de résister et d’atténuer une quantité de trafic entrant qui submergerait facilement le serveur d’origine ciblé.