Récemment, plusieurs amis ont couru aux échecs pour me demander, a dit maintenant DDoS frappé de plus en plus féroce, veulent aller sur la haute défense CDN et se soucier de HTTPS cryptage - après tout, la recharge de jeu, les données de l'utilisateur, les enregistrements de jeu de cartes sont des informations sensibles, la transmission nue est tout simplement une invitation aux pirates de faire la fête. J'ai directement rejeté la conclusion :Les CDN réguliers à haute défense ne prennent pas seulement en charge HTTPS, mais doivent être cryptés tout au long du processus.Mais il y a plus de nids-de-poule que vous ne le pensez.
L'année dernière, notre équipe a pris en charge un projet d'échecs, qui vient de migrer vers un CDN hors de la mite. L'utilisateur recevra occasionnellement un “certificate warning”, une vérification pour trouver le nœud CDN de retour à la source a effectivement utilisé HTTP, des données sensibles dans le dernier lien nu. J'étais tellement en colère que j'étais sur place pour battre la table :De nos jours, même les CDN doivent “prévenir les coéquipiers” !。
Pourquoi les échecs et les cartes doivent-ils utiliser le cryptage HTTPS ? Tout simplement trois points douloureux : premièrement, l'état de connexion de l'utilisateur et les données de transaction est intercepté directement signifie que le carnaval de l'industrie noire ; deuxièmement, l'opérateur renifle les mots-clés de jeu peut directement pincer la ligne ; troisièmement, les boutiques iOS et Android sont maintenant sur la transmission de texte clair de l'audit App directement rejetée. Ne me demandez pas comment je le sais, j'ai payé ma cotisation plusieurs fois.
Après avoir testé trois grands fournisseurs de CDN de haute défense (appelés au hasard CDN5, CDN07, 08Host je crois), la conclusion est la suivante :La prise en charge de HTTPS n'est qu'une opération de base, l'essentiel étant de voir comment réaliser la boucle fermée du lien crypté.Par exemple, dans la configuration par défaut de CDN5, l'utilisateur se rend au nœud CDN via HTTPS, mais le nœud retourne à la source via HTTP. Par exemple, dans la configuration par défaut de CDN5, l'utilisateur se rend au nœud CDN par HTTPS, mais le nœud retourne à la source par HTTP - ce “chiffrement à mi-chemin” est un confort purement psychologique. Plus tard, j'ai retourné le document pour découvrir que pour ouvrir un commutateur séparé “forcer le retour à la source HTTPS”, caché plus profondément que le menu caché du Haidilao.
Nous publions ici une configuration testée et utilisable de Nginx repo pour vous aider à éviter les pièges :
Ne vous contentez pas de quelques lignes, le service client de 08Host m'a dit qu'ils ne supportaient pas le HTTPS vers la source, et qu'ils devaient me laisser passer à la redirection de port TCP. J'ai fait marche arrière sur le test CDN07, les gens non seulement supportent, mais aussi avec son propre certificat pour faire la vérification dans les deux sens - le serveur de jeu n'accepte que les demandes du nœud CDN, chantage veulent forger retour à la porte de paquet de source n'ont pas.
La gestion des certificats est un véritable casse-têteLa première chose à faire est d'obtenir un certificat pour votre clé privée. Certains fournisseurs de CDN vous permettent de télécharger la clé privée du certificat, et les entreprises au grand cœur les détestent directement avec des certificats wildcard. Je recommande fortement :Ne jamais exposer les nœuds de haute défense avec des certificats de type "wildcard".! Une fois qu'un nœud de bordure est infiltré, tous vos sous-domaines peuvent être nus. La pratique courante aujourd'hui est d'émettre des certificats pour les sous-domaines, ou même d'utiliser des certificats à validité courte pour les faire pivoter automatiquement (par exemple Let's Encrypt avec le script acme.sh).
L'année dernière, dans l'architecture que nous avons créée pour le projet Texas Nights, nous avons signé des certificats distincts pour l'utilisateur, l'API de backend et le callback de paiement. Avec la fonction SNI (Server Name Indication) de CDN5, la même IP peut héberger des dizaines de certificats, et le pirate veut vérifier le nom de domaine par le biais du compteur d'IP ? Laissez-le directement douter de sa vie.
La question des performances est également un point de pari. Beaucoup de gens pensent que la poignée de main HTTPS consomme des performances, mais la version moderne de TLS 1.3 a réduit le temps de la poignée de main à moins de 1 RTT. Données de test : CDN07 open TLS 1.3 + échange de clés ECDHE, le délai moyen n'est que de 8 ms supérieur à celui du HTTP, mais la capacité anti-piratage a doublé. En ce qui concerne le chiffrement de la consommation de CPU, nous disposons maintenant d'une carte accélérée matériellement, le QPS 200 000 en dessous du nœud de jeu ne peut pas ressentir les fluctuations.
La manœuvre la plus flamboyante est le “certificate entrapment”.”--Certains petits CDN signent secrètement leurs propres certificats pour vos noms de domaine, ce qui est appelé “optimiser l'expérience”, mais équivaut en réalité à laisser une porte dérobée dans votre canal de données. La méthode de détection est très simple : utilisez openssl s_client pour vous connecter au nœud CDN et voir s'il y a un émetteur inconnu dans la chaîne de certificats. Après l'avoir détecté une fois, nous écrivons directement dans le contrat “interdire la signature du certificat”.
En parlant de configuration pratique, partagez une leçon de sang :Ne vous contentez pas de cliquer sur “Enable HTTPS” dans la console CDN et de penser que tout va bien !. Le lien crypté complet nécessite quatre étapes de vérification :
Enfin, certains fournisseurs annoncent la “prise en charge de HTTPS” comme un argument de vente, mais la configuration par défaut est pleine de vulnérabilités. Si vous voulez vraiment protéger la sécurité des données du conseil d'administration, vous devez vérifier cette liste point par point :
En fin de compte, HTTPS pour les CDN à haute défense n'est pas une question à choix multiple mais une question à réponse obligatoire. Mais le cryptage n'est pas suffisant, il doit être défendu contre tous les aspects comme un jack-in-the-box...Si vous ne cryptez aucun des liens entre le navigateur et le serveur, c'est comme si vous affichiez la combinaison du coffre-fort à la porte du casino.. Désormais, mon équipe active toujours le HTTPS par défaut pour les nouveaux projets, et demande même au fournisseur de CDN de fournir des modèles de configuration avec des scores SSL Labs de A+ ou plus.
Au fait, j'aimerais vous envoyer un œuf à la fin : pendant le test, j'ai découvert que le nœud japonais de 08Host avait installé par erreur un certificat racine auto-signé, ce qui entraînait des alarmes fréquentes sur les appareils iOS. DoncVeillez à analyser l'ensemble du nœud à l'aide d'un outil d'inspection SSL avant de mettre en service le système !Après tout, vos utilisateurs ne vous donneront pas une seconde chance de confiance.
