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.
Configuration de SSL/TLS sur Amazon Linux
SSL/TLS (Secure Sockets Layer/Transport Layer Security) crée un canal chiffré entre un serveur web et un client web qui empêche les données en transit d’être écoutées. Ce tutoriel explique comment ajouter manuellement la prise en charge de SSL/TLS sur une instance EC2 avec l’AMI Amazon Linux et le serveur Web Apache. Ce tutoriel suppose que vous n’utilisez pas d’équilibreur de charge. Si vous utilisez Elastic Load Balancing, vous pouvez choisir de configurer le déchargement SSL sur l’équilibreur de charge, en utilisant un certificat à partir de AWS Certificate Manager
Pour des raisons historiques, le chiffrement web est communément appelé SSL. Alors que les navigateurs web prennent toujours en charge SSL, son protocole successeur TLS est moins vulnérable en cas d’attaque. L’AMI Amazon Linux désactive la prise en charge, côté serveur, de toutes les versions de SSL par défaut. Les organismes de normalisation de la sécurité
Ce tutoriel fait référence au chiffrement Web moderne simplement comme TLS.
Important
Ces procédures sont destinées à une utilisation avec l’AMI Amazon Linux. Si vous essayez de configurer un serveur web LAMP sur une instance d’une distribution différente, certaines procédures de ce tutoriel ne fonctionneront peut-être pas pour vous. Pour Amazon Linux 2, veuillez consulter Configurer SSL/TLS sur Amazon Linux 2. Pour Ubuntu, consultez la documentation de la communauté suivante : Open SSL on Ubuntu
Note
Vous pouvez également utiliser AWS Certificate Manager (ACM) for AWS Nitro enclaves, une application d'enclave qui vous permet d'utiliser des certificats SSL/TLS publics et privés avec vos applications Web et vos serveurs exécutés sur des instances Amazon EC2 avec Nitro Enclaves. AWS Nitro Enclaves est une fonctionnalité d’Amazon EC2 qui permet de créer des environnements de calcul isolés pour protéger et traiter en toute sécurité des données très sensibles, telles que des certificats SSL/TLS et des clés privées.
ACM for Nitro Enclaves fonctionne avec nginx exécuté sur votre instance Amazon EC2 Linux pour créer des clés privées, distribuer des certificats et des clés privées et gérer le renouvellement des certificats.
Pour utiliser ACM for Nitro Enclaves, vous devez utiliser une instance Linux compatible avec les enclaves.
Pour plus d'informations, consultez Qu'est-ce que AWS Nitro Enclaves ? et AWS Certificate Manager pour Nitro Enclaves dans le guide de l'utilisateur de AWS Nitro Enclaves.
Table des matières
Prérequis
Avant de commencer ce tutoriel, suivez les étapes suivantes :
-
Lancez une instance basée sur EBS avec l’AMI Amazon Linux. Pour de plus amples informations, veuillez consulter Étape 1 : Lancer une instance.
-
Configurez votre groupe de sécurité afin que votre instance puisse accepter des connexions sur les ports TCP suivants :
-
SSH (port 22)
-
HTTP (port 80)
-
HTTPS (port 443)
Pour de plus amples informations, veuillez consulter Autoriser le trafic entrant pour vos instances Linux.
-
-
Installez le serveur web Apache. Pour step-by-step obtenir des instructions, consultez Tutoriel : Installation d'un serveur Web LAMP sur Amazon Linux. Seuls le package http24 et ses dépendances sont nécessaires. Vous pouvez ignorer les instructions impliquant PHP et MySQL.
-
Pour identifier et authentifier les sites web, l’infrastructure à clés publiques (PKI) TLS repose sur le système de noms de domaine (DNS). Pour utiliser votre instance EC2 pour héberger un site web public, vous devez enregistrer un nom de domaine pour votre serveur web ou transférer un nom de domaine existant vers votre hôte Amazon EC2. Plusieurs services d’enregistrement de domaines tiers et d’hébergement DNS sont disponibles pour cela, ou vous pouvez utiliser Amazon Route 53.
Étape 1 : Activer TLS sur le serveur
Option : Effectuer ce tutoriel en utilisant Automation
Pour terminer ce didacticiel en utilisant AWS Systems Manager au lieu des tâches suivantes, exécutez le document d'automatisation
Cette procédure vous décrit le processus de paramétrage de TLS sur Amazon Linux avec un certificat auto-signé numérique.
Note
Un certificat auto-signé est acceptable dans un environnement de test, mais pas pour les environnements de production. Si vous exposez votre certificat auto-signé sur Internet, les visiteurs de votre site verront s’afficher des messages d’avertissement de sécurité.
Pour activer TLS sur un serveur
-
Connectez-vous à votre instance et confirmez qu’Apache est en cours d’exécution.
[ec2-user ~]$sudo service httpd statusSi nécessaire, démarrez Apache.
[ec2-user ~]$sudo service httpd start -
Pour vous assurer que tous vos packages logiciels sont mis à jour, effectuez une mise à jour logicielle rapide sur votre instance. Ce processus peut prendre quelques minutes, mais il est important pour vous assurer que vous disposez des dernières mises à jour de sécurité et des nouveaux correctifs de bogues.
Note
L’option
-yinstalle les mises à jour sans demander de confirmation. Si vous souhaitez examiner les mises à jour avant l’installation, vous pouvez omettre cette option.[ec2-user ~]$sudo yum update -y -
Maintenant que votre instance est à jour, ajoutez la prise en charge de TLS en installant le module Apache
mod_ssl:[ec2-user ~]$sudo yum install -y mod_sslVotre instance dispose désormais des fichiers suivants que vous utilisez pour configurer votre serveur sécurisé et créer un certificat pour les tests :
/etc/httpd/conf.d/ssl.confLe fichier de configuration de mod_ssl. Il contient des « directives » indiquant à Apache où trouver les clés et les certificats de chiffrement, les versions de protocoles TLS à autoriser et les algorithmes de chiffrement à accepter.
/etc/pki/tls/private/localhost.keyUne clé privée RSA 2048 bits générée automatiquement pour votre hôte Amazon EC2. Pendant l’installation, OpenSSL a utilisé cette clé pour générer un certificat d’hôte auto-signé ; vous pouvez également utiliser cette clé pour générer une demande de signature de certificat (CSR) à envoyer à une autorité de certification (CA).
/etc/pki/tls/certs/localhost.crtUn certificat X.509 auto-signé généré automatiquement pour votre serveur hôte. Ce certificat est utile pour vérifier qu’Apache est correctement paramétré pour utiliser TLS.
Les fichiers
.keyet.crtsont au format PEM qui est constitué de caractères ASCII codés en Base64, encadrés par des lignes « BEGIN » et « END », comme dans cet exemple abrégé d’un certificat :-----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----Les noms et extensions de fichier sont fournis à des fins de commodité et n’ont aucun effet sur la fonction ; vous pouvez appeler un certificat
cert.crt,cert.pemou tout autre nom de fichier dans la mesure où la directive associée dans le fichierssl.confutilise le même nom.Note
Lorsque vous remplacez les fichiers TLS par défaut par vos propres fichiers personnalisés, veillez à ce qu’ils soient au format PEM.
-
Redémarrez Apache.
[ec2-user ~]$sudo service httpd restart -
Votre serveur web Apache devrait maintenant prendre en charge HTTPS (HTTP sécurisé) sur le port 443. Testez-le en tapant l’adresse IP ou le nom de domaine complet de votre instance EC2 dans une barre URL du navigateur avec le préfixe
https://. Étant donné que vous vous connectez à un site avec un certificat d’hôte auto-signé non approuvé, il se peut que votre navigateur affiche une série d’avertissements de sécurité.Ignorez-les et poursuivez sur le site. Si la page de test Apache par défaut s’ouvre, cela signifie que vous avez configuré correctement TLS sur votre serveur. Toutes les données transmises entre le navigateur et le serveur sont maintenant chiffrées en toute sécurité.
Pour éviter aux visiteurs du site d’avoir des avertissements, vous devez obtenir un certificat qui chiffre mais vous authentifie aussi publiquement comme le propriétaire du site.
Étape 2 : Obtenir un certificat signé par une autorité de certification (CA)
Vous pouvez utiliser le processus suivant pour obtenir un certificat signé par une CA :
-
Générez une demande de signature de certificat (CSR) à partir d’une clé privée
-
Envoyez la demande de signature de certificat (CSR) à une autorité de certification (CA)
-
Obtenez un certificat d’hôte signé
-
Configurez Apache pour utiliser le certificat
Le chiffrement d’un certificat X.509 TLS auto-signé est identique à celui d’un certificat signé par une autorité de certification. La différence est sociale, pas mathématique. Une autorité de certification promet de valider au minimum la propriété d’un domaine avant de générer un certificat pour un demandeur. Chaque navigateur web contient une liste d’autorités de certification approuvées par le fournisseur de navigateur pour faire cela. Un certificat X.509 se compose surtout d’une clé publique qui correspond à votre clé de serveur privée et d’une signature de l’autorité de certification qui est cryptographiquement reliée à la clé publique. Lorsqu’un navigateur se connecte à un serveur web sur HTTPS, le serveur présente un certificat que le navigateur doit vérifier par rapport à sa liste d’autorités de certification approuvées. Si le signataire est sur la liste ou s’il est accessible via une chaîne de confiance composée d’autres utilisateurs de confiance, le navigateur négocie un canal de données chiffrées rapide avec le serveur et charge la page.
Les certificats coûtent généralement de l’argent à cause travail impliqué dans la validation des requêtes, donc il est intéressant de comparer les prix. Quelques autorités de certification offrent des certificats basiques gratuits. La plus importante autorité de certification est le projet Let’s Encrypt
Si vous prévoyez d’offrir des services de qualité commerciale, AWS Certificate Manager est une bonne option.
La clé est l’élément sous-jacent du certificat d’hôte. Depuis 2017, des groupes gouvernementaux
Ces instructions pour l’acquisition de certificats d’hôte signés par l’autorité de certification (CA) ne fonctionnent pas à moins que vous possédiez un domaine DNS enregistré et hébergé.
Pour obtenir un certificat signé par une CA
-
Connectez-vous à votre instance et accédez à /etc/pki/tls/private/. Il s’agit du répertoire où la clé privée du serveur de SSL/TLS est stockée. Si vous préférez utiliser votre clé d’hôte existante pour générez la CSR, passez à l’étape 3.
-
(Facultatif) Générez une nouvelle clé privée. Voici quelques exemples de configurations de clés. Toutes les clés obtenues fonctionnent avec votre serveur web, mais elles diffèrent dans leur façon de mettre en œuvre la sécurité (et en ce qui concerne le niveau de sécurité assuré).
-
Exemple 1 : création d’une clé d’hôte RSA par défaut. Le fichier obtenu,
custom.key, est une clé privée RSA 2048 bits.[ec2-user ~]$sudo openssl genrsa -out custom.key -
Exemple 2 : création d’une clé RSA plus forte avec un modulus plus grand. Le fichier obtenu,
custom.key, est une clé privée RSA 4096 bits.[ec2-user ~]$sudo openssl genrsa -out custom.key 4096 -
Exemple 3 : création d’une clé RSA chiffrée 4096 bits avec protection par mot de passe. Le fichier obtenu,
custom.key, est une clé privée RSA 4096 bits chiffrée avec le chiffrement AES-128.Important
Le chiffrement de la clé offre une plus grande sécurité, mais comme une clé chiffrée nécessite un mot de passe, les services qui en dépendent ne peuvent pas démarrer automatiquement. A chaque fois que vous utilisez cette clé, vous devez fournir le mot de passe (« abcde12345 » dans l’exemple précédent) sur une connexion SSH.
[ec2-user ~]$sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096 -
Exemple 4 : création d’une clé avec un chiffrement non RSA. La cryptographie RSA peut être relativement lente en raison de la taille de ses clés publiques, lesquelles sont basées sur le produit de deux grands nombres premiers. Cependant, il est possible de créer des clés pour TLS qui utilisent des chiffrements non RSA. Les clés basées sur les mathématiques des courbes elliptiques sont plus petites et plus rapides en termes de calcul, tout en offrant un niveau de sécurité équivalent.
[ec2-user ~]$sudo openssl ecparam -name prime256v1 -out custom.key -genkeyLe résultat est une clé privée 256 bits à courbes elliptiques utilisant prime256v1, une « courbe nommée » que OpenSSL prend en charge. Sa qualité cryptographique est légèrement plus importante qu’une clé RSA 2048 bits, selon NIST
. Note
Toutes les autorités de certification ne fournissent pas le même niveau de support pour elliptic-curve-based les clés que pour les clés RSA.
Assurez-vous que la nouvelle clé privée possède un critère de propriété et d’autorisations très restrictif (propriétaire=racine, groupe=racine, lecture/écriture pour propriétaire uniquement). Les commandes seraient les suivantes :
[ec2-user ~]$sudo chown root.root custom.key[ec2-user ~]$sudo chmod 600 custom.key[ec2-user ~]$ls -al custom.keyLes commandes ci-dessus devraient générer le résultat suivant :
-rw------- root root custom.keyUne fois que vous avez créé et configuré une clé satisfaisante, vous pouvez créer une CSR.
-
-
Créez une CSR à l’aide de votre clé préférée. L’exemple ci-dessous utilise
custom.key:[ec2-user ~]$sudo openssl req -new -key custom.key -out csr.pemOpenSSL ouvre une boîte de dialogue et vous invite à compléter les informations affichées dans le tableau ci-dessous. Tous les champs à l’exception de Common Name sont facultatifs pour un certificat d’hôte basique avec validation de domaine.
Nom Description Exemple Nom du pays Abréviation ISO de deux lettres de votre pays. US (=Etats-Unis) Nom de l’état ou de la province Nom de l’état ou de la province où votre organisation se situe. Ce nom ne peut pas être abrégé. Washington Nom de la localité L’emplacement de votre organisation, comme une ville. Seattle Nom de l’organisation Nom légal complet de votre organisation. N’abrégez pas le nom de votre organisation. Exemple d’entreprise Nom de l’unité d’organisation Informations supplémentaires sur l’organisation, s’il y en a. Exemple de service Nom commun Cette valeur doit exactement correspondre à l’adresse web que les utilisateurs taperont dans un navigateur, selon vous. Il s’agit généralement d’un nom de domaine avec un nom d’hôte ou un alias préfixé sous la forme
www.example.com. Dans les essais avec un certificat auto-signé et aucune résolution DNS, le nom commun peut se composer uniquement du nom d’hôte. Les autorités de certification proposent aussi des certificats onéreux qui acceptent les noms inconnus comme*.example.com.www.exemple.com Adresse e-mail L’adresse e-mail de l’administrateur du serveur. quelquun@exemple.com Au final, OpenSSL vous invite à donner un mot de passe de stimulation facultatif. Ce mot de passe s’applique uniquement à la CSR et aux transactions entre vous et votre autorité de certification, donc suivez les recommandations de l’autorité de certification sur cela, l’autre champ facultatif et le nom de l’entreprise facultatif. Le mot de passe de stimulation de la CSR n’a aucun effet sur le fonctionnement du serveur.
Le fichier obtenu
csr.pemcontient votre clé publique, la signature numérique de votre clé publique et les métadonnées que vous avez saisies. -
Envoyez la CSR à une autorité de certification. Elle consiste généralement en l’ouverture de votre fichier CSR dans un éditeur de texte et la reproduction du contenu dans un formulaire web. A ce moment-là, il se peut que l’on vous demande de fournir un SAN (subject alternate name) ou plus à placer sur le certificat. Si
www.example.comest le nom commun,example.comserait un bon SAN, et vice versa. Un visiteur de votre site qui tape l’un de ces noms devrait bénéficier d’une connexion sans erreur. Si le formulaire web de votre autorité de certification le permet, incluez le nom commun dans la liste des SAN. Certaines autorités de certification l’incluent automatiquement.Une fois que votre demande a été approuvée, vous recevrez un nouveau certificat d’hôte signé par l’autorité de certification. Il se peut que l’on vous demande également de télécharger un fichier de certificat intermédiaire qui contient des certificats supplémentaires nécessaires pour compléter la chaîne de confiance de l’autorité de certification.
Note
Votre autorité de certification peut vous envoyer des fichiers sous différents formats en fonction des finalités recherchées. Dans ce tutoriel, vous devez utiliser uniquement un fichier de certificat au format PEM qui comporte habituellement (mais pas toujours) une extension
.pemou.crt. Si vous ne savez pas quel fichier utiliser, ouvrez les fichiers dans un éditeur de texte et recherchez celui qui contient un ou plusieurs blocs commençant par :- - - - -BEGIN CERTIFICATE - - - - -Le fichier doit également se terminer par :
- - - -END CERTIFICATE - - - - -Vous pouvez également tester un fichier dans la ligne de commande, comme suit :
[ec2-user certs]$openssl x509 -incertificate.crt-textVérifiez que ces lignes apparaissent dans le fichier. N’utilisez pas de fichiers se terminant par
.p7b,.p7cou autres extensions similaires. -
Placez le nouveau certificat signé par une CA et les certificats intermédiaires dans le répertoire
/etc/pki/tls/certs.Note
Il existe plusieurs méthodes pour charger votre clé personnalisée dans votre instance EC2, mais le moyen le plus simple et informatif consiste à ouvrir un éditeur de texte (vi, nano, Bloc-notes, etc.) sur votre ordinateur local et votre instance, puis à copier et coller le contenu du fichier. Pour effectuer ces opérations sur l’instance EC2, vous devez disposer de privilèges racine [sudo]. Vous voyez ainsi immédiatement s’il existe des problèmes d’autorisation ou de chemin d’accès. Veillez toutefois à ne pas d’ajouter des lignes supplémentaires lors de la copie du contenu, ou à les modifier de quelque façon.
À partir du répertoire
/etc/pki/tls/certs, utilisez les commandes suivantes pour vérifier que les paramètres de propriété du fichier, de groupe et d’autorisation correspondent aux valeurs par défaut Amazon Linux très restrictives (propriétaire=racine, groupe=racine, lecture/écriture pour propriétaire uniquement).[ec2-user certs]$sudo chown root.root custom.crt[ec2-user certs]$sudo chmod 600 custom.crt[ec2-user certs]$ls -al custom.crtLes commandes ci-dessus devraient générer le résultat suivant :
-rw------- root root custom.crtLes autorisations pour le fichier de certificat intermédiaire sont moins contraignantes (propriétaire=racine, groupe=racine, le propriétaire peut écrire, le groupe peut lire, tout le monde peut lire). Les commandes seraient :
[ec2-user certs]$sudo chown root.root intermediate.crt[ec2-user certs]$sudo chmod 644 intermediate.crt[ec2-user certs]$ls -al intermediate.crtLes commandes ci-dessus devraient générer le résultat suivant :
-rw-r--r-- root root intermediate.crt -
Si vous avez utilisé une clé personnalisée pour créer votre CSR et le certificat d’hôte correspondant, supprimez ou renommez l’ancienne clé du répertoire
/etc/pki/tls/private/, puis ajoutez-lui la nouvelle clé.Note
Il existe plusieurs méthodes pour charger votre clé personnalisée dans votre instance EC2, mais le moyen le plus simple et informatif consiste à ouvrir un éditeur de texte (vi, nano, Bloc-notes, etc.) sur votre ordinateur local et votre instance, puis à copier et coller le contenu du fichier. Pour effectuer ces opérations sur l’instance EC2, vous devez disposer de privilèges racine [sudo]. Vous voyez ainsi immédiatement s’il existe des problèmes d’autorisation ou de chemin d’accès. Veillez toutefois à ne pas d’ajouter des lignes supplémentaires lors de la copie du contenu, ou à les modifier de quelque façon.
À partir du répertoire
/etc/pki/tls/private, vérifiez que les paramètres de propriété du fichier, de groupe et d’autorisation correspondent aux valeurs par défaut Amazon Linux très restrictives (propriétaire=racine, groupe=racine, lecture/écriture pour propriétaire uniquement). Les commandes seraient les suivantes :[ec2-user private]$sudo chown root.root custom.key[ec2-user private]$sudo chmod 600 custom.key[ec2-user private]$ls -al custom.keyLes commandes ci-dessus devraient générer le résultat suivant :
-rw------- root root custom.key -
Modifiez
/etc/httpd/conf.d/ssl.confpour refléter les nouveaux fichiers de certificat et de clé.-
Fournissez le chemin et le nom de fichier du certificat d’hôte signé par une CA dans la directive
SSLCertificateFiled’Apache :SSLCertificateFile /etc/pki/tls/certs/custom.crt -
Si vous avez reçu un fichier de certificat intermédiaire (
intermediate.crtdans cet exemple), indiquez son nom correct de chemin et de fichier à l’aide de la directiveSSLCACertificateFiled’Apache :SSLCACertificateFile /etc/pki/tls/certs/intermediate.crtNote
Certaines autorités de certification combinent le certificat d’hôte et les certificats intermédiaires dans un seul fichier ; cette directive devient alors inutile. Consultez les instructions fournies par votre autorité de certification.
-
Fournissez le chemin et le nom de fichier de la clé privée dans la directive
SSLCertificateKeyFiled’Apache :SSLCertificateKeyFile /etc/pki/tls/private/custom.key
-
-
Enregistrez
/etc/httpd/conf.d/ssl.confet redémarrez Apache.[ec2-user ~]$sudo service httpd restart -
Testez votre serveur en saisissant votre nom de domaine dans la barre d’URL de navigateur avec le préfixe
https://. Votre navigateur doit charger la page de test via HTTPS sans générer d’erreurs.
Étape 3 : Tester et renforcer la configuration de sécurité
Une fois que votre TLS est opérationnel et exposé au public, vous devriez tester son niveau de sécurité. Il est facile de le faire avec des services en ligne comme Qualys SSL Labs
Important
Le test concret est essentiel pour la sécurité de votre serveur. Les petites erreurs de configuration peuvent entraîner des failles de sécurité et des pertes de données. Comme les pratiques de sécurité recommandées changent constamment en réponse à la recherche et aux menaces émergentes, des audits de sécurité périodiques sont essentiels pour la bonne administration du serveur.
Sur le site Qualys SSL Labswww.example.com. Après environ deux minutes, vous recevrez une note (de A à F) pour votre site et une analyse détaillée des résultats. Même si l’aperçu montre que la configuration est principalement sûre, le rapport détaillé indique plusieurs problèmes potentiels. Exemples :
✗ Le chiffrement RC4 est pris en charge pour être utilisé par certains navigateurs plus anciens. Un chiffrement est le noyau mathématique d’un algorithme de chiffrement. RC4, un chiffrement rapide utilisé pour chiffrer les flux de données TLS, est connu pour avoir plusieurs failles importantes
✗ Les anciennes versions de TLS sont prises en charge. La configuration prend en charge TLS 1.0 (déjà obsolète) et TLS 1.1 (bientôt obsolète). Seul TLS 1.2 est recommandé depuis 2018.
Pour corriger la configuration de TLS
-
Ouvrez le fichier de configuration
/etc/httpd/conf.d/ssl.confdans un éditeur de texte et mettez en commentaire les lignes qui suivent en saisissant « # » au début de chacune d’entre elles :#SSLProtocol all -SSLv3 #SSLProxyProtocol all -SSLv3 -
Ajoutez les directives suivantes :
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2Ces directives désactivent explicitement les versions SSL 2 et 3, ainsi que les versions TLS 1.0 et 1.1. Le serveur refuse désormais d’accepter les connexions chiffrées avec des clients utilisant tout sauf TLS 1.2. La formulation des commentaires dans la directive communique plus clairement, à un lecteur humain, ce pour quoi le serveur est configuré.
Note
La désactivation des versions TLS 1.0 et 1.1 de cette manière empêche un faible pourcentage de navigateurs web obsolètes d’accéder à votre site.
Pour modifier la liste des chiffrements autorisés
-
Ouvrez le fichier de configuration
/etc/httpd/conf.d/ssl.confet trouvez la section avec les exemples mis en commentaire pour la configuration deSSLCipherSuiteetSSLProxyCipherSuite.#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 #SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5Laissez-les tels quels et ajoutez en dessous les directives suivants :
Note
Même si elle est affichée ici sur plusieurs lignes pour plus de lisibilité, chacune de ces deux directives doit être sur une seule ligne sans espaces entre les noms des chiffrements.
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLProxyCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHACes chiffrements constituent un sous-ensemble de la liste beaucoup plus longue des chiffrements pris en charge dans OpenSSL. Ils sont été sélectionnés et classés selon les critères suivants :
-
Prise en charge de la confidentialité persistante
-
Force
-
Rapidité
-
Chiffrements spécifiques avant les familles de chiffrements
-
Chiffrements autorisés avant les chiffrements refusés
Notez que les noms des chiffrements de niveau élevé contiennent les lettres ECDHE, pour Elliptic Curve Diffie-Hellman Ephemeral. Expression dans laquelle Ephemeral (éphémère) indique la confidentialité persistante. Par ailleurs, RC4 compte maintenant parmi les chiffrements interdits vers la fin.
Nous vous recommandons d’utiliser une liste explicite de chiffrements au lieu de compter sur les valeurs par défaut ou les directives succinctes dont le contenu n’est pas visible. La liste des chiffrements affichée compte parmi les nombreuses listes possibles. Par exemple, il se peut que vous vouliez optimiser une liste pour la rapidité plutôt que la confidentialité persistante.
Si vous anticipez un besoin de prise en charge des clients plus anciens, vous pouvez autoriser la suite de chiffrement DES-CBC3-SHA.
Enfin, chaque mise à jour de OpenSSL présente de nouveaux chiffrements qui rend les anciens obsolète. Gardez à jour votre instance EC2 Amazon Linux, surveillez les annonces de sécurité d’OpenSSL
et restez attentif aux rapports de nouvelles attaques de la sécurité dans la presse technique. -
-
Supprimez la mise en commentaire de la ligne suivante en retirant le « # » :
#SSLHonorCipherOrder onCette commande force le serveur à préférer les chiffrements de niveau élevé notamment (dans ce cas) ceux qui prennent en charge la confidentialité persistante. Avec cette directive activée, le serveur essaie d’établir une connexion très sécurisée avant d’avoir recours aux chiffrements autorisés dotés d’une sécurité moindre.
-
Redémarrez Apache. Si vous testez de nouveau le domaine sur Qualys SSL Labs
, vous devriez voir que la vulnérabilité RC4 a été supprimée.
Dépannage
-
Mon serveur Web Apache ne démarre pas si je ne fournis pas un mot de passe
Il s’agit du comportement attendu si vous avez installé une clé de serveur privée chiffrée et protégée par mot de passe.
Vous pouvez supprimer l’obligation de chiffrement et de mot de passe de la clé. En supposant que vous disposez d’une clé RSA privée chiffrée nommée
custom.keydans le répertoire par défaut et que le mot de passe de celle-ci estabcde12345, exécutez les commandes suivantes sur votre instance EC2 pour générer une version non chiffrée de la clé.[ec2-user ~]$cd /etc/pki/tls/private/[ec2-user private]$sudo cp custom.key custom.key.bak[ec2-user private]$sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt[ec2-user private]$sudo mv custom.key.nocrypt custom.key[ec2-user private]$sudo chown root.root custom.key[ec2-user private]$sudo chmod 600 custom.key[ec2-user private]$sudo service httpd restartApache devrait maintenant démarrer sans vous demander de fournir un mot de passe.
