FAQ sur la configuration et l'utilisation de l'accélération HTTPS - CDN

HTTPS est un canal HTTP sécurisé qui offre une meilleure protection pour la transmission du contenu via CDN. Il permet aux clients de parcourir le contenu des sites web de manière plus sûre et efficace, tout en bénéficiant d'un accès rapide. Cette rubrique répond aux questions fréquemment posées sur HTTPS.

Principes et bases de HTTPS

Quels sont les types courants d'attaques HTTP ?

Voici les types d'attaques HTTP les plus courants :

Injection SQL : les attaquants exploitent des applications existantes pour injecter des commandes SQL malveillantes dans les moteurs de base de données backend afin de les exécuter. Ils peuvent également saisir des instructions SQL malveillantes dans des formulaires web pour accéder à la base de données d'un site web présentant des vulnérabilités de sécurité, au lieu d'exécuter les instructions SQL comme prévu par le concepteur.
Script intersite (XSS) : le script intersite (XSS) est l'une des méthodes d'attaque de sites web les plus courantes et les plus basiques. Les attaquants publient des données contenant du code malveillant sur des pages web. Lorsqu'un utilisateur consulte une telle page, le script s'exécute avec l'identité et les autorisations de l'utilisateur naviguant sur le site. Le XSS facilite la falsification des données utilisateur et le vol d'informations.
Usurpation de requête intersite (CSRF) : l'usurpation de requête intersite (CSRF) est une autre attaque courante. Les attaquants forgent des requêtes de diverses manières pour imiter la soumission de formulaires par les utilisateurs, afin de falsifier des données ou d'effectuer des tâches spécifiques. Pour usurper l'identité d'un utilisateur, les attaques CSRF et XSS fonctionnent souvent de concert, mais les attaquants peuvent aussi utiliser d'autres moyens, comme inciter les utilisateurs à cliquer sur un lien malveillant.
Attaque par en-têtes HTTP : lorsque vous utilisez un navigateur pour consulter un site web, le protocole HTTP est toujours impliqué, quelles que soient les technologies et les frameworks utilisés. Dans ce protocole, une ligne vide sépare l'en-tête de réponse du contenu ; elle se compose de deux séries de caractères CRLF (0x0D 0x0A). Cette ligne marque la fin des en-têtes et le début du contenu, une faille que les attaquants peuvent exploiter. Si ces derniers parviennent à injecter des caractères arbitraires dans les en-têtes, l'attaque réussit.
Attaque par redirection : le phishing est une attaque courante. Les auteurs de phishing envoient généralement aux victimes un lien d'apparence légitime. Lorsque les victimes visitent ce lien, elles sont redirigées vers un site web malveillant, ce qui permet aux attaquants de gagner leur confiance et de voler leurs informations. Pour prévenir cela, validez toutes les opérations de redirection afin d'éviter les redirections vers des destinations dangereuses. Une solution courante consiste à utiliser une liste d'autorisation : ajoutez-y les URL de redirection légitimes et rejetez les redirections vers les domaines absents de cette liste. Une autre solution repose sur des jetons de redirection : ajoutez un jeton aux URL légitimes et validez-le lors de la redirection.

L'activation de l'accélération HTTPS consomme-t-elle plus de ressources ou ralentit-elle l'accès ?

Lorsque HTTPS est activé sur l'origine, la consommation de ressources de calcul augmente par rapport à l'accès HTTP. Cette hausse provient principalement du chiffrement et du déchiffrement asymétriques lors de la poignée de main HTTPS, et la consommation de ressources augmente considérablement en cas de forte concurrence. La consommation liée au chiffrement et au déchiffrement symétriques est essentiellement la même que pour HTTP ; il convient donc d'augmenter le taux de réutilisation de session. Toutefois, l'accès direct à l'origine via HTTPS prend plus de temps que l'accès direct via HTTP. Pour le contenu statique, la distribution en périphérie réduit le temps de transmission au prix d'un temps de poignée de main supplémentaire, ce qui diminue le temps d'accès global. De plus, les ressources statiques n'ont pas besoin d'être récupérées depuis l'origine, ce qui réduit les interactions avec celle-ci et abaisse la consommation de ressources sur le serveur d'origine.

Scénarios d'utilisation et décisions concernant HTTPS

HTTPS est-il requis uniquement pour la connexion au site ?

Non. Analysez la situation sous les angles suivants :

Sécurité : si certaines pages sont en HTTP et d'autres en HTTPS, le chargement d'autres ressources (telles que les fichiers JS ou CSS) via HTTP ou par le biais d'un service CDN non sécurisé expose toujours le site web au risque de divulgation des informations utilisateur. L'utilisation de HTTPS sur l'ensemble du site est le moyen le plus simple de prévenir ce risque.
Performance : lorsqu'un site web prend en charge à la fois HTTPS et HTTP, le basculement entre les deux protocoles nécessite de nombreuses redirections côté serveur, ce qui ralentit le chargement des pages lorsque ces redirections sont déclenchées.
Écosystème web : les navigateurs prennent mieux en charge HTTPS, et les moteurs de recherche offrent un meilleur support d'indexation pour les sites HTTPS.

HTTPS est déjà configuré sur l'origine. Dois-je toujours configurer HTTPS sur CDN ?

HTTPS concerne l'interaction entre le client et le serveur. Avant l'utilisation de CDN, le client interagit directement avec l'origine, donc HTTPS doit être configuré sur l'origine. Après l'utilisation de CDN, le client interagit avec CDN. Si vous souhaitez accéder à CDN via HTTPS, vous devez configurer un certificat HTTPS sur CDN. Pour savoir comment configurer un certificat HTTPS sur CDN, consultez Configurer un certificat HTTPS.

Le certificat HTTPS sur l'origine a été mis à jour. Le certificat sur CDN doit-il être mis à jour en conséquence ?

Non. Le certificat HTTPS sur le serveur d'origine et le certificat HTTPS sur CDN sont indépendants. La mise à jour du certificat sur l'origine n'affecte pas le certificat HTTPS sur CDN. Mettez à jour le certificat HTTPS sur CDN uniquement lorsque le certificat configuré sur CDN est sur le point d'expirer ou a déjà expiré. Pour plus d'informations, consultez Configurer un certificat HTTPS.

Le port d'origine change-t-il après la configuration d'un certificat HTTPS ?

La configuration d'un certificat HTTPS pour un nom de domaine accéléré n'affecte pas directement le port d'origine, mais elle l'affecte indirectement en mode de suivi de protocole. Les règles spécifiques sont les suivantes :

1. La configuration d'un certificat HTTPS en soi n'a rien à voir avec le port d'origine

Le certificat HTTPS fournit uniquement le chiffrement entre le client et les nœuds CDN. Il ne modifie ni le protocole d'origine ni le port entre CDN et l'origine. Le comportement de l'origine est contrôlé indépendamment par le paramètre de protocole d'origine : lorsqu'il est défini sur HTTP, CDN récupère le contenu depuis l'origine sur le port 80 par défaut ; lorsqu'il est défini sur HTTPS, CDN récupère le contenu depuis l'origine sur le port 443 par défaut. Cela n'a aucun rapport avec la configuration ou non d'un certificat en périphérie.

2. Lorsque le protocole d'origine est défini sur « suivre », il est affecté par le protocole d'accès du client

Après la configuration d'un certificat HTTPS et l'activation de l'accélération sécurisée HTTPS, CDN prend en charge l'accès via HTTP et HTTPS ;
Si le protocole d'origine est défini pour suivre le client : lorsque le client accède à CDN via HTTP, CDN récupère le contenu depuis l'origine sur le port 80 ; lorsque le client accède à CDN via HTTPS, CDN récupère le contenu depuis l'origine sur le port 443.

3. Si un chiffrement HTTPS de bout en bout est requis

La configuration d'un seul certificat en périphérie ne suffit pas. Définissez également le protocole d'origine sur HTTPS dans les paramètres d'origine, et assurez-vous que l'origine prend en charge l'accès HTTPS.

Pour savoir comment configurer le protocole d'origine, consultez Configurer la politique de protocole d'origine.

Configuration et téléchargement de certificats

Lors du téléchargement d'un certificat tiers contenant plusieurs fichiers .crt, comment télécharger le certificat ?

Les fichiers de certificat émis par une autorité de certification intermédiaire contiennent plusieurs certificats. Concaténez le certificat de serveur et les certificats intermédiaires en un seul certificat complet avant le téléchargement.

Ouvrez tous les fichiers de certificat au format *.PEM avec un éditeur de texte. Placez le certificat de serveur en premier, suivi des certificats intermédiaires. Il ne doit y avoir aucune ligne vide entre les certificats. Dans la plupart des cas, l'autorité de certification fournit des instructions correspondantes lors de l'émission du certificat. Suivez ces instructions.

Le certificat concaténé se présente comme suit.

Comportement d'accès HTTPS et compatibilité

Lors de la configuration de HSTS, après avoir activé l'inclusion des sous-domaines, dois-je activer HSTS sur les sous-domaines ?

Vous n'avez pas besoin d'activer HSTS sur les sous-domaines. Après avoir activé Inclure les sous-domaines, la politique HSTS s'applique à tous les sous-domaines. Assurez-vous que chaque sous-domaine prend en charge un accès HTTPS normal. Sinon, le sous-domaine deviendra inaccessible.

HTTPS est déjà configuré. Pourquoi les clients accèdent-ils toujours au site via HTTP ?

Le fait qu'un client accède au site via HTTP ou HTTPS relève entièrement du comportement du client. Si vous souhaitez forcer les clients à utiliser l'accès HTTPS, activez la redirection HTTPS forcée sur CDN. Pour plus d'informations, consultez Configurer la redirection HTTP/S.

Pourquoi la plupart des appareils peuvent-ils accéder à un nom de domaine accéléré via HTTPS, tandis que certains appareils ne le peuvent pas ?

Cela est principalement dû au fait que CDN s'appuie sur SNI lors du traitement des requêtes HTTPS. SNI est une extension du protocole TLS qui permet à un client de spécifier le nom d'hôte qu'il souhaite visiter lors de l'initiation d'une demande de connexion HTTPS.

Cependant, certains clients plus anciens ou spécialement configurés (par exemple, les anciennes versions d'Android ou d'iOS, Java 6 et versions antérieures, ainsi que certains appareils IoT) peuvent ne pas prendre en charge SNI, ou ne pas envoyer d'informations SNI lors de l'initiation de requêtes HTTPS. Dans ce cas, les nœuds CDN ne peuvent pas déterminer le site exact que le client souhaite visiter et ne peuvent donc pas fournir le certificat SSL/TLS correct. Par conséquent, la tentative de connexion HTTPS échoue et les utilisateurs ne peuvent pas accéder au contenu du site web.

Pour améliorer cette situation, nous recommandons les mesures suivantes :

Mettre à niveau le système client : assurez-vous que les systèmes d'exploitation et les logiciels utilisés sont à jour afin que SNI soit pris en charge.
Mettre à jour le micrologiciel des appareils IoT : pour les appareils IoT, vérifiez régulièrement et installez les dernières mises à jour du micrologiciel fournies par le fabricant.

Facturation HTTPS

Y a-t-il des frais supplémentaires après l'activation de l'accélération HTTPS sur CDN ?

Oui. L'activation de l'accélération HTTPS sur CDN active effectivement HTTPS sur le lien entre le client et les nœuds en périphérie de CDN. Étant donné que la poignée de main SSL et le déchiffrement du contenu nécessitent tous deux des calculs, la consommation de ressources CPU des serveurs CDN augmente. Cependant, la consommation de ressources sur votre serveur d'origine n'augmente pas, car le lien entre les nœuds en périphérie de CDN et votre origine utilise toujours le protocole HTTP et n'ajoute pas de charge supplémentaire à votre origine.

Si vous achetez différents types de certificats, des frais supplémentaires sont applicables. Vous pouvez également vous connecter à la console Certificate Management Service pour demander un certificat de test (édition gratuite), qui est un certificat de niveau DV. Vous pouvez demander un certificat de test pour chaque nom de domaine accéléré. Le certificat est valable trois mois et peut être renouvelé automatiquement gratuitement. Après la configuration d'un certificat HTTPS, CDN facture toutes les requêtes HTTPS pour ce nom de domaine. Pour plus d'informations sur les frais liés aux requêtes HTTPS statiques, consultez Facturation des requêtes HTTPS pour le contenu statique.

Lorsque les requêtes atteignent la liste noire d'IP ou la liste noire User-Agent, ou lorsque les requêtes renvoient 403/404, les requêtes HTTPS sont-elles facturées ?

Les requêtes HTTPS sont facturées. Lorsqu'une requête atteint certaines règles de politique et renvoie un code d'état 403 ou 404, la requête reçoit une réponse correcte, elle est donc comptabilisée comme une requête HTTPS. Comme une telle requête ne transporte aucun contenu de ressource, le trafic facturé est très faible.