Meilleures pratiques de Citrix Networking SSL / TLS

Aperçu

Ce document technique fournit les étapes nécessaires pour valider la configuration SSL \ TLS existante d’un serveur virtuel s’exécutant sur un Citrix ADC et les moyens de s’assurer que les meilleures pratiques sont appliquées. Nous couvrons les éléments de configuration tels que la chaîne de certificats liée au serveur virtuel, les paramètres de la suite de chiffrement et la désactivation des anciens protocoles vulnérables aux attaques.

Il existe de nombreux outils qui peuvent être utilisés pour valider la configuration d’un site public protégé par Citrix ADC - l’un de ces outils est leTest de serveurSSL par Qualys SSL Labs. Il effectue une série robuste de tests sur votre serveur et fournit une carte de score facile à lire que vous pouvez utiliser pour apporter des améliorations à votre configuration. La numérisation est gratuite et ne prend qu’environ une minute.

Qualys développe activement le test SSL et, en tant que tels, les tests sont susceptibles de changer à l’avenir à mesure que de nouveaux protocoles seront créés et que de nouvelles vulnérabilités seront découvertes. En raison de cette vulnérabilité, il est recommandé de tester régulièrement les sites pour s’assurer que les nouvelles vulnérabilités ne sont pas exposées.

Remarque : SSLLabs affiche l’URL du serveur testé avec le score final sur leur tableau de bord public, à moins que l’option Ne pas afficher les résultats sur les tableaux soit choisie.

Éléments de configuration qui doivent être validés

  • Certificats - La chaîne complète est-elle fournie et fiable ? L’algorithme de signature est-il sécurisé ?
  • Protocoles, clés et chiffrement - Quelles versions de protocole SSL et TLS sont prises en charge ? Quelles suites de chiffrement sont préférées et dans quel ordre ? Est-ce que les suites de chiffrement fournies prennent en charge le secret de transfert ?
  • TLS Handshake Simulation - Détermine quel protocole et chiffrement sont négociés par plusieurs clients et navigateurs différents
  • Détails du protocole - La renégociation sécurisée est-elle prise en charge ? La sécurité stricte des transports est-elle prise en charge ?
  • Vulnérabilités connues - Le serveur est-il vulnérable aux attaques telles que POODLE, BEAST ou TLS descendance ?

Une fois le test SSLLabs terminé, une note de lettre est présentée avec une échelle de points pour chacune des quatre catégories :

1 Certificate 2 Protocol Support 3 Key Exchange 4 Cipher Strength

Chacune des catégories ci-dessus reçoit un score numérique qui est ensuite calculé en moyenne dans un score total. Il existe également des cas particuliers ou des configurations qui limitent la note finale ou retirent des points - par exemple lorsqu’un certificat n’est pas approuvé ou si SSLv3 est activé. Une documentation complète sur la façon dont les tests SSL Labs sont classés peutêtre trouvé ici.

Application Citrix Receiver \ Workspace Prise en charge du chiffrement pour les déploiements de passerelle

*Important : consultez les articles suivants concernant la prise en charge du chiffrement client lors du déploiement d’un serveur virtuel de passerelle pour les applications virtuelles et les postes de travail : CTX234227 pour Citrix Receiver et CTX250104 pour l’application Workspace*

Problèmes liés à la mise en œuvre

Certaines des étapes de configuration notées dans cet article peuvent causer des problèmes de connectivité avec les anciens clients et navigateurs. Par exemple, Windows XP SP2 ne prend pas en charge les certificats SHA256 ; les navigateurs Web plus anciens ne peuvent pas prendre en charge les chiffrements TLS1.2 ou ECC. Dans les cas où le support est manquant, le client peut rencontrer des messages d’erreur ou une incapacité à afficher le site.

Remarque : reportez-vous à la section Notes sur le microprogramme pour les versions requises et d’autres remarques concernant le microprogramme ADC spécifique.

Étapes de base - GUI

Voici les étapes générales qui sont prises en premier pour garantir un score élevé lors du test SSL Labs.

  • Assurez-vous que l’ADC exécute une version récente du micrologiciel - 10.5 build 67 ou version ultérieure est recommandé

    • Désactiver SSLv3 sur tous les serveurs virtuels (ou profils SSL si vous utilisez le profil par défaut SSL) dans la section Paramètres SSL de la configuration du serveur virtuel

SSLv3-Disabled

  • Assurez-vous que la chaîne de certificats est complète et fiable
    • Les certificats ne sont pas toujours signés par une autorité de certification que chaque point de terminaison approuve intrinsèquement. Souvent, ils sont signés par une autorité de certification intermédiaire
    • Le certificat intermédiaire est installé sur l’ADC puis lié au certificat de serveur qui est lié au serveur virtuel
    • Les certificats intermédiaires sont fournis par le fournisseur qui a fourni le certificat du serveur, souvent dans un « paquet de certificats ». Ils peuvent également être trouvés sur le site public des fournisseurs
    • Il peut y avoir plusieurs certificats intermédiaires qui doivent être installés et liés. Pour que le certificat de serveur fonctionne, le client doit recevoir une chaîne de certificats se terminant par un certificat d’autorité de certification que le client approuve déjà
    • Le certificat d’autorité de certification racine utilisé pour signer le certificat intermédiaire sera probablement approuvé par tous les clients
    • Pour installer le certificat intermédiaire, accédez à : Gestion du trafic > SSL > Certificats > Certificats CA et choisissez Installer (Remarque : les versions antérieures de Citrix ADC n’ont pas l’option « Certificats CA » dans l’interface graphique )
    • Une fois le certificat intermédiaire installé, il peut être lié au certificat du serveur en sélectionnant le certificat et en choisissant le lien dans le menu Action.
    • Si le certificat intermédiaire correct est installé, il est automatiquement renseigné dans le menu de liaison.

Certificat CA - installation

Lien de certificat

Lié avec certificat

  • Assurez-vous que TLSv1.2 est activé sur tous les serveurs virtuels (ou profils SSL si vous utilisez le profil par défaut SSL) dans la section Paramètres SSL de la configuration du serveur virtuel

TLSv12-Enabled

  • Autoriser la renégociation sécurisée
    • Accédez à Gestion du trafic > SSL et sélectionnez Modifier les paramètres SSL avancés
    • Définissez Deny SSL Renégociation sur NONSECURE pour permettre à seuls les clients prenant en charge RFC 5746 de renégocier

Renégocier en toute sécurité

  • Créer une clé DH à utiliser par les suites de chiffrement DHE
    • Remarque : la création et la liaison d’une clé DH sont facultatives, plus lentes et utiles uniquement pour les clients plus anciens qui ne prennent pas en charge ECDHE. Si une clé DH n’est pas liée, les suites de chiffrement DHE sont ignorées.
    • Allez dans Gestion du trafic > SSL et sélectionnez Créer une clé Diffie-Hellman (DH)
    • Dans le champ Nom du fichier DH, entrez un nom de fichier pour le fichier clé (Remarque : le chemin par défaut de l’appliance est /nsconfig/ssl/)
    • Entrez la taille de clé DH souhaitée dans la taille du paramètre DH - 1024 ou 2048 (Remarque : les clés DH 4096 bits ne sont pas prises en charge actuellement)
    • Remarque : la taille de la clé DH devrait être de la même taille que la clé RSA et est généralement de 2048 bits
    • Choisissez le générateur de nombres aléatoires 2 ou 5
    • Cliquez sur Créer - la génération de clés peut prendre un certain temps.

DH-Générer

  • Liez la clé DH au serveur virtuel
    • Sur le serveur virtuel sélectionné, ouvrez la section Paramètres SSL et cliquez sur le bouton Modifier (crayon dans le coin supérieur droit)
    • Cochez la case Activer DH Param
    • Définissez le chemin d’accès au fichier clé créé précédemment

DH-Liaison

  • Créer un groupe de chiffrement personnalisé qui fournit la confidentialité directe (FS)
    • Accédez à Gestion du trafic > SSL > Groupes de chiffrement et choisissez Ajouter
    • Entrez un nom pour le groupe de chiffrement
    • Cliquez sur + Ajouter puis développez la section + ALL - sélectionnez les suites de chiffrement suivantes :
      • TLS1.3-CHACHA20-POLY1305-SHA256
      • TLS1.3-AES128-GCM-SHA256
      • TLS1.3-AES256-GCM-SHA384
      • TLS1.2-ECDHE-ECDSA-AES256-SHA384
      • TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
      • TLS1.2-DHE-RSA-AES256-GCM-SHA384
      • TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
      • TLS1.2-ECDHE-RSA-CHACHA20-POLY1305
      • TLS1.2-ECDHE-ECDSA-CHACHA20-POLY1305
      • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
    • Cliquez sur la flèche > droite pour déplacer les chiffrements de la colonne Disponible vers la colonne Configur é
    • Cliquez sur Créer

Création-Groupe

  • Liez le groupe de chiffrement au serveur virtuel
    • Sur le serveur virtuel sélectionné, ouvrez la section Ciphers SSL et cliquez sur le bouton Modifier (crayon dans le coin supérieur droit)
    • Supprimez tous les chiffrements ou groupes de chiffrement existants à l’aide du bouton Supprimer tout ou de l’icône - de chaque élément
    • Sélectionnez le bouton radio Groupes de chiffrement et choisissez le groupe de chiffrement créé précédemment
    • Cliquez sur OK.

Groupe complémentaire

Groupe de chiffrement des compléments

  • Activer la sécurité de transport stricte (HSTS) sur le serveur virtuel
    • Sur le serveur virtuel sélectionné, ouvrez la section Paramètres SSL et cliquez sur le bouton Modifier (crayon dans le coin supérieur droit)
    • Cochez la case pour activer HSTS
    • Entrez 157680000 dans le champ Âge maximum
    • Remarque : cet indicateur est disponible dans les versions 12.0 35 et ultérieures. Pour les versions antérieures, voir cet article pour ajouter la prise en charge HSTS.

HSTS-Enable

Étapes de base - CLI

Voici les étapes générales qui sont prises en premier pour garantir un score élevé lors du test SSL Labs. Dans les exemples CLI ci-dessous, le nom du serveur virtuel SSL est répertorié comme ex-vServer - il peut être remplacé par le nom du serveur virtuel SSL dans votre environnement.

  • Assurez-vous que SSL3 est désactivé et que TLS1.2 est activé sur un serveur virtuel nommé Ex-vServer
set ssl vserver Ex-vServer -ssl3 DISABLED -tls1 ENABLED -tls11 ENABLED -tls12 ENABLED
<!--NeedCopy-->
  • Pour activer ONLY TLS1.2 et TLS1.3 sur ex-VServer, utilisez la commande suivante à la place de ce qui précède
set ssl vserver Ex-vServer -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tls13 ENABLED
<!--NeedCopy-->
  • Autoriser la renégociation sécurisée
set ssl parameter -denySSLReneg NONSECURE
<!--NeedCopy-->
  • Créer et lier une clé DH à un serveur virtuel nommé Ex-vServer
create ssl dhparam DH_Key_Name_Here.key 2048 -gen 2

set ssl vServer Ex-vServer -dh ENABLED -dhFile DH_Key_Name_Here.key
<!--NeedCopy-->
  • Créer un groupe de chiffrement personnalisé qui préfère les suites de chiffrement ECDHE et ECDSA
add ssl cipher New_APlus_CipherGroup

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.3-CHACHA20-POLY1305-SHA256

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.3-AES128-GCM-SHA256

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.3-AES256-GCM-SHA384

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY1305

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-ECDSA-CHACHA20-POLY1305

bind ssl cipher New_APlus_CipherGroup -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
<!--NeedCopy-->
  • Délier le groupe de chiffrement par défaut du serveur virtuel et lier le groupe personnalisé
unbind ssl vServer Ex-vServer -cipherName DEFAULT

bind ssl vServer Ex-vServer -cipherName New_APlus_CipherGroup

bind ssl vServer Ex-vServer -eccCurveName ALL
<!--NeedCopy-->
  • Activer Strict Transport Security (HSTS) sur un serveur virtuel nommé ex-vServer
set ssl vServer Ex-vServer -HSTS ENABLED -maxage 157680000
<!--NeedCopy-->

Autres paramètres

Certificats SHA1

Les certificats signés avec SHA1 sont considérés comme faibles et empêchent un grade élevé dans le test SSLLabs. Si des certificats sont signés SHA1, ils sont renouvelés avec un certificat SHA256 et installés sur l’ADC.

DNS CAA

DNS Certification Authority Authorization (CAA) permet aux autorités de certification de valider si elles sont autorisées à délivrer des certificats pour un domaine et de fournir un contact en cas de problème.

Elle est configurée sur les serveurs DNS, plutôt que sur l’appliance ADC.

Notes du micrologiciel

Au fur et à mesure que de nouvelles vulnérabilités seront découvertes, elles seront testées par SSLLabs, de sorte que des tests fréquents sont recommandés. Certaines vulnérabilités sont corrigées par les améliorations du code Citrix ADC.

  • Version minimale requise : 10.5 build 67

  • La vulnérabilité ROBOT a été corrigée dans les versions 12.0 build 53, 11.1 build 56, 11.0 build 71 et 10.5 build 67 -plus de détails sont disponibles ici

  • L’indicateur HSTS (Strict Transport Security) est devenu disponible dans la version 12.0 35 - les versions antérieures nécessitaient une politique de réécriture pour insérer l’en-tête HSTS. Vous ne pouvez pas utiliser les deux car cela entraînera l’insertion de 2 en-têtes, ce qui n’est pas autorisé.

  • La prise en charge de TLS1.2 a été ajoutée aux appliances VPX dans 10.5 build 57. Il était disponible dans les versions antérieures pour les appliances avec du matériel SSL dédié

  • La prise en charge de TLS1.3 a été ajoutée dans 12.1 build 49.23 - il doit être activé dans le vServerSSLProfile, et les chiffrements TLS1.3 (répertoriés) doivent être liés

  • La prise en charge des certificats ECC a été ajoutée aux appliances VPX dans la version 12.0 57. Il était disponible dans les versions antérieures pour les appliances avec du matériel SSL dédié

  • La vulnérabilité Zombie POODLE a été corrigée dans les versions 12.1 build 50.31, 12.0 build 60.9, 11.1 build 60.14, 11.0 build 72.17 et 10.5 build 69.5. Cette vulnérabilité affecte uniquement les appliances MPX \ SDX avec du matériel SSL Nitrox, ce qui signifie que les appliances MPX \ SDX avec Coleto Creek ne sont pas vulnérables ; la désactivation des suites de chiffrement basées sur CBC atténuera également cette vulnérabilité. Voir l’article CTX pour plus d’informations

  • La liste de chiffrement a été modifiée pour corriger les faiblesses de la CBC, supprimant ainsi les chiffrements 0xc028 et 0x39

Meilleures pratiques de Citrix Networking SSL / TLS