Chiffrements disponibles sur les appliances NetScaler

Votre appliance NetScaler 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

• Depuis la version 13.0 build 71.x et les versions ultérieures, l’accélération matérielle TLS1.3 est prise en charge sur les plates-formes suivantes :

  • MPX 5900
  • MPX/SDX 8900
  • MPX/SDX 9100
  • MPX/SDX 15000
  • MPX/SDX 15000-50G
  • MPX/SDX 16000
  • MPX/SDX 26000
  • MPX/SDX 26000-50S

  • MPX/SDX 26000-100G

  • La prise en charge logicielle uniquement du protocole TLSv1.3 est disponible sur toutes les autres appliances NetScaler MPX et SDX, à l’exception des appliances NetScaler FIPS.

• TLSv1.3 n’est pris en charge qu’avec le profil amélioré. Pour activer le profil amélioré, voir Activer le profil amélioré.

• Pour utiliser TLS1.3, vous devez utiliser un client conforme à la spécification RFC 8446.

• Le chiffrement RC4 n’est pas inclus dans le groupe de chiffrement par défaut de l’appliance NetScaler. 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 plateformes NetScaler et sur les modules matériels de sécurité (HSM) externes :

• Appliance NetScaler MPX/SDX Intel Lewisburg : prise en charge du chiffrement sur une appliancebasée sur une puce SSL Intel Lewisburg NetScaler MPX/SDX
• Appliance NetScaler MPX/SDX (N3): prise en charge du chiffrement sur une appliance NetScaler MPX/SDX (N3)
• Appliance Intel Coleto NetScaler MPX/SDX : prise en charge du chiffrement sur une appliancebasée sur une puce SSL NetScaler MPX/SDX Intel Coleto
• Appliance NetScaler VPX  : prise en charge du chiffrement sur une appliance NetScaler VPX
• ApplianceNetScaler MPX/SDX 14000 FIPS : prise en charge du chiffrementsur une appliance FIPSNetScaler MPX/SDX 14000
• HSM externe (Thales/Safenet) : chiffrement pris en charge sur un HSM externe (Thales/Safenet)
• ApplianceNetScaler MPX/SDX (N2) : prise en charge du chiffrement surune applianceNetScaler MPX/SDX (N2)
• Appliance NetScaler MPX 9700 FIPS : prise en charge du chiffrement sur unNetScaler MPX 9700 FIPSavec microprogramme 2.2
• Appliances CITRIX VPX FIPS et MPX FIPS : prise en charge du chiffrement sur les appliances certifiées NetScaler VPX FIPS et MPX FIPS

Remarque :

Pour la prise en charge du chiffrement DTLS, consultez la section Prise en charge du chiffrement DTLS sur les appliances NetScaler VPX, MPX et SDX.

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

|Protocole/Plate-forme|MPX/SDX (N2)|MPX/SDX (N3)|VPX|MPX/SDX 14000** FIPS|MPX 5900/8900 MPX 15000-50 G MPX 26000-100 G| |—|—|—|—|—|—| | TLS 1.3 | 13.1 toutes les versions | 13.1 toutes les versions | 13.1 toutes les versions | Non pris en charge | 13.1 toutes les versions | ||13.0 toutes les versions | 13.0 toutes les versions | 13.0 toutes les versions | Non pris en charge | 13.0 toutes les versions | || 12,1—50,x (sauf TLS1.3-CHACHA20-POLY1305-SHA256)| 12,1—50,x (sauf TLS1.3-CHACHA20-POLY1305-SHA256)| 12.1–50.x | Non pris en charge | 12.1–50.x | | TLS 1.1/1.2 | 13.1 toutes les versions | 13.1 toutes les versions | 13.1 toutes les versions | 13.1 toutes les versions | 13.1 toutes les versions | || 13.0 toutes les versions | 13.0 toutes les versions | 13.0 toutes les versions | 13.0 toutes les versions | 13.0 toutes les versions | || 12.1 toutes les versions | 12.1 toutes les versions | 12.1 toutes les versions | 12.1 toutes les versions | 12.1 toutes versions pour MPX 5900/8900, 12.1-50.x pour MPX 15000-50G et MPX 26000-100G | || 12.0 toutes les versions | 12.0 toutes les versions | 12.0 toutes les versions | 12.0 toutes les versions | 12.0 toutes les versions pour MPX 5900/8900, 12,0 à 57. x pour MPX 15000-50G, 12,0 à 60,x pour MPX 26000-100G | || 11.1 all builds | 11.1 all builds |11.1 all builds | 11.1–56.x for MPX 5900/8900 and MPX 15000-50G, 11.1-60.x for MPX 26000-100G | || 11.0 all builds | 11.0 all builds | 11.0 all builds | 11.0 all builds | 11.0–70.x (only on MPX 5900/8900) | || 10.5 all builds | 10.5 all builds | 10.5–57.x | 10.5–59.1359.e | 10.5–67.x, 10.5-63.47 (only on MPX 5900/8900) | | ECDHE/DHE (Example TLS1-ECDHE-RSA-AES128-SHA)|13.1 all builds |13.1 all builds | 13.1 all builds | 13.1 all builds | 13.1 all builds| || 13.0 all builds | 13.0 all builds | 13.0 all builds | 13.0 all builds |13.0 all builds| ||12.1 all builds | 12.1 all builds | 12.1 all builds | 12.1 all builds | 12.1 all builds for MPX 5900/8900, 12.1-50.x for MPX 15000-50G and MPX 26000-100G | || 12.0 all builds | 12.0 all builds | 12.0 all builds | 12.0 all builds | 12.0 all builds for MPX 5900/8900, 12.0-57.x for MPX 15000-50G, 12.0-60.x for MPX 26000-100G | || 11.1 all builds|11.1 all builds | 11.1 all builds | 11.1–51.x |11.1–56.x for MPX 5900/8900 and MPX 15000-50G, 11.1-60.x for MPX 26000-100G | || 11.0 all builds | 11.0 all builds | 11.0 all builds||11.0–70.114 (only on MPX 5900/8900) | || 10.5–53.x| 10.5–53.x| 10.5 all builds|| 10.5–67.x, 10.5-63.47 (only on MPX 5900/8900) | |AES-GCM (Example TLS1.2-AES128-GCM-SHA256) | 13.1 all builds | 13.1 all builds|13.1 all builds | 13.1 all builds | 13.1 all builds | ||13.0 all builds | 13.0 all builds | 13.0 all builds | 13.0 all builds | 13.0 all builds | || 12.1 all builds | 12.1 all builds | 12.1 all builds|12.1 all builds | 12.1 all builds for MPX 5900/8900, 12.1-50.x for MPX 15000-50G and MPX 26000-100G | || 12.0 all builds|12.0 all builds | 12.0 all builds|12.0 all builds | 12.0 all builds for MPX 5900/8900, 12.0-57.x for MPX 15000-50G, 12.0-60.x for MPX 26000-100G | || 11.1 all builds | 11.1 all builds | 11.1 all builds | 11.1–51.x (See note) | 11.1–56.x for MPX 5900/8900 and MPX 15000-50G, 11.1-60.x for MPX 26000-100G | ||11.0 all builds|11.0 all builds|11.0–66.x||11.0–70.114 (only on MPX 5900/8900) | ||10.5–53.x|10.5–53.x|||10.5–67.x, 10.5-63.47 (only on MPX 5900/8900) | |SHA-2 Ciphers (Example TLS1.2-AES-128-SHA256)| 13.1 all builds|13.1 all builds|13.1 all builds|13.1 all builds|13.1 all builds | ||13.0 all builds|13.0 all builds|13.0 all builds|13.0 all builds|13.0 all builds | ||12.1 all builds|12.1 all builds|12.1 all builds|12.1 all builds|12.1 all builds for MPX 5900/8900, 12.1-50.x for MPX 15000-50G and MPX 26000-100G | || 12.0 all builds | 12.0 all builds | 12.0 all builds | 12.0 all builds | 12.0 all builds for MPX 5900/8900, 12.0-57.x for MPX 15000-50G, 12.0-60.x for MPX 26000-100G | || 11.1 all builds | 11.1 all builds | 11.1 all builds | 11.1–52.x | 11.1–56.x for MPX 5900/8900 and MPX 15000-50G, 11.1-60.x for MPX 26000-100G | || 11.0 all builds | 11.0 all builds | 11.0–66.x || 11.0–72.x, 11.0-70.114 (only on MPX 5900/8900) | || 10.5–53.x | 10.5–53.x ||| 10.5–67.x, 10.5-63.47 (only on MPX 5900/8900) | | ECDSA (Example TLS1-ECDHE-ECDSA-AES256-SHA) | Not supported | 13.1 all builds | 13.1 all builds | 13.1 all builds | 13.1 all builds | || Not supported | 13.0 all builds | 13.0 all builds | 13.0 all builds | 13.0 all builds | || Not supported | 12.1 all builds | 12.1 all builds | 12.1 all builds | 12.1 all builds for MPX 5900/8900, 12.1-50.x for MPX 15000-50G and MPX 26000-100G | || Not supported | 12.0 all builds | 12.0-57.x | Not supported | 12.0 all builds for MPX 5900/8900, 12.0-57.x for MPX 15000-50G, 12.0-60.x for MPX 26000-100G | ||| 11.1 all builds ||| 11.1–56.x, 11.1-54.126 (Only ECC curves P_256 and P_384 are supported.) | | CHACHA20 | Not supported | 13.1 all builds | 13.1 all builds | Not supported | 13.1 all builds | ||Not supported | 13.0 all builds | 13.0 all builds | Not supported | 13.0 all builds | || Not supported | Not supported | 12.1 all builds | Not supported | 12.1–49.x (only on MPX 5900/8900) | || Not supported | Not supported | 12.0–56.x | Not supported | Not supported |

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.

Remarques

• 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 NetScaler

Le PFS peut être configuré sur un NetScaler 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 NetScaler 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-->