Sécuriser les communications

Pour sécuriser les communications entre votre site et l’application Citrix Workspace, vous pouvez intégrer vos connexions via l’application Citrix Workspace à l’aide de technologies sécurisées telles que Citrix Gateway :

Remarque :

Citrix recommande d’utiliser Citrix Gateway entre les serveurs StoreFront et les machines utilisateur.

• Un pare-feu : les pare-feu de réseau peuvent autoriser ou empêcher le passage des paquets de données en fonction de l’adresse et du port de destination. Si vous utilisez l’application Citrix Workspace avec un pare-feu de réseau qui mappe l’adresse IP interne du serveur sur une adresse Internet externe (c’est-à-dire, la traduction d’adresse de réseau, ou NAT), configurez l’adresse externe.

• Serveur approuvé.

• Pour les déploiements de Citrix Virtual Apps and Desktops ou Citrix DaaS (anciennement Citrix Virtual Apps and Desktops Service) uniquement (non applicable à XenDesktop 7) : un serveur proxy SOCKS ou serveur proxy sécurisé (également appelé serveur proxy de sécurité, serveur proxy HTTPS ou serveur proxy de tunneling TLS). Vous pouvez utiliser des serveurs proxy pour limiter l’accès à l’intérieur et à l’extérieur de votre réseau, et pour gérer les connexions entre l’application Citrix Workspace et les serveurs. L’application Citrix Workspace prend en charge les protocoles de proxy SOCKS et de proxy sécurisé.

• Pour les déploiements Citrix Virtual Apps and Desktops ou Citrix DaaS : Citrix Secure Web Gateway ou solutions de relais SSL avec protocoles TLS. Les versions TLS 1.0 à 1.2 sont prises en charge.

Citrix Gateway

Citrix Gateway (anciennement Access Gateway) sécurise les connexions aux magasins StoreFront. Ce service permet également aux administrateurs de contrôler, de manière détaillée, l’accès des utilisateurs aux bureaux et aux applications.

Pour se connecter à des bureaux et des applications via Citrix Gateway :

1. Spécifiez l’URL de Citrix Gateway qui vous a été fournie par votre administrateur de l’une des manières suivantes :

   • La première fois que vous utilisez l’interface utilisateur en libre-service, vous êtes invité à entrer l’adresse URL dans la boîte de dialogue Ajouter un compte.
   • Lorsque vous utilisez l’interface utilisateur en libre-service ultérieurement, entrez l’URL en cliquant sur Préférences > Comptes > Ajouter.
   • Si vous établissez une connexion avec la commande storebrowse, entrez l’adresse URL sur la ligne de commande.

   L’URL spécifie la passerelle et, éventuellement, un magasin spécifique :

   • Pour vous connecter au premier magasin détecté par l’application Citrix Workspace, utilisez une URL au format suivant par exemple : https://gateway.company.com.
   • Pour vous connecter à un magasin spécifique, utilisez une URL au format https://gateway.company.com?<\nommagasin\> par exemple. Le format de cette URL dynamique n’est pas un format standard ; n’incluez pas le signe égal = dans l’URL. Si vous établissez une connexion à un magasin spécifique avec storebrowse, vous devrez peut-être utiliser des guillemets autour de l’URL dans la commande storebrowse.

2. Lorsque vous y êtes invité, connectez-vous au magasin (via la passerelle) à l’aide de votre nom d’utilisateur, mot de passe et de jeton de sécurité. Pour de plus amples informations sur cette étape, consultez la documentation de Citrix Gateway.

   Lorsque l’authentification est terminée, vos bureaux et applications sont affichés.

Serveur proxy

Les serveurs proxy permettent de limiter l’accès à l’intérieur comme à l’extérieur du réseau, et de gérer les connexions établies entre l’application Citrix Workspace et votre déploiement Citrix Virtual Apps and Desktops ou Citrix DaaS.

L’application Citrix Workspace prend en charge les protocoles SOCKS et HTTPS, ainsi que les éléments suivants :

• Citrix Secure Web Gateway et le Relais SSL Citrix, le protocole proxy sécurisé
• Authentification Stimulation/Réponse Windows NT (NTLM)

Pour configurer un proxy afin de lancer un bureau à l’aide du protocole SOCKS, procédez comme suit :

1. Accédez au fichier de configuration ~/.ICAClient/All_Regions.ini.

2. Mettez à jour les attributs suivants :

   1. Mettez à jour ProxyType. Vous pouvez utiliser SocksV5 comme ProxyType.

   2. Mettez à jour ProxyHost. Vous pouvez ajouter ProxyHost au format suivant :

      <IP>:<PORT>. Par exemple « 10.122.122.122:1080 ».

Remarque :

• Pour utiliser le proxy, désactivez EDT. Pour désactiver EDT, définissez l’attribut HDXoverUDP sur off dans la section [Network\UDT] du fichier de configuration ~/.ICAClient/All_Regions.ini.
• Pour garantir l’établissement d’une connexion sécurisée, activez le protocole TLS.

Prise en charge du protocole HTTPS pour le serveur proxy

Auparavant, vous pouviez vous connecter à un serveur proxy uniquement à l’aide du protocole SOCKS. À partir de l’application Citrix Workspace 2308, vous pouvez également vous connecter à un serveur proxy à l’aide du protocole HTTPS.

Pour ouvrir un bureau à l’aide du protocole HTTPS, procédez comme suit :

1. Accédez au fichier de configuration ~/.ICAClient/All_Regions.ini.
2. Accédez à la section [Network\UDT].

3. Définissez les paramètres suivants :

   HDXoverUDP=Off
   <!--NeedCopy-->
   

4. Accédez à la section [Network\Proxy].

5. Mettez à jour les attributs suivants :

   • Mettez à jour le champ ProxyType. Vous pouvez utiliser Secure comme ProxyType.
   • Mettez à jour le champ ProxyHost. Vous pouvez ajouter ProxyHost au format suivant :

   <IP>:<PORT>. Par exemple, « 192.168.101.37:6153 ».

Serveur proxy sécurisé

La configuration de connexions utilisant le protocole de proxy sécurisé assure également la prise en charge de l’authentification Stimulation/Réponse Windows NT (NTLM). Si ce protocole est disponible, il est détecté et utilisé au moment de l’exécution sans nécessiter de configuration supplémentaire.

Important :

La prise en charge de NTLM nécessite les bibliothèques OpenSSL 1.1.1d et libcrypto.so. Installez les bibliothèques sur la machine utilisateur. Ces bibliothèques sont souvent incluses dans les distributions Linux. Vous pouvez également les télécharger depuis http://www.openssl.org/.

Secure Web Gateway et SSL

Vous pouvez intégrer l’application Citrix Workspace avec Citrix Secure Web Gateway ou le service Relais SSL (Secure Sockets Layer) Citrix. L’application Citrix Workspace prend en charge le protocole TLS. TLS (Transport Layer Security) est la dernière version normalisée du protocole SSL. Le groupe de travail Internet Engineering Taskforce (IETF) l’a rebaptisé TLS lorsqu’il est devenu responsable du développement de SSL sous la forme d’une norme ouverte. TLS garantit la sécurité des communications de données grâce à l’authentification des serveurs, au chiffrement du flux de données et aux contrôles d’intégrité des messages. Certaines organisations, notamment des organisations gouvernementales américaines, requièrent l’utilisation du protocole TLS pour la sécurisation de leurs communications de données. Ces organisations peuvent nécessiter l’utilisation d’une cryptographie validée, comme la norme FIPS 140 (Federal Information Processing Standard). La norme FIPS 140 est une norme de cryptographie.

Secure Web Gateway

Vous pouvez utiliser Citrix Secure Web Gateway en mode Normal ou en mode Relais afin de fournir un canal de communication sécurisé entre l’application Citrix Workspace et le serveur. Si vous utilisez Secure Web Gateway en mode Normal, l’application Citrix Workspace ne nécessite aucune configuration.

Si Citrix Secure Web Gateway Proxy est installé sur un serveur dans le réseau sécurisé, vous pouvez l’utiliser en mode Relais. Si vous utilisez le mode Relais, le serveur Citrix Secure Web Gateway fonctionne comme un serveur proxy. Dans ce cas, vous devez configurer l’application Citrix Workspace pour qu’elle utilise :

• le nom de domaine complet du serveur Citrix Secure Web Gateway ;
• le numéro de port du serveur Citrix Secure Web Gateway.

Remarque :

Citrix Secure Web Gateway version 2.0 ne prend pas en charge le mode Relais.

Le nom de domaine complet (FQDN) doit contenir, dans l’ordre, les trois composants suivants :

• Nom d’hôte
• Domaine intermédiaire
• Domaine de tête

Par exemple : mon_ordinateur.mon_entreprise.com est un nom de domaine complet car il liste dans l’ordre un nom d’hôte (mon_ordinateur), un domaine intermédiaire (mon_entreprise) et un domaine de niveau supérieur (com). La combinaison du domaine intermédiaire et du domaine de tête (mon_entreprise.com) est appelée nom de domaine.

Relais SSL

Par défaut, le Relais SSL Citrix utilise le port TCP 443 sur le serveur Citrix Virtual Apps and Desktops ou Citrix DaaS pour les communications sécurisées TLS. Lorsque le Relais SSL reçoit une connexion TLS, il décrypte les données avant de les rediriger sur le serveur.

Si vous configurez le Relais SSL Citrix pour l’écoute sur un port autre que le port 443, vous devez spécifier le numéro du port d’écoute non standard dans l’application Citrix Workspace.

Le Relais SSL Citrix vous permet de sécuriser les communications suivantes.

• Entre une machine utilisateur et un serveur sur lesquels TLS est activé.

Pour obtenir des informations sur la configuration et l’utilisation du Relais SSL en vue de sécuriser l’installation, veuillez consulter la documentation de Citrix Virtual Apps.

TLS

Auparavant, la version minimale de TLS prise en charge était 1.0 et la version maximale de TLS prise en charge était 1.2. À compter de la version 2203, la version TLS maximale prise en charge est 1.3.

Vous pouvez contrôler les versions du protocole TLS qui peuvent être négociées en ajoutant les options de configuration suivantes dans la section [WFClient]:

• MinimumTLS=1.1
• MaximumTLS=1.3

Il s’agit des valeurs par défaut, qui sont implémentées en code. Modifiez-les comme bon vous semble.

Remarques :

• Ces valeurs sont lues chaque fois qu’un programme démarre. Si vous les modifiez après le démarrage de self-service ou storebrowse, entrez : killall AuthManagerDaemon ServiceRecord selfservice storebrowse.

• L’application Citrix Workspace pour Linux n’autorise pas l’utilisation du protocole SSLv3.

• TLS 1.0/1.1 fonctionne uniquement avec l’ancien VDI ou Citrix Gateway qui les prend en charge.

Pour sélectionner la suite de chiffrement, ajoutez l’option de configuration suivante dans la section [WFClient] :

• SSLCiphers=GOV

Il s’agit de la valeur par défaut. Les autres valeurs reconnues sont COM et ALL.

Remarque :

Tout comme avec la configuration de la version TLS, si vous changez cette configuration après le démarrage de self-service ou storebrowse, vous devez taper : killall AuthManagerDaemon ServiceRecord selfservice storebrowse

Mise à jour de CryptoKit

CryptoKit version 14.2 est intégré à la version 1.1.1d d’OpenSSL.

Mise à jour cryptographique

Cette fonctionnalité est un changement important au protocole de communication sécurisé. Les suites de chiffrement avec le préfixe TLS_RSA_ ne proposent pas la fonctionnalité Forward Secrecy et sont considérées comme faibles.

Les suites de chiffrement TLS_RSA_ ont été entièrement supprimées. Au lieu de cela, les suites de chiffrement TLS_ECDHE_RSA_ avancées sont prises en charge.

Si votre environnement n’est pas configuré avec la suite de chiffrement TLS_ECDHE_RSA_, les lancements de clients ne sont pas pris en charge en raison de la faiblesse du chiffrement. Pour l’authentification client, les clés RSA 1536 bits sont prises en charge.

Les suites de chiffrement avancées suivantes sont prises en charge :

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

DTLS v1.0 prend en charge les suites de chiffrement suivantes :

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

DTLS v1.2 prend en charge les suites de chiffrement suivantes :

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

TLS v1.3 prend en charge les suites de chiffrement suivantes :

• TLS_AES_128_GCM_SHA256 (0x1301)
• TLS_AES_256_GCM_SHA384 (0x1302)

Remarque :

À partir des versions 1903 et ultérieures, DTLS est pris en charge à partir de Citrix Gateway 12.1 et versions ultérieures. Pour plus d’informations sur les suites de chiffrement prises en charge par DTLS pour Citrix Gateway, voir Prise en charge du protocole DTLS.

Suites de chiffrement

Pour activer différentes suites de chiffrement, modifiez la valeur du paramètre SSLCiphers sur ALL, COM ou GOV. Par défaut, l’option est définie sur ALL dans le fichier All_Regions.ini du répertoire $ICAROOT/config.

Les ensembles suivants de suites de chiffrement sont fournis respectivement par ALL, GOV et COM :

• TOUT
  • les 3 chiffrements sont pris en charge.
• GOV
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
• COM
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

Pour plus d’informations sur le dépannage, consultez Suites de chiffrement.

Les suites de chiffrement avec le préfixe TLS_RSA_ ne proposent pas la fonctionnalité Forward Secrecy Ces suites de chiffrement sont maintenant obsolètes dans le secteur. Toutefois, pour prendre en charge la rétrocompatibilité avec les anciennes versions de Citrix Virtual Apps and Desktops ou Citrix DaaS, l’application Citrix Workspace peut utiliser ces suites de chiffrement.

Pour une meilleure sécurité, définissez l’indicateur Enable\_TLS\_RSA\_ sur False.

Voici une liste des suites de chiffrement obsolètes :

• TLS_RSA_AES256_GCM_SHA384
• TLS_RSA_AES128_GCM_SHA256
• TLS_RSA_AES256_CBC_SHA256
• TLS_RSA_AES256_CBC_SHA
• TLS_RSA_AES128_CBC_SHA
• TLS_RSA_3DES_CBC_EDE_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA

Remarque :

Les deux dernières suites de chiffrement utilisent l’algorithme RC4 et sont obsolètes parce qu’elles ne sont pas sécurisées. Vous pouvez également considérer la suite de chiffrement TLS_RSA_3DES_CBC_EDE_SHA comme étant obsolète. Vous pouvez utiliser ces indicateurs pour appliquer toutes ces suites obsolètes.

Pour de plus amples informations sur la configuration de DTLS v1.2, consultez la section Transport adaptatif dans la documentation de Citrix Virtual Apps and Desktops.

Conditions préalables :

Si vous utilisez les versions 1901 et antérieures, suivez les étapes suivantes :

Si .ICAClient est déjà présent dans le répertoire de base de l’utilisateur actuel :

• Supprimez le fichier All\_Regions.ini

Ou

• Pour conserver le fichier AllRegions.ini, ajoutez les lignes suivantes à la fin de la section [Network\SSL] :
  • Enable_RC4-MD5=
  • Enable_RC4_128_SHA=
  • Enable_TLS_RSA_=

Si le dossier .ICAClient n’existe pas dans le dossier de base de l’utilisateur actuel, cela indique une nouvelle installation de l’application Citrix Workspace. Dans ce cas, le paramètre par défaut des fonctionnalités est conservé.

Le tableau suivant répertorie les suites de chiffrement compris dans chaque ensemble : Tableau 1 - Matrice de prise en charge de la suite de chiffrement

Remarque :

Toutes les suites de chiffrement précédentes sont conformes aux normes FIPS- et SP800-52-. Les deux premières sont autorisées uniquement pour les connexions (D) TLS1.2. Consultez Tableau 1 - Matrice de prise en charge de la suite de chiffrement pour une représentation complète de la prise en charge de la suite de chiffrement.

Certificats

Lorsque vous utilisez un magasin avec l’authentification SAML (à l’aide du protocole AUTHv3), le message d’erreur suivant s’affiche : « Certificat TLS inacceptable ».

Ce problème se produit lorsque vous utilisez la version 1906 ou des versions ultérieures de l’application Citrix Workspace. Pour obtenir des instructions de dépannage, consultez les articles suivants du Centre de connaissances :

• CTX260336
• CTX231524
• CTX203362

Si votre serveur StoreFront ne peut pas fournir les certificats intermédiaires correspondant au certificat qu’il utilise, ou que vous installez des certificats intermédiaires pour prendre en charge des utilisateurs de cartes à puce, suivez ces étapes avant d’ajouter un magasin StoreFront :

1. Obtenez le ou les certificats intermédiaires séparément au format PEM.

   Conseil :

   Si vous ne trouvez aucun certificat de format PEM, utilisez l’utilitaire openssl pour convertir un certificat au format CRT en un fichier .pem.

2. En tant qu’utilisateur qui installe le package (généralement racine) :

   1. Copiez le ou les fichiers dans $ICAROOT/keystore/intcerts.

   2. Exécutez la commande suivante en tant qu’utilisateur qui a installé le package :

      $ICAROOT/util/ctx_rehash

Si vous authentifiez un certificat de serveur qui a été émis par une autorité de certification et qui n’a pas encore été approuvé par les machines utilisateur, suivez les instructions suivantes avant d’ajouter un magasin StoreFront :

1. Obtenez le certificat racine au format PEM. Conseil : si vous ne trouvez aucun certificat de ce format, utilisez l’utilitaire openssl pour convertir un certificat au format CRT en un fichier .pem.
2. En tant qu’utilisateur qui a installé le package (généralement racine) :

   1. Copiez le fichier dans $ICAROOT/keystore/cacerts.

   2. Exécutez la commande suivante :

      $ICAROOT/util/ctx_rehash

Améliorations apportées au protocole HDX Enlightened Data Transport (EDT)

Dans les versions antérieures, lorsque HDXoverUDP est défini sur Preferred, le transport de données via EDT est utilisé comme mode principal avec retour vers TCP.

À partir de la version 2103 de l’application Citrix Workspace, lorsque la fiabilité de session est activée, EDT et TCP sont tentés en parallèle lors des opérations suivantes :

• Connexion initiale
• Reconnexion de la fiabilité de session
• Reconnexion automatique des clients

Cette amélioration réduit le temps de connexion lorsque EDT est le mode préféré. Toutefois, le transport UDP sous-jacent requis n’est pas disponible et TCP doit être utilisé.

Par défaut, après le repli vers TCP, le transport adaptatif continue d’interroger EDT toutes les 5 minutes.

Découverte MTU EDT (Enlightened Data Transport)

L’application Citrix Workspace version 2109 prend désormais en charge la découverte MTU (unité de transmission maximale) dans Enlightened Data Transport (EDT). Cela augmente la fiabilité et la compatibilité du protocole EDT et optimise l’expérience utilisateur.

Pour plus d’informations, consultez la section Découverte MTU EDT dans la documentation de Citrix Virtual Apps and Desktops.

Prise en charge d’EDT IPv6

À partir de la version 2203 de l’application Citrix Workspace, EDT IPv6 est pris en charge.

Remarque :

IPv6 est pris en charge à la fois pour TCP et EDT. Cependant, IPv6 n’est pas pris en charge pour TCP over TLS et pour EDT over DTLS.

Prise en charge d’UDP IPv6 avec DTLS

Auparavant, les connexions DTLS entre l’application Citrix Workspace pour Linux et les Virtual Delivery Agent (VDA) étaient prises en charge uniquement sur le réseau IPv4.

À partir de la version 2311, l’application Citrix Workspace prend en charge les connexions DTLS via IPv4 et IPv6.

Cette fonctionnalité est activée par défaut.

Aucune configuration supplémentaire n’est requise lorsque vous utilisez une connexion directe IPv6 DTLS avec des VDA sur l’application Citrix Workspace pour Linux.

Prise en charge de TCP IPv6 avec TLS

Auparavant, les connexions TLS entre l’application Citrix Workspace pour Linux et les Virtual Delivery Agent (VDA) étaient prises en charge uniquement sur le réseau IPv4.

À partir de la version 2311, l’application Citrix Workspace prend en charge les connexions TLS via IPv4 et IPv6.

Cette fonctionnalité est activée par défaut.

Aucune configuration supplémentaire n’est requise lorsque vous utilisez une connexion directe TLS IPv6 avec des VDA sur l’application Citrix Workspace pour Linux.