Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisez le protocole HTTPS avec CloudFront
Vous pouvez configurer CloudFront pour obliger les utilisateurs à utiliser le protocole HTTPS afin que les connexions soient chiffrées lors des CloudFront communications avec les spectateurs. Vous pouvez également CloudFront configurer l'utilisation du protocole HTTPS avec votre origine afin que les connexions soient cryptées lorsque CloudFront vous communiquez avec votre origine.
Si vous configurez CloudFront pour exiger le protocole HTTPS à la fois pour communiquer avec les spectateurs et pour communiquer avec votre origine, voici ce qui se passe lorsque CloudFront vous recevez une demande :
1. Un utilisateur envoie une demande HTTPS à CloudFront. Il y a une SSL/TLS négociation ici entre le spectateur et CloudFront. La visionneuse finit par envoyer la requête dans un format chiffré.
1. Si l'emplacement CloudFront périphérique contient une réponse mise en cache, CloudFront chiffre la réponse et la renvoie au visualiseur, qui la déchiffre.
1. Si l'emplacement CloudFront périphérique ne contient pas de réponse mise en cache, CloudFront effectue une négociation SSL/TLS avec votre origine et, une fois la négociation terminée, transmet la demande à votre origine dans un format crypté.
1. Votre origine déchiffre la demande, la traite (génère une réponse), chiffre la réponse et renvoie la réponse à. CloudFront
1. CloudFront déchiffre la réponse, la chiffre à nouveau et la transmet au lecteur. CloudFrontmet également en cache la réponse dans l'emplacement périphérique afin qu'elle soit disponible la prochaine fois qu'elle sera demandée.
1. La visionneuse déchiffre la réponse.
Le processus fonctionne essentiellement de la même manière, MediaStore que votre origine soit un compartiment Amazon S3 ou une origine personnalisée telle qu'un serveur HTTP/S.
**Note**
Pour aider à contrecarrer les attaques de type renégociation SSL, CloudFront ne prend pas en charge la renégociation pour les demandes du destinataire et de l'origine.
Vous pouvez également activer l'authentification mutuelle pour votre CloudFront distribution. Pour de plus amples informations, veuillez consulter [Authentification TLS mutuelle avec CloudFront (Viewer MTLS)Origin Mutual TLS avec CloudFront](mtls-authentication.md).
Pour savoir comment exiger le protocole HTTPS entre les utilisateurs et CloudFront, entre CloudFront et votre origine, consultez les rubriques suivantes.
**Topics**
+ [Exiger le protocole HTTPS entre les spectateurs et CloudFront](using-https-viewers-to-cloudfront.md)
+ [Exigence du protocole HTTPS vers une origine personnalisée](using-https-cloudfront-to-custom-origin.md)
+ [Exigence du protocole HTTPS vers une origine Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Protocoles et chiffrements pris en charge entre CloudFront et l'origine](secure-connections-supported-ciphers-cloudfront-to-origin.md)
# Exiger le protocole HTTPS pour la communication entre les spectateurs et CloudFront
Vous pouvez configurer un ou plusieurs comportements de cache dans votre CloudFront distribution afin d'exiger le protocole HTTPS pour la communication entre les utilisateurs et CloudFront. Vous pouvez également configurer un ou plusieurs comportements de cache pour autoriser à la fois le HTTP et le HTTPS, ce qui CloudFront nécessite le protocole HTTPS pour certains objets mais pas pour d'autres. Les étapes de configuration dépendent du nom de domaine que vous utilisez dans l'objet URLs :
+ Si vous utilisez le nom de domaine CloudFront attribué à votre distribution, tel que d111111abcdef8.cloudfront.net, vous modifiez le paramètre **Viewer Protocol Policy** pour un ou plusieurs comportements de cache afin d'exiger une communication HTTPS. Dans cette configuration, CloudFront fournit le SSL/TLS certificat.
Pour modifier la valeur de **Viewer Protocol Policy** à l'aide de la CloudFront console, reportez-vous à la procédure décrite plus loin dans cette section.
Pour plus d'informations sur l'utilisation de l' CloudFront API pour modifier la valeur de l'`ViewerProtocolPolicy`élément, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
+ Si vous utilisez votre propre nom de domaine, comme example.com, vous devez modifier plusieurs paramètres CloudFront. Vous devez également utiliser un SSL/TLS certificat fourni par AWS Certificate Manager (ACM) ou importer un certificat d'une autorité de certification tierce dans ACM ou dans le magasin de certificats IAM. Pour de plus amples informations, veuillez consulter [Utilisation de noms de domaines alternatifs et HTTPS](using-https-alternate-domain-names.md).
**Note**
Si vous voulez vous assurer que les objets que les spectateurs obtiennent CloudFront étaient chiffrés lorsqu'ils CloudFront sont arrivés de chez vous, utilisez toujours le protocole HTTPS entre CloudFront et votre origine. Si vous êtes récemment passé du protocole HTTP au protocole HTTPS entre CloudFront et votre origine, nous vous recommandons d'invalider les objets situés dans des emplacements CloudFront périphériques. CloudFront renverra un objet à un visualiseur, que le protocole utilisé par le visualiseur (HTTP ou HTTPS) corresponde ou non au protocole CloudFront utilisé pour obtenir l'objet. Pour plus d'informations sur la suppression ou le remplacement des objets dans une distribution, consultez [Ajouter, supprimer ou remplacer du contenu CloudFront diffusé](AddRemoveReplaceObjects.md).
## Exigence du protocole HTTPS pour les utilisateurs
Pour exiger le protocole HTTPS entre les utilisateurs et CloudFront pour un ou plusieurs comportements de cache, effectuez la procédure suivante.
**Pour configurer CloudFront afin d'exiger le protocole HTTPS entre les spectateurs et CloudFront**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.
1. Dans l’onglet **Comportements**, choisissez le comportement de cache à mettre à jour, puis sélectionnez **Modifier**.
1. Spécifiez l’une des valeurs suivantes pour **Politique de protocole d’utilisateur** :
**Redirect HTTP to HTTPS**
Les visionneuses peuvent utiliser les deux protocoles. Le HTTP `GET` et les `HEAD` requêtes sont automatiquement redirigés vers les requêtes HTTPS. CloudFront renvoie le code d'état HTTP 301 (déplacé définitivement) ainsi que la nouvelle URL HTTPS. Le téléspectateur soumet ensuite à nouveau la demande à CloudFront l'aide de l'URL HTTPS.
Si vous envoyez`POST`,`PUT`, `DELETE``OPTIONS`, ou `PATCH` via HTTP avec un comportement de cache HTTP vers HTTPS et une version du protocole de requête HTTP 1.1 ou supérieure, CloudFront redirige la demande vers un emplacement HTTPS avec un code d'état HTTP 307 (redirection temporaire). Cette approche garantit le nouvel envoi de la demande vers le nouvel emplacement à l'aide de la même méthode et de la même charge utile du corps.
Si vous envoyez`POST`, `PUT` `DELETE``OPTIONS`, ou des `PATCH` requêtes via HTTP vers HTTPS, le comportement du cache avec une version du protocole de requête inférieure à HTTP 1.1 CloudFront renvoie un code d'état HTTP 403 (interdit).
Quand un utilisateur émet une requête HTTP redirigée vers une requête HTTPS, CloudFront perçoit des frais pour les deux requêtes. Pour la requête HTTP, les frais concernent uniquement la demande et les en-têtes CloudFront renvoyés au lecteur. Pour la requête HTTPS, le montant correspond à la requête ainsi qu'aux en-têtes et à l'objet renvoyés par votre origine.
**HTTPS Only**
Les visionneuses ne peuvent accéder au contenu que si elles utilisent le protocole HTTPS. Si un utilisateur envoie une requête HTTP au lieu d'une requête HTTPS, il CloudFront renvoie le code d'état HTTP 403 (Interdit) et ne renvoie pas l'objet.
1. Sélectionnez **Enregistrer les modifications**.
1. Répétez les étapes 3 à 5 pour chaque comportement de cache supplémentaire pour lequel vous souhaitez exiger le protocole HTTPS entre les utilisateurs et CloudFront.
1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
+ Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
+ Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Les comportements de cache acheminent les requêtes vers les origines correctes.
# Exigez le protocole HTTPS pour la communication entre CloudFront et votre origine personnalisée
Vous pouvez exiger le protocole HTTPS pour la communication entre CloudFront et votre origine.
**Note**
Si votre origine est un compartiment Amazon S3 configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS avec votre origine, car Amazon S3 ne prend pas en charge le protocole HTTPS pour les points de terminaison de sites Web.
Pour exiger le protocole HTTPS entre CloudFront et votre origine, suivez les procédures décrites dans cette rubrique pour effectuer les opérations suivantes :
1. Dans votre distribution, modifiez le paramètre **Stratégie de protocole d'origine** pour l'origine.
1. Installez un SSL/TLS certificat sur votre serveur d'origine (cela n'est pas obligatoire lorsque vous utilisez une origine Amazon S3 ou certaines autres AWS origines).
**Topics**
+ [Exigence du protocole HTTPS pour les origines personnalisées](#using-https-cloudfront-to-origin-distribution-setting)
+ [Installez un SSL/TLS certificat sur votre origine personnalisée](#using-https-cloudfront-to-origin-certificate)
## Exigence du protocole HTTPS pour les origines personnalisées
La procédure suivante explique comment configurer l'utilisation du protocole HTTPS CloudFront pour communiquer avec un équilibreur de charge Elastic Load Balancing, une instance Amazon EC2 ou une autre origine personnalisée. Pour plus d'informations sur l'utilisation de l' CloudFront API pour mettre à jour une distribution, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
**Pour configurer CloudFront afin d'exiger le protocole HTTPS entre CloudFront et votre origine personnalisée**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.
1. Dans l’onglet **Comportements**, sélectionnez l’origine à mettre à jour, puis choisissez **Modifier**.
1. Modifiez les paramètres suivants :
**Origin Protocol Policy**
Modifiez le paramètre **Stratégie de protocole d'origine** pour les origines concernées de votre distribution :
+ **HTTPS uniquement** : CloudFront utilise uniquement le protocole HTTPS pour communiquer avec votre origine personnalisée.
+ **Match Viewer** : CloudFront communique avec votre origine personnalisée via HTTP ou HTTPS, selon le protocole de la demande du spectateur. Par exemple, si vous choisissez **Match Viewer** for **Origin Protocol Policy** et que le lecteur utilise le protocole HTTPS pour demander un objet CloudFront, il utilise CloudFront également le protocole HTTPS pour transférer la demande à votre source.
Ne sélectionnez **Identique à l’utilisateur** que si vous affectez la valeur **Rediriger HTTP vers HTTPS** ou **HTTPS uniquement** au paramètre **Stratégie de protocole d’utilisateur**.
CloudFront ne met en cache l'objet qu'une seule fois, même si les utilisateurs font des demandes à l'aide des protocoles HTTP et HTTPS.
**Origin SSL Protocols**
Choisissez les **Protocoles SSL d'origine** pour les origines concernées de votre distribution. Le SSLv3 protocole étant moins sécurisé, nous vous recommandons de choisir SSLv3 uniquement si votre origine ne le prend pas en charge TLSv1 ou plus tard. La TLSv1 poignée de main est à la fois rétrocompatible avec la version 1 et les versions ultérieures SSLv3, mais pas avec la version TLSv1 .1 et les versions ultérieures. Lorsque vous le souhaitez SSLv3, envoie CloudFront *uniquement* des demandes de SSLv3 poignée de main.
1. Sélectionnez **Enregistrer les modifications**.
1. Répétez les étapes 3 à 5 pour chaque origine supplémentaire pour laquelle vous souhaitez exiger le protocole HTTPS entre CloudFront et votre origine personnalisée.
1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
+ Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
+ Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Les comportements de cache acheminent les requêtes vers les origines pour lesquelles vous avez modifié le paramètre **Stratégie de protocole d'origine**.
## Installez un SSL/TLS certificat sur votre origine personnalisée
Vous pouvez utiliser un SSL/TLS certificat provenant des sources suivantes sur votre origine personnalisée :
+ Si votre origine est un équilibreur de charge Elastic Load Balancing, vous pouvez utiliser un certificat fourni par AWS Certificate Manager (ACM). Vous pouvez également utiliser un certificat signé par une autorité de certification tierce reconnue et importé dans ACM.
+ Pour les origines autres que les équilibreurs de charge Elastic Load Balancing, vous devez utiliser un certificat signé par une autorité de certification (CA) tierce de confiance, par exemple Comodo ou DigiCert Symantec.
Le certificat renvoyé depuis l'origine doit comprendre l'un des noms de domaine suivants :
+ Le nom de domaine dans le champ du **domaine Origin** de l'origine (le `DomainName` champ de l' CloudFront API).
+ Nom du domaine dans l’en-tête `Host`, si le comportement du cache est configuré pour transférer l'en-tête `Host` de l'origine.
Lorsque CloudFront vous utilisez le protocole HTTPS pour communiquer avec votre origine, CloudFront vérifie que le certificat a été émis par une autorité de certification fiable. CloudFront supporte les mêmes autorités de certification que Mozilla. Pour obtenir la liste actuelle, consultez [Liste des certificats CA inclus dans Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). Vous ne pouvez pas utiliser de certificat auto-signé pour les communications HTTPS entre CloudFront et votre origine.
**Important**
Si le serveur d'origine renvoie un certificat expiré, un certificat non valide ou un certificat auto-signé, ou s'il renvoie la chaîne de certificats dans le mauvais ordre, CloudFront abandonne la connexion TCP, renvoie le code d'état HTTP 502 (Bad Gateway) au visualiseur et définit l'`X-Cache`en-tête sur. `Error from cloudfront` De même, si la chaîne complète de certificats, y compris le certificat intermédiaire, n'est pas présente, CloudFront supprime la connexion TCP.
# Exiger le protocole HTTPS pour la communication entre votre Amazon S3 CloudFront et votre point d'origine
Lorsque votre origine est un compartiment Amazon S3, les options d'utilisation du protocole HTTPS pour les communications avec ce CloudFront dernier dépendent de la manière dont vous utilisez le compartiment. Si votre compartiment Amazon S3 est configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS pour communiquer avec votre origine, car Amazon S3 ne prend pas en charge les connexions HTTPS dans cette configuration.
Lorsque votre origine est un compartiment Amazon S3 qui prend en charge les communications HTTPS, CloudFront transmet les demandes à S3 en utilisant le protocole utilisé par les utilisateurs pour envoyer les demandes. La valeur par défaut du paramètre [Protocole (origines personnalisées uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) est **Identique à l’utilisateur** et elle ne peut pas être modifiée. Toutefois, si vous activez le contrôle d'accès à l'origine (OAC) pour votre origine Amazon S3, la communication utilisée entre Amazon S3 CloudFront et Amazon S3 dépend de vos paramètres. Pour de plus amples informations, veuillez consulter [Création d’un nouveau contrôle d’accès d’origine](private-content-restricting-access-to-s3.md#create-oac-overview-s3).
Si vous souhaitez exiger le protocole HTTPS pour les communications entre Amazon S3 CloudFront et Amazon S3, vous devez modifier la valeur de **Viewer Protocol Policy** pour **rediriger le HTTP vers HTTPS** ou **HTTPS uniquement**. La procédure décrite plus loin dans cette section explique comment utiliser la CloudFront console pour modifier la **politique du protocole Viewer**. Pour plus d'informations sur l'utilisation de l' CloudFront API pour mettre à jour l'`ViewerProtocolPolicy`élément d'une distribution, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
Lorsque vous utilisez le protocole HTTPS avec un compartiment Amazon S3 qui prend en charge la communication HTTPS, Amazon S3 fournit le SSL/TLS certificat, vous n'avez donc pas à le faire.
## Exigence du protocole HTTPS pour une origine Amazon S3
La procédure suivante explique comment configurer CloudFront pour exiger le protocole HTTPS sur votre origine Amazon S3.
**Pour configurer CloudFront afin d'exiger le protocole HTTPS pour votre origine Amazon S3**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.
1. Sous l’onglet **Comportements**, choisissez le comportement de cache à mettre à jour, puis cliquez sur **Modifier**.
1. Spécifiez l’une des valeurs suivantes pour **Politique de protocole d’utilisateur** :
**Redirect HTTP to HTTPS**
Les utilisateurs peuvent utiliser les deux protocoles, mais les requêtes HTTP sont automatiquement redirigées vers les requêtes HTTPS. CloudFront renvoie le code d'état HTTP 301 (déplacé définitivement) ainsi que la nouvelle URL HTTPS. Le téléspectateur soumet ensuite à nouveau la demande à CloudFront l'aide de l'URL HTTPS.
CloudFront ne redirige pas `DELETE``OPTIONS`,`PATCH`,`POST`, ou les `PUT` requêtes de HTTP vers HTTPS. Si vous configurez un comportement de cache pour rediriger vers HTTPS, vous CloudFront répondez au HTTP`DELETE`,`OPTIONS`, `PATCH``POST`, ou aux `PUT` demandes relatives à ce comportement de cache avec le code d'état HTTP 403 (Interdit).
Quand un utilisateur émet une requête HTTP redirigée vers une requête HTTPS, CloudFront perçoit des frais pour les deux requêtes. Pour la requête HTTP, les frais concernent uniquement la demande et les en-têtes CloudFront renvoyés au lecteur. Pour la requête HTTPS, le montant correspond à la requête ainsi qu'aux en-têtes et à l'objet renvoyés par votre origine.
**HTTPS Only**
Les visionneuses ne peuvent accéder au contenu que si elles utilisent le protocole HTTPS. Si un utilisateur envoie une requête HTTP au lieu d'une requête HTTPS, il CloudFront renvoie le code d'état HTTP 403 (Interdit) et ne renvoie pas l'objet.
1. Choisissez **Oui, Modifier**.
1. Répétez les étapes 3 à 5 pour chaque comportement de cache supplémentaire pour lequel vous souhaitez exiger le protocole HTTPS entre les utilisateurs et CloudFront entre CloudFront et S3.
1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
+ Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
+ Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Les comportements de cache acheminent les requêtes vers les origines correctes.
# Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront
Lorsque vous avez [besoin du protocole HTTPS entre les spectateurs et votre CloudFront distribution](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), vous devez choisir une [politique de sécurité](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) qui détermine les paramètres suivants :
+ SSL/TLS Protocole minimal CloudFront utilisé pour communiquer avec les spectateurs.
+ Les chiffrements qui CloudFront peuvent être utilisés pour chiffrer la communication avec les spectateurs.
Pour choisir une stratégie de sécurité, spécifiez la valeur applicable pour [Politique de sécurité ( SSL/TLS version minimale)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). Le tableau suivant répertorie les protocoles et les chiffrements qui CloudFront peuvent être utilisés pour chaque politique de sécurité.
Un utilisateur doit prendre en charge au moins l'un des chiffrements pris en charge pour établir une connexion HTTPS avec. CloudFront CloudFront choisit un chiffre dans l'ordre indiqué parmi les chiffrements pris en charge par le lecteur. Consultez également [Noms de chiffrement OpenSSL, s2n et RFC](#secure-connections-openssl-rfc-cipher-names).
| | Politique de sécurité | | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv11.1\$12016 | TLSv12.2\$12018 | TLSv12.2\$12019 | TLSv12.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| SSL/TLS Protocoles pris en charge |
| TLSv13. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLSv12. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| TLSv11. | ♦ | ♦ | ♦ | ♦ | | | | | |
| TLSv1 | ♦ | ♦ | ♦ | | | | | | |
| SSLv3 | ♦ | | | | | | | | |
| Chiffrements TLSv1 1.3 pris en charge |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | ♦ |
| Chiffrements ECDSA pris en charge |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-ECDSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-ECDSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ | | | | | |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-ECDSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| ECDHE-ECDSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-ECDSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ | | | | | |
| Chiffrements RSA pris en charge |
| ECDHE-RSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-RSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-RSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ | | | | | |
| ECDHE-RSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-RSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| ECDHE-RSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-RSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ | | | | | |
| AES128-GCM- SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES256-GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES256-SHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| AES128-SHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| CBC3DES-SHA | ♦ | ♦ | | | | | | | |
| RC4-MD5 | ♦ | | | | | | | | |
## Noms de chiffrement OpenSSL, s2n et RFC
OpenSSL et [s2n](https://github.com/awslabs/s2n) utilisent des noms de chiffrement différents de ceux utilisés par les standards TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), et [RFC 8446](https://tools.ietf.org/html/rfc8446)). Le tableau suivant met en correspondance les noms OpenSSL et s2n avec le nom RFC pour chaque chiffrement.
CloudFront prend en charge les échanges de clés classiques et quantiques. Pour les échanges de clés classiques utilisant des courbes elliptiques, CloudFront prend en charge les éléments suivants :
+ `prime256v1`
+ `X25519`
+ `secp384r1`
Pour les échanges de clés sécurisés quantiques, prend en CloudFront charge les éléments suivants :
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**Note**
Les échanges de clés sécurisés quantiques ne sont pris en charge qu'avec TLS 1.3. TLS 1.2 et les versions antérieures ne prennent pas en charge les échanges de clés sécurisés quantiques.
Pour plus d’informations, consultez les rubriques suivantes :
+ [Cryptographie post-quantique](https://aws.amazon.com/security/post-quantum-cryptography/)
+ [Algorithmes de cryptographie et Services AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
+ [Échange de clés hybride dans TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)
Pour plus d'informations sur les exigences en matière de certificats pour CloudFront, consultez[Exigences relatives à l'utilisation de SSL/TLS certificats avec CloudFront](cnames-and-https-requirements.md).
| Nom de chiffrement OpenSSL et s2n | Nom de chiffrement RFC |
| --- | --- |
| Chiffrements TLSv1 1.3 pris en charge |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | TLS\$1AES\$1128\$1GCM\$1 SHA256 |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | TLS\$1AES\$1256\$1GCM\$1 SHA384 |
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 |
| Chiffrements ECDSA pris en charge |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-ECDSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 |
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| Chiffrements RSA pris en charge |
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-RSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1RSA\$1AVEC\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 |
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-GCM- SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 |
| AES256-GCM- SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 |
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 |
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| CBC3DES-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA |
| RC4-MD5 | TLS\$1RSA\$1AVEC\$1 \$1128\$1 RC4 MD5 |
## Schémas de signature pris en charge entre les spectateurs et CloudFront
CloudFront prend en charge les schémas de signature suivants pour les connexions entre les spectateurs etCloudFront.
| | Politique de sécurité | Schémas de signature | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv11.1\$12016 | TLSv12.2\$12018 | TLSv12.2\$12019 | TLSv12.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1R1\$1 SECP256 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1R1\$1 SECP384 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA1 | ♦ | ♦ | ♦ | ♦ | | | | | |
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA1 | ♦ | ♦ | ♦ | ♦ | | | | | |
# Protocoles et chiffrements pris en charge entre CloudFront et l'origine
Si vous choisissez d'[exiger le protocole HTTPS entre CloudFront et votre origine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), vous pouvez décider [quel SSL/TLS protocole autoriser](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) la connexion sécurisée, et vous CloudFront pouvez vous connecter à l'origine à l'aide de l'un des chiffrements ECDSA ou RSA répertoriés dans le tableau suivant. Votre origine doit prendre en charge au moins un de ces chiffrements pour CloudFront établir une connexion HTTPS avec votre origine.
OpenSSL et [s2n](https://github.com/awslabs/s2n) utilisent des noms de chiffrement différents de ceux utilisés par les standards TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), et [RFC 8446](https://tools.ietf.org/html/rfc8446)). Le tableau suivant inclut les noms OpenSSL et s2n avec le nom RFC pour chaque chiffrement.
Pour les chiffrements utilisant des algorithmes d'échange de clés à courbe elliptique, CloudFront prend en charge les courbes elliptiques suivantes :
+ prime256v1
+ secp384r1
+ X25519
| Nom de chiffrement OpenSSL et s2n | Nom de chiffrement RFC |
| --- | --- |
| Chiffrements ECDSA pris en charge |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| Chiffrements RSA pris en charge |
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| CBC3DES-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA |
| RC4-MD5 | TLS\$1RSA\$1AVEC\$1 \$1128\$1 RC4 MD5 |
**Schémas de signature pris en charge entre CloudFront et l'origine**
CloudFront prend en charge les schémas de signature suivants pour les connexions entre CloudFront et l'origine.
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA256
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA384
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA512
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA224
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA256
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA384
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA512
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA224
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA1
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA1