Suites de chiffrement disponibles sur les appliances Citrix ADC

Votre appliance NetScaler ADC est livrée avec un ensemble prédéfini de groupes de chiffrement. Pour utiliser des chiffrements qui ne font pas partie du groupe de chiffrement DEFAULT, vous devez les lier explicitement à un serveur virtuel SSL. Vous pouvez également créer un groupe de chiffrement défini par l’utilisateur pour lier au serveur virtuel SSL. Pour plus d’informations sur la création d’un groupe de chiffrement défini par l’utilisateur, voir Configurer des groupes de chiffrement définis par l’utilisateur sur l’appliance ADC.

Remarques

Le chiffrement RC4 n’est pas inclus dans le groupe de chiffrement par défaut sur l’appliance NetScaler ADC. Cependant, il est pris en charge dans le logiciel des appliances N3. Le chiffrement RC4, y compris la prise de contact, est effectué dans le logiciel.

Citrix recommande de ne pas utiliser ce chiffrement car il est considéré comme non sécurisé et déconseillé par la RFC 7465.

Utilisez la commande « show hardware » pour déterminer si votre appliance est équipée de puces N3.

sh hardware

Platform: NSMPX-22000 16\*CPU+24\*IX+12\*E1K+2\*E1K+4*CVM N3 2200100

Manufactured on: 8/19/2013

CPU: 2900MHZ

Host Id: 1006665862

Serial no: ENUK6298FT

Encoded serial no: ENUK6298FT
<!--NeedCopy-->

• Pour afficher des informations sur les suites de chiffrement liées par défaut au niveau du frontal (à un serveur virtuel), tapez : sh cipher DEFAULT
• Pour afficher des informations sur les suites de chiffrement liées par défaut au niveau du serveur principal (à un service), tapez : sh cipher DEFAULT_BACKEND
• Pour afficher des informations sur tous les groupes de chiffrement (alias) définis sur l’appliance, tapez : sh cipher
• Pour afficher des informations sur toutes les suites de chiffrement qui font partie d’un groupe de chiffrement spécifique, tapez : sh cipher <alias name>. Par exemple, sh chiffre ECDHE.

Les liens suivants répertorient les suites de chiffrement prises en charge sur différentes plates-formes NetScaler ADC et sur des modules de sécurité matérielle externes (HSM) :

• Appliance NetScaler ADC MPX/SDX (N3): prise en charge du chiffrement sur une appliance NetScaler ADC MPX/SDX (N3)
• Appliance Intel Coleto NetScaler ADC MPX/SDX : prise en charge du chiffrement sur une appliance basée sur puce SSL Intel Coleto NetScaler ADC MPX/SDX
• Appliance NetScaler ADC VPX : prise en charge du chiffrement sur une appliance NetScaler ADC VPX
• Appliance FIPS NetScaler ADC MPX/SDX 14000: prise en charge du chiffrement sur une appliance FIPS NetScaler ADC MPX/SDX 14000
• HSM externe (Thales/Safenet) : chiffrement pris en charge sur un HSM externe (Thales/Safenet)
• Appliance NetScaler ADC MPX/SDX (N2) : prise en charge du chiffrement sur une appliance NetScaler ADC MPX/SDX (N2)
• Appliance FIPS NetScaler ADC MPX 9700 : prise en charge du chiffrement sur une NetScaler ADC MPX 9700 FIPS avec microprogramme 2.2
• Appliances CITRIX ADC VPX FIPS et MPX FIPS : prise en charge du chiffrement sur les appliances certifiées NetScaler ADC VPX FIPS et MPX FIPS

Remarque :

Pour connaître la prise en charge du chiffrement DTLS, reportez-vous à la section Prise en charge du chiffrement DTLS sur les appliances NetScaler ADC VPX, MPX et SDX.

Tableau1 - Prise en charge du serveur virtuel/service frontend interne :

Tableau 2 - Prise en charge des services dorsaux :

Le protocole TLS 1.3 n’est pas pris en charge sur le serveur principal.

Pour obtenir la liste détaillée des chiffrements ECDSA pris en charge, voir Prise en charge des suites de chiffrement ECDSA.

Remarque

• La suite de chiffrement TLS-Fallback_scsv est prise en charge sur toutes les appliances à partir de la version 10.5 build 57.x.

• La prise en charge de HTTP Strict Transport Security (HSTS) est basée sur des règles.

• Tous les certificats signés SHA-2 (SHA256, SHA384, SHA512) sont pris en charge sur le frontal de tous les matériels. Dans la version 11.1 build 54.x et ultérieures, ces certificats sont également pris en charge sur le back-end de tous les dispositifs. Dans les versions 11.0 et antérieures, seuls les certificats signés SHA256 sont pris en charge sur le back-end de tous les dispositifs.

• Dans la version 11.1 build 52.x et antérieure, les chiffrements suivants ne sont pris en charge que sur l’avant des appliances MPX 9700 et MPX/SDX 14000 FIPS :
  • TLS1.2-ECDHE-RSA-AES-256-SHA384
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384. From release 11.1 build 53.x, and in release 12.0, these ciphers are also supported on the back end.
• Tous les chiffrements Chacha20-Poly1035 utilisent une fonction pseudo-aléatoire (PSF) TLS avec la fonction de hachage SHA-256.

Secret Perfect Forward (PFS)

Perfect Forward Secrecy garantit la protection des communications SSL actuelles même si la clé de session d’un serveur Web est compromise ultérieurement.

Pourquoi avez-vous besoin de Perfect Forward Secrecy (PFS) ?

Une connexion SSL est utilisée pour sécuriser les données transmises entre un client et un serveur. Cette connexion commence par la prise de contact SSL entre le navigateur d’un client et le serveur Web contacté. C’est au cours de cette poignée de contact que le navigateur et le serveur échangent certaines informations pour parvenir à une clé de session qui sert de moyen de chiffrer les données tout au long de la communication.

Le RSA est l’algorithme le plus couramment utilisé pour l’échange de clés. Le navigateur utilise la clé publique du serveur pour chiffrer et envoyer le secret pré-maître à un serveur. Ce secret pré-maître est utilisé pour arriver à la clé de session. Le problème dans l’approche d’échange de clés RSA est que si un attaquant parvient à saisir la clé privée du serveur à n’importe quel moment dans le futur, l’attaquant obtient le secret pré-maître à l’aide duquel la clé de session peut être obtenue. Cette clé de session peut désormais être utilisée par l’attaquant pour déchiffrer toutes les conversations SSL. Cela signifie que vos communications SSL historiques étaient sécurisées auparavant, mais elles ne sont plus sécurisées, car la clé privée volée du serveur peut être utilisée pour arriver à la clé de session et ainsi déchiffrer toute conversation historique enregistrée.

Le besoin est de pouvoir protéger les communications SSL passées même si la clé privée du serveur a été compromise. C’est là que la configuration de Perfect Forward Secrecy (PFS) vient à la rescousse.

Comment PFS aide-t-il ?

Perfect Forward Secrecy (PFS) protège les communications SSL passées en demandant au client et au serveur d’accepter une nouvelle clé pour chaque session et en gardant le calcul de cette clé de session secret. Il fonctionne sur la base que la compromission d’une clé de serveur ne doit pas entraîner de compromis sur la clé de session. La clé de session est dérivée séparément aux deux extrémités et n’est jamais transférée sur le fil. Les clés de session sont également détruites une fois la communication terminée. Ces faits garantissent que même si quelqu’un a accès à la clé privée du serveur, il ne sera pas en mesure d’arriver à la clé de session et ne serait donc pas en mesure de déchiffrer les données passées.

Explication avec exemple

Supposons que nous utilisons DHE pour atteindre le PFS. L’algorithme DH garantit que même si un pirate met en main la clé privée du serveur, le pirate ne pourra pas arriver à la clé de session car la clé de session et les numéros aléatoires (utilisés pour arriver à la clé de session) sont gardés secrets aux deux extrémités et ne sont jamais échangés par fil. PFS peut être atteint en utilisant l’échange de clés Diffie-Hellman éphémère qui crée de nouvelles clés temporaires pour chaque session SSL.

L’inverse de la création d’une clé pour chaque session est qu’elle nécessite des calculs supplémentaires, mais cela peut être surmonté en utilisant la courbe elliptique qui a des tailles de clés plus petites.

Configurer PFS sur l’appliance NetScaler ADC

PFS peut être configuré sur un NetScaler ADC en configurant des chiffrements DHE ou ECDHE. Ces chiffrements garantissent que la clé de session secrète créée n’est pas partagée sur le fil (algorithme DH) et que la clé de session ne reste vivante que pendant une courte période (éphémère). Les deux configurations sont expliquées dans les sections suivantes.

Remarque : L’utilisation de chiffrements ECDHE au lieu de DHE permet de sécuriser la communication avec des tailles de clés plus petites.

Configurer DHE à l’aide de l’interface graphique

1. Générez une clé DH.

   a. Accédez à Gestion du trafic > SSL > Outils.

   b. Cliquez sur Créer une clé DH (Diffie Helman).

   Remarque : La génération d’une clé DH de 2 048 bits peut prendre jusqu’à 30 minutes.

2. Activez DH Param pour le serveur virtuel SSL et attachez la clé DH au serveur virtuel SSL.

   a. Accédez à Configuration > Gestion du trafic > Serveurs virtuels.

   b. Sélectionnez le serveur virtuel sur lequel vous souhaitez activer DH.

   c. Cliquez sur Modifier, cliquez sur Paramètres SSL, puis sur Activer le paramètre DH.

3. Liez les chiffrements DHE au serveur virtuel.

   a. Accédez à Configuration > Gestion du trafic > Serveurs virtuels.

   b. Sélectionnez le serveur virtuel sur lequel vous souhaitez activer DH et cliquez sur l’icône crayon pour le modifier.

   c. Sous Paramètres avancés, cliquez sur l’icône Plus en regard de SSL Ciphers, sélectionnez les groupes de chiffrement DHE, puis cliquez sur OK pour lier.

   Remarque : Assurez-vous que les chiffrements DHE se trouvent en haut de la liste des chiffrements liés au serveur virtuel.

Configurer ECDHE à l’aide de l’interface graphique

1. Liez les courbes ECC au serveur virtuel SSL.

   a. Accédez à Configuration > Gestion du trafic > Équilibrage de charge > Serveurs virtuels.

   b. Sélectionnez le serveur virtuel SSL que vous souhaitez modifier, cliquez sur Courbe ECC, puis sur Ajouter une liaison.

   c. Liez la courbe ECC requise au serveur virtuel.

2. Liez les chiffrements ECDHE au serveur virtuel.

   a. Accédez à Configuration > Gestion du trafic > Serveurs virtuels et sélectionnez le serveur virtuel sur lequel vous souhaitez activer le DH.

   b. Cliquez sur Modifier > Chiffrements SSL, sélectionnez les groupes de chiffrement ECDHE, puis cliquez sur Lier.

   Remarque : Assurez-vous que les chiffrements ECDHE figurent en haut de la liste des chiffrements liés au serveur virtuel.

Remarque : Dans chaque cas, vérifiez que l’appliance NetScaler ADC prend en charge les chiffrements que vous souhaitez utiliser pour la communication.

Configurer PFS à l’aide d’un profil SSL

Remarque : L’option permettant de configurer PFS (chiffrement ou ECC) à l’aide d’un profil SSL est introduite à partir de la version 11.0 64.x. Ignorez la section suivante si vous utilisez des versions antérieures.

Pour activer PFS à l’aide d’un profil SSL, une configuration similaire (comme expliqué dans les sections de configuration précédentes) doit être effectuée mais sur le profil SSL au lieu de la configurer directement sur un serveur virtuel.

Configurer PFS à l’aide d’un profil SSL à l’aide de l’interface graphique

1. Liez les courbes ECC et les chiffrements ECDHE sur le profil SSL.

   Remarque : les courbes ECC sont déjà liées par défaut à tous les profils SSL.

   a. Accédez à Système > Profils > Profils SSL et choisissez le profil sur lequel vous souhaitez activer PFS.

   b. Liez les chiffrements ECDHE.

2. Liez le profil SSL au serveur virtuel.

   a. Accédez à Configuration > Gestion du trafic > Serveurs virtuels et sélectionnez le serveur virtuel.

   b. Cliquez sur l’icône crayon pour modifier le profil SSL.

   c. Cliquez sur OK, puis sur Terminé.

Configurer PFS avec SSL à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

1. Liez les courbes ECC au profil SSL.

   bind sslprofile <SSLProfileName> -eccCurveName <Name_of_curve>
   <!--NeedCopy-->
   

2. Liez le groupe de chiffrement ECDHE.

   bind sslprofile <SSLProfileName> cipherName <ciphergroupName>
   <!--NeedCopy-->
   

3. Définissez la priorité du chiffrement ECDHE sur 1.

   set sslprofile <SSLProfileName> cipherName <ciphergroupName> cipherPriority <positive_integer>
   <!--NeedCopy-->
   

4. Liez le profil SSL au serveur virtuel.

   set SSL vserver <vservername> sslProfile <SSLProfileName>
   <!--NeedCopy-->