Didacticiel : Configurer SSL/TLS avec l'AMI Amazon Linux - Amazon Elastic Compute Cloud

Didacticiel : Configurer SSL/TLS avec l'AMI 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 didacticiel 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 didacticiel 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 normes de sécurité considèrent TLS 1.0 comme peu sûr, et TLS 1.0 et TLS 1.1 sont sur le point d’être déclarés formellement obsolètes par l’IETF. Ce didacticiel contient des conseils pour l’activation de TLS 1.2 exclusivement. (Un protocole TLS 1.3 plus récent existe sous forme d’ébauche, mais il n’est pas pris en charge sur Amazon Linux). Pour plus d'informations sur les normes de chiffrement mises à jour, consultez RFC 7568 et RFC 8446.

Ce didacticiel 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 didacticiel ne fonctionneront peut-être pas pour vous. Pour Amazon Linux 2, veuillez consulter Didacticiel : Configurer SSL/TLS sur Amazon Linux 2. Pour Ubuntu, consultez la documentation de la communauté Ubuntu suivante : ApachemySQLPHP. Pour Red Hat Enterprise Linux, consultez les informations suivantes :Setting up the Apache HTTP Web Server (Configuration du serveur web HTTP Apache). Pour les autres distributions, consultez leur documentation spécifique.

Prerequisites

Avant de commencer ce didacticiel, 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 : Lancement d'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 des instructions pas à pas, consultez le Didacticiel : 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

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

  1. Connectez-vous à votre instance et confirmez qu'Apache est en cours d'exécution.

    [ec2-user ~]$ sudo service httpd status

    Si nécessaire, démarrez Apache.

    [ec2-user ~]$ sudo service httpd start
  2. 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 -y installe 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
  3. 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 mod24_ssl

    Votre 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.conf

    Le 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.key

    Une 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.crt

    Un 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 .key et .crt sont 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.pem ou tout autre nom de fichier dans la mesure où la directive associée dans le fichier ssl.conf utilise 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.

  4. Redémarrez Apache.

    [ec2-user ~]$ sudo service httpd restart
  5. 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, qui prend également en charge l'automatisation du processus de création et de renouvellement des certificats. Pour de plus amples informations sur l'utilisation de Let's Encrypt comme autorité de certification, consultez Automatisation de certificat : Utilisation de Let's Encrypt avec Certbot sur Amazon Linux 2.

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 et industriels recommandent l'utilisation d'une taille de clé minimale (module) de 2048 bits pour les clés RSA conçues pour protéger des documents jusqu'en 2030. La taille de module par défaut générée par OpenSSL dans Amazon Linux est de 2048 bits ce qui signifie que la clé existante générée automatiquement convient à l'utilisation d'un certificat signé par une CA. Une autre procédure est décrite ci-dessous pour ceux qui désirent une clé personnalisée, par exemple, une avec un module plus important ou utilisant un algorithme de chiffrement différent.

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

  1. 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.

  2. (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 -genkey

      Le 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

      Les autorités de certification ne fournissent pas toutes le même niveau de support pour les clés basées sur les courbes elliptiques 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.key

    Les commandes ci-dessus devraient générer le résultat suivant :

    -rw------- root root custom.key

    Une fois que vous avez créé et configuré une clé satisfaisante, vous pouvez créer une CSR.

  3. 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.pem

    OpenSSL 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.pem contient votre clé publique, la signature numérique de votre clé publique et les métadonnées que vous avez saisies.

  4. 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.com est le nom commun, example.com serait 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 didacticiel, vous devez utiliser uniquement un fichier de certificat au format PEM qui comporte habituellement (mais pas toujours) une extension .pem ou .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 -in certificate.crt -text

    Vérifiez que ces lignes apparaissent dans le fichier. N'utilisez pas de fichiers se terminant par .p7b, .p7c ou autres extensions similaires.

  5. 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.crt

    Les commandes ci-dessus devraient générer le résultat suivant :

    -rw------- root root custom.crt

    Les 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.crt

    Les commandes ci-dessus devraient générer le résultat suivant :

    -rw-r--r-- root root intermediate.crt
  6. 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.key

    Les commandes ci-dessus devraient générer le résultat suivant :

    -rw------- root root custom.key
  7. Modifiez /etc/httpd/conf.d/ssl.conf pour refléter les nouveaux fichiers de certificat et de clé.

    1. Fournissez le chemin et le nom de fichier du certificat d'hôte signé par une CA dans la directive SSLCertificateFile d’Apache :

      SSLCertificateFile /etc/pki/tls/certs/custom.crt
    2. Si vous avez reçu un fichier de certificat intermédiaire (intermediate.crt dans cet exemple), indiquez son nom correct de chemin et de fichier à l'aide de la directive SSLCACertificateFile d'Apache :

      SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
      Note

      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.

    3. Fournissez le chemin et le nom de fichier de la clé privée dans la directive SSLCertificateKeyFile d’Apache :

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. Enregistrez /etc/httpd/conf.d/ssl.conf et redémarrez Apache.

    [ec2-user ~]$ sudo service httpd restart
  9. 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 qui effectue une analyse gratuite et complète de votre configuration de sécurité. En fonction des résultats, vous pouvez décider de renforcer la configuration de sécurité par défaut en contrôlant les protocoles que vous acceptez, les chiffrements que vous préférez et que vous excluez. Pour plus d'informations, consultez comment Qualys formule ses scores.

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 Labs, tapez le nom de domaine complet de votre serveur dans le formulaire www.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. À moins que vous ayez une très bonne raison de prendre en charge des navigateurs existants, vous devez désactiver cette option.

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

  1. Ouvrez le fichier de configuration /etc/httpd/conf.d/ssl.conf dans 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
  2. Ajoutez les directives suivantes :

    SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Ces 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

  1. Ouvrez le fichier de configuration /etc/httpd/conf.d/ssl.conf et trouvez la section avec les exemples mis en commentaire pour la configuration de SSLCipherSuite et SSLProxyCipherSuite.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 #SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

    Laissez-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-SHA

    Ces 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.

  2. Supprimez la mise en commentaire de la ligne suivante en retirant le « # » :

    #SSLHonorCipherOrder on

    Cette 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.

  3. 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.

Troubleshoot

  • 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.key dans le répertoire par défaut et que le mot de passe de celle-ci est abcde12345, 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 restart

    Apache devrait maintenant démarrer sans vous demander de fournir un mot de passe.