Récemment, les gens me demandent toujours si les CDN à haute sécurité supportent HTTPS, cette question m'a fait me gratter la tête - en 2024, il y a encore des gens qui pensent que les CDN à haute sécurité ne font que transporter des DDoS ?
J'ai vu trop d'équipes dans le projet avant le lancement de l'incendie dans la hâte de trouver une solution, la première fois que j'ai entendu parler de CDN haute défense immédiatement associé au “nettoyage du trafic”, “difficile de porter l'attaque”, mais complètement ignoré la partie fatale du cryptage de la transmission. Résultat ? Les attaques sont évitées, mais les données sont nues, volées par l'intermédiaire d'une personne nue qui doit encore porter le chapeau.
Pour vous dire la vérité, aujourd'hui, chez tous les fournisseurs de services CDN haute défense décents, HTTPS n'est plus depuis longtemps un problème de “prise en charge ou non”, mais plutôt un problème de “comment vous permettre d'utiliser plus de fluidité”. Même certains fournisseurs, tels que CDN5 et CDN07, sont en mesure de demander, de déployer et de renouveler automatiquement des certificats SSL, sans que vous ayez à vous soucier de l'aspect du certificat.
Mais il ne faut pas croire que tous les fournisseurs sont au même niveau. J'en ai testé sept ou huit, certains disent qu'ils sont compatibles en surface, mais la configuration réelle peut vous faire vomir trois litres de sang : soit le certificat est téléchargé pour prendre effet aussi lentement qu'un escargot, soit l'interface de configuration est cachée plus profondément qu'un trou noir, et certains ne prennent même pas en charge SNI, la configuration multi-domaine directement dans la rue.
La raison est aussi simple qu'un verre d'eau : vous ne pouvez pas laisser votre maison ouverte parce que vous portez un gilet pare-balles, n'est-ce pas ? La protection DDoS vise à prévenir les impacts violents externes, tandis que HTTPS vise à empêcher l'écoute et la falsification des données, ce qui n'est pas du tout une relation alternative, mais une combinaison en or.
Les sites HTTP sont depuis longtemps marqués comme “non sûrs”, en particulier dans le navigateur Google Chrome. Vous travaillez dur avec un CDN à haute défense pour transporter l'attaque de trafic 500G, les résultats de l'utilisateur d'ouvrir le site pour voir le navigateur de signaler la boîte rouge, tourner autour et aller, cette vague de perte de sang à la fin, qui est responsable ?
J'utilise un CDN à haute défense dans mon environnement de production depuis 2017, et dans les premiers temps, j'ai dû lancer des certificats manuellement : les acheter moi-même, les faire circuler moi-même, garder un œil sur le renouvellement du délai d'expiration, c'était une douleur dans le cul. Mais aujourd'hui ? Oh, l'automatisation a été poussée à un point tel que même le clic d'un bouton est sauvegardé - il suffit de faire correspondre l'enregistrement CNAME dans l'étape de résolution DNS, et le certificat est automatiquement en place.
Par exemple, CDN5, que j'ai aidé le mois dernier à migrer des clients, a fait le vrai test : ajouter un nom de domaine en cochant la case “SSL automatique”, il est directement lié à Let's Encrypt, en 15 minutes pour émettre et déployer automatiquement des certificats, mais aussi vient avec HTTP / 2 et TLS 1.3 de support. Pouvez-vous le croire ? C'est une expérience beaucoup plus confortable que de frotter les certificats à la main sur Nginx moi-même.
CDN07 supporte même les certificats personnalisés + le mode hybride de renouvellement automatique - si vous avez déjà un certificat d'entreprise (tel que DigiCert ou Sectigo), vous pouvez télécharger votre propre clé privée et chaîne de certificats, et en même temps activer le renouvellement automatique, afin d'éviter toute interruption d'activité due à l'expiration du certificat. Ce genre de détails n'est vraiment compris que par les vétérans qui ont mis les pieds dans le plat.
Mais ne croyez pas au battage publicitaire qui consiste à dire que le système est “entièrement automatisé et imbattable”. Les fonctions SSL automatiques de certains petits vendeurs sont à moitié développées, comme la non prise en charge des certificats wildcard, la non prise en charge de la résolution des inondations de noms de domaine à plusieurs niveaux, et même certains ne soumettent même pas les journaux de transparence des certificats (CT), ce qui entraîne le rejet des certificats sur les appareils iOS. Je suis tombé dans ce trou l'année dernière et j'ai été réveillé au milieu de la nuit par un message texte d'alarme, c'était un cauchemar.
Au niveau de la configuration, la plupart des CDN de haut niveau proposent désormais deux modes : les “Edge Certificates” (hébergés et gérés automatiquement par le fournisseur du CDN) et les “Custom Certificates” (que vous téléchargez vous-même). Je recommande vivement l'utilisation des certificats Edge, à moins que vous n'ayez des exigences strictes en matière de conformité - c'est facile, sans effort et gratuit.
Par exemple, supposons que vous utilisiez le CDN haute-défense de 08Host (la résistance aux attaques de ce CC est forte), le processus de configuration est probablement long comme ceci :
C'est fait. Ensuite, 30 jours avant l'expiration du certificat, le système le renouvellera automatiquement, sans que vous ayez à lire l'e-mail de rappel.
Mais si vous avez une tête de fer et que vous devez transmettre le certificat vous-même, ce n'est pas grave. Mais attention : la clé privée doit être au format PEM et doit contenir la chaîne de certificats complète. Beaucoup de gens tombent dans cette étape, passant le certificat mais manquant la chaîne intermédiaire, ce qui entraîne une erreur de certificat sur l'appareil Android.
La commande OpenSSL que j'utilise couramment pour générer la chaîne complète :
Téléchargez ensuite ce fullchain.pem avec la clé privée, en toute sérénité.
Une autre opération sordide est le préchargement HSTS. Si vous utilisez des fournisseurs CDN5 ou CDN07 qui supportent HSTS, il est fortement recommandé de l'activer - il force le navigateur à se connecter à votre domaine uniquement via HTTPS, même le premier saut est sauvegardé, ce qui élimine complètement les attaques par stripping SSL. Cependant, cette étape est une arme à double tranchant, assurez-vous de confirmer que tous les sous-domaines ont été activés via HTTPS avant la configuration, ou verrouillez directement l'accès.
En ce qui concerne les performances, je sais que beaucoup de gens craignent que le cryptage et le décryptage TLS n'augmentent le temps de latence. Mais pour être honnête, les nœuds de périphérie des CDN de haute défense sont maintenant des cartes d'accélération SSL matérielles, cette petite surcharge est presque négligeable. J'ai testé un projet de commerce électronique, l'augmentation de la latence est inférieure à 3 ms après l'ouverture de HTTPS, mais l'amélioration de la sécurité est exponentielle.
Même certains fournisseurs tels que 08Host, mais aussi le ticket de session TLS (ticket de session) multiplexage, le même utilisateur une courte période de temps pour répéter la connexion ne nécessite pas une poignée de main complète, le multiplexage direct de la clé de cache, plus rapide que HTTP (après tout, HTTP/2 multiplexage est également parfumée ah).
Enfin, j'aimerais dire que, de nos jours, même les CDN doivent “prévenir les coéquipiers”. Certains petits fournisseurs sous la bannière de CDN haute défense, en fait, la clé privée SSL existe réellement sur le serveur central, les nœuds périphériques doivent retourner à la source de chaque décryptage pour extraire la clé - ce n'est pas pour enlever leur pantalon pété ? Si vous voulez vraiment faire cela, sans parler de l'explosion des délais, le risque de fuite de clé directement vers le ciel.
Lors du choix d'un fournisseur, il convient donc de s'enquérir de son mécanisme de gestion des clés SSL. Une solution fiable consiste à stocker la clé privée localement dans le nœud périphérique et à la chiffrer en mémoire, voire à prendre en charge la rotation des clés (Key Rotation) comme CDN07, qui change automatiquement la clé privée une fois par trimestre, afin d'éviter les taupes et les infiltrations.
En bref (tsk, je ne peux pas m'empêcher de répéter le mot résumé), le CDN à haute défense et le HTTPS sont depuis longtemps la norme de la norme. Ce dont vous avez besoin, ce n'est pas de la réponse “support ou pas”, mais de l'expérience “comment choisir de ne pas marcher sur la fosse”. Les certificats automatiques peuvent sauver le cœur, mais l'essentiel est de voir la mise en œuvre sous-jacente du fournisseur - sinon la surface est brillante, mais derrière toutes les mines.
La prochaine fois que quelqu'un vous demandera si un CDN de haute sécurité supporte ou non HTTPS, consultez directement cet article : il ne s'agit pas seulement d'un support, mais aussi d'un jeu de fleurs.
