Suites de chiffrement disponibles sur les appliances Citrix ADC

Votre appliance Citrix 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 Citrix 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 Citrix ADC et sur des modules de sécurité matérielle externes (HSM) :

• Appliance Citrix ADC MPX/SDX Intel Lewisburg : prise en charge du chiffrement sur une appliancebasée sur une puce SSL Intel Lewisburg Citrix MPX/SDX
• Appliance Citrix ADC MPX/SDX (N3): prise en charge du chiffrement sur une appliance Citrix ADC MPX/SDX (N3)
• Appliance Intel Coleto Citrix ADC MPX/SDX : prise en charge du chiffrement sur une appliancebasée sur une puce SSL Citrix ADC MPX/SDX Intel Coleto
• Appliance Citrix ADC VPX : prise en charge du chiffrement sur une appliance Citrix ADC VPX
• Appliance FIPS Citrix ADC MPX/SDX 14000: prise en charge du chiffrement sur une appliance FIPS Citrix ADC MPX/SDX 14000
• HSM externe (Thales/Safenet) : chiffrement pris en charge sur un HSM externe (Thales/Safenet)
• Appliance Citrix ADC MPX/SDX (N2) : prise en charge du chiffrement sur une appliance Citrix ADC MPX/SDX (N2)
• Appliance FIPS Citrix ADC MPX 9700 : prise en charge du chiffrement sur une Citrix 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 Citrix 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 Citrix 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 tous les dispositifs à 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 poignée de main SSL qui a lieu 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 de l’approche d’échange de clés RSA est que si un attaquant parvient à obtenir la clé privée du serveur à tout moment dans le futur, il 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. Par conséquent, votre communication SSL historique qui était sécurisée auparavant n’est plus sécurisée car la clé privée volée du serveur peut être utilisée pour atteindre la clé de session et ainsi décrypter également 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. La configuration de Perfect Forward Secrecy (PFS) permet de résoudre ce problème.

Comment PFS aide-t-il ?

PFS protège la communication SSL passée en demandant au client et au serveur de convenir d’une nouvelle clé pour chaque session et en gardant secret le calcul de cette clé de session. 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 accède à la clé privée du serveur, il ne sera pas en mesure d’accéder à la clé de session. Par conséquent, ils ne seraient 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 obtient la clé privée du serveur, il ne peut pas accéder à la clé de session. La raison en est que la clé de session et les nombres 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 sur le réseau. 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’autre côté de la création d’une clé pour chaque session est qu’elle nécessite un calcul supplémentaire. Cependant, ce problème peut être résolu en utilisant la courbe elliptique dont les tailles de clé sont plus petites.

Configurer PFS sur l’appliance Citrix ADC

PFS peut être configuré sur un Citrix 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 Chiffrements SSL, sélectionnez les groupes de chiffrement DHE et 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 Citrix 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-->