Sécuriser

Dans cet article :

Pour sécuriser les communications entre votre batterie de serveurs et Citrix Receiver, vous pouvez intégrer vos connexions Citrix Receiver à la batterie de serveurs grâce à un large choix de technologies de sécurité, dont :

  • Un serveur proxy SOCKS ou serveur proxy sécurisé (également appelé serveur proxy, serveur proxy HTTPS ou serveur proxy de tunneling TLS). Vous pouvez utiliser les 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 Receiver et les serveurs. Receiver prend en charge les protocoles de proxy SOCKS et de proxy sécurisé.
  • Secure Gateway ou solutions de relais SSL avec protocoles TLS. Les versions TLS 1.0 à 1.2 sont prises en charge.
  • 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 Receiver 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.

Connexion via un 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 Citrix Receiver et votre déploiement Citrix XenApp ou Citrix XenDesktop. Citrix Receiver prend en charge le protocole SOCKS, de même que Secure Gateway et le Relais SSL Citrix, le protocole proxy sécurisé et l’authentification Stimulation/Réponse Windows NT (NTLM).

La liste des types de proxy pris en charge est limitée aux types Auto, None et Wpad par le contenu des fichiers Trusted_Regions.ini et Untrusted_Regions.ini. Si vous utilisez les types SOCKS, Secure ou Script, modifiez ces fichiers pour ajouter les types supplémentaires à la liste des types autorisés.

Remarque

Pour garantir l’établissement d’une connexion sécurisée, activez le protocole TLS.

Connexion via un 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 la fonctionnalité NTLM requiert la présence de la bibliothèque OpenSSL (libcrypto.so) sur la machine utilisateur. Cette bibliothèque est généralement incluse dans les distributions Linux. Le cas échéant, elle est également téléchargeable à l’adresse http://www.openssl.org/.

Connexion avec Secure Gateway ou le Relais SSL Citrix

Vous pouvez intégrer Receiver avec Secure Gateway ou le service Relais SSL (Secure Sockets Layer) Citrix. Receiver 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 cryptage 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.

Connexion avec la passerelle Secure Gateway

Vous pouvez utiliser la passerelle Secure Gateway en mode Normal ou en mode Relais afin de fournir un canal sécurisé de communication entre Citrix Receiver et le serveur. Il n’est pas nécessaire de configurer Citrix Receiver si vous utilisez la passerelle Secure Gateway en mode Normal et si les utilisateurs se connectent via l’Interface Web.

Citrix Receiver utilise des paramètres configurés à distance sur le serveur exécutant l’Interface Web pour se connecter aux serveurs exécutant Secure Gateway. Pour plus d’informations sur la configuration des paramètres de serveur proxy pour Citrix Receiver, veuillez consulter la documentation de l’Interface Web.

Si le proxy Secure Gateway est installé sur un serveur dans le réseau sécurisé, vous pouvez l’utiliser en mode Relais. Pour plus d’informations, veuillez consulter la documentation de XenApp (Secure Gateway).

Si vous utilisez le mode Relais, le serveur Secure Gateway fonctionne comme un serveur proxy. Dans ce cas, vous devez configurer Citrix Receiver pour qu’il utilise :

  • le nom de domaine complet du serveur Citrix Secure Gateway ;
  • le numéro de port du serveur Citrix Secure Gateway. Le mode Relais n’est pas pris en charge par Secure Gateway, version 2.0.

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 tête (com). La combinaison du domaine intermédiaire et du domaine de tête (mon_entreprise.com) est appelée nom de domaine.

Connexion avec le Relais SSL Citrix

Par défaut, le Relais SSL Citrix utilise le port TCP 443 du serveur XenApp 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 auprès de Citrix Receiver.

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

  • Entre une machine utilisateur et un serveur sur lesquels TLS est activé.
  • Avec l’Interface Web, entre le serveur XenApp et le serveur Web.

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 XenApp. Pour obtenir des informations sur la configuration de l’Interface Web en vue d’utiliser le cryptage TLS, veuillez consulter la documentation de l’Interface Web.

Configuration et activation de TLS

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.0
  • MaximumTLS=1.2

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

Remarque : ces valeurs sont lues chaque fois qu’un programme démarre. Si vous les modifiez après le démarrage de selfservice ou storebrowse, tapez : killall AuthManagerDaemon ServiceRecord selfservice storebrowse.

Remarque : Citrix Receiver pour Linux n’autorise pas l’utilisation du protocole SSLv3.

Citrix Receiver pour Linux prend en charge DTLS 1.0 et TLS 1.0, 1.1 et 1.2, avec les suites de chiffrement suivantes :

  • RSA+AES256-SHA (RSA pour l’échange de clés, AES 256 pour le cryptage, SHA-1 pour le digest)
  • RSA+AES256-SHA256 (RSA pour l’échange de clés, AES 256 pour le cryptage, SHA-256 pour le digest)
  • RSA+AES128-SHA (RSA pour l’échange de clés, AES 128 pour le cryptage, SHA-1 pour le digest)
  • RSA+DES-CBC3-SHA (RSA pour l’échange de clés, Triple DES pour le cryptage, SHA-1 pour le digest)
  • RSA+RC4128-MD5 (RSA pour l’échange de clés, RC4 128 pour le cryptage, MD5 pour le digest)
  • RSA+RC4128-SHA (RSA pour l’échange de clés, RC4 128 pour le cryptage, SHA-1 pour le digest)
  • RSA+AES128_GCM+SHA256 (RSA pour l’échange de clés, AES 128 pour le cryptage, SHA-256 pour le digest)
  • RSA+AES256_GCM+SHA384 (RSA pour l’échange de clés, AES 256 pour le cryptage, SHA-384 pour le digest)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Diffie-Hellman à courbe elliptique pour l’échange de clés, RSA pour l’authentification, AES 256 et GCM SHA 384 pour le digest)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Diffie-Hellman à courbe elliptique pour l’échange de clés, RSA pour l’authentification, AES 256 et CBC SHA 384 pour le digest)
  • TLS_RSA_AES256_CBC_SHA256 (RSA pour l’authentification, AES 256 et CBC SHA 256 pour le digest)

La taille réelle de la clé de cryptage est telle que définie ci-dessus pour cette suite de chiffrement SSL/TLS standard :

  • Algorithme RC4 : 128 bits (chiffrement de flux)
  • Algorithme triple DES : 3x64 bits (taille réelle 3x56 = 168 bits) (taille de bloc 64 bits)
  • Algorithme AES : 128 bits ou 256 bits (taille de bloc 128 bits)
  • Pour l’échange de clés RSA et l’authentification, la plage de longueurs de clé prises en charge (module) va de 1 024 bits à 4 096 bits.
  • Pour l’échange de clés ECDH, les courbes elliptiques prises en charge sont NIST P-256 et NIST P-384 (longueurs de clé de 256 et 384 bits).

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 valeur après le démarrage de selfservice ou storebrowse, vous devez taper : killall AuthManagerDaemon ServiceRecord selfservice storebrowse

Installation de certificats racine sur des machines utilisateur

Pour utiliser le protocole TLS, vous devez disposer d’un certificat racine sur la machine cliente permettant de vérifier la signature de l’autorité de certification apposée sur le certificat du serveur. Par défaut, Citrix Receiver prend en charge les certificats suivants.

Certificat Autorité émettrice
Class4PCA_G2_v2.pem VeriSign Trust Network
Class3PCA_G2_v2.pem VeriSign Trust Network
BTCTRoot.pem Baltimore Cyber Trust Root
GTECTGlobalRoot.pem GTE Cyber Trust Global Root
Pcs3ss_v4.pem Class 3 Public Primary Certification Authority
GeoTrust_Global_CA.pem GeoTrust
DigiCertGlobalRootCA.pem DigiCert Global Root CA

Il n’est pas nécessaire d’obtenir et d’installer des certificats racine sur les machines utilisateur pour pouvoir utiliser des certificats émis par ces autorités de certification. Cependant, si vous choisissez d’utiliser une autorité de certification différente, vous devez alors obtenir un certificat racine auprès de celle-ci, que vous installez ensuite sur chaque machine utilisateur.

Citrix Receiver pour Linux prend en charge les clés RSA de longueur 1024, 2048 et 3072. Les certificats racine avec des clés RSA de longueur de 4 096 bits sont aussi pris en charge.

Remarque : Receiver pour Linux 13.0 utilise c_rehash à partir de la machine locale. La version 13.1 et les versions suivantes utilisent l’outil ctx_rehash comme décrit dans les étapes suivantes.

Utiliser un certificat racine

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 la machine 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

Utiliser un certificat intermédiaire

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

Activation de la prise en charge des cartes à puce

Citrix Receiver pour Linux assure la prise en charge de différents lecteurs de carte à puce. Si la prise en charge des cartes à puce est activée à la fois sur le serveur et sur Receiver, vous pouvez utiliser des cartes à puce aux fins suivantes :

  • Authentification d’ouverture de session par carte à puce. Servez-vous de cartes à puce pour authentifier les utilisateurs auprès des serveurs Citrix XenApp.
  • Prise en charge des applications recourant à une carte à puce. Autorisez les applications recourant à une carte à puce à accéder aux lecteurs de carte à puce locaux.

Les données de carte à puce sont sensibles en matière de sécurité et doivent être transmises au moyen d’un canal authentifié sécurisé (TLS, par exemple).

Pré-requis de la prise en charge des cartes à puce :

  • Les lecteurs de carte à puce et les applications publiées doivent être conformes aux normes PC/SC de l’industrie.
  • Installez le pilote approprié au lecteur de carte à puce.
  • Installez le package PC/SC Lite.
  • Installez et exécutez le démon pcscd, qui fournit le middleware permettant d’accéder à la carte à puce à l’aide de PC/SC.
  • Sur un système 64 bits, les versions 64 bits et 32 bits du package « libpscslite1 » doivent être présentes.

Important : si vous utilisez le terminal SunRay avec le logiciel serveur SunRay version 2.0 ou ultérieure, installez le package de contournement SRCOM PC/SC, disponible au téléchargement à l’adresse http://www.sun.com/.

Pour plus d’informations sur la configuration de la prise en charge des cartes à puce sur vos serveurs, veuillez consulter la documentation de XenApp et XenDesktop.

Connexion via NetScaler Gateway

Citrix NetScaler Gateway (anciennement Access Gateway) sécurise les connexions aux magasins StoreFront, et permet aux administrateurs de contrôler, de façon détaillée, l’accès utilisateur aux bureaux et applications.

Pour se connecter à des bureaux et des applications via NetScaler Gateway

  1. Spécifiez l’URL NetScaler Gateway qui vous a été fournie par votre administrateur. Vous pouvez effectuer cette opération 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 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 que Receiver détecte, utilisez une URL au format https://gateway.company.com
    • Pour vous connecter à un magasin spécifique, utilisez une URL au format https://gateway.company.com?<nommagasin>. 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 NetScaler Gateway.

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

Configuration des suites de chiffrement obsolètes

Les suites de chiffrement avec le préfixe TLS_RSA_ ne proposent pas la fonctionnalité Forward Secrecy. De manière générale, ces suites de chiffrement sont maintenant obsolètes dans le secteur. Toutefois, pour prendre en charge la rétrocompatibilité avec les anciennes versions de XenApp et XenDesktop, Receiver pour Linux peut utiliser ces suites de chiffrement.

Des drapeaux ont été créés pour permettre l’utilisation de suites de chiffrement obsolètes. Dans Receiver pour Linux 13.10, ces indicateurs sont activés par défaut, mais n’appliquent pas la fin de prise en charge des suites de chiffrement à l’aide d’algorithmes de chiffrement AES ou 3DES par défaut. Toutefois, vous pouvez modifier et utiliser ces indicateurs pour appliquer la fin de prise en charge de manière plus stricte.

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 plus d’informations sur la configuration DTLS v1.2, consultez la section Transport adaptatif.

Conditions préalables

Pour configurer cette fonctionnalité sur le client, effectuez l’étape suivante :

Si .ICAClient est déjà présent dans le dossier 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’est pas présent dans le dossier de base, cela indique une nouvelle installation de Receiver. Dans ce cas, le paramètre par défaut des fonctionnalités est conservé.

Pour configurer les suites de chiffrement obsolètes

  1. Ouvrez le fichier $ICAROOT/config/All_Regions.ini.
  2. Dans la section Network\SSL, utilisez les trois indicateurs suivants pour activer ou désactiver les suites de chiffrement obsolètes :

    • Enable_TLS_RSA_ : par défaut, l’indicateur Enable_TLS_RSA_ est défini sur True.
      Définissez l’indicateur Enable_TLS_RSA_ sur true pour afficher les suites de chiffrement suivantes :

      • 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

    Important

    Définissez l’indicateur Enable_TLS_RSA_ sur true pour utiliser les deux autres suites de chiffrement Enable_RC4-MD5 et Enable_RC4_128_SHA.

    • Enable_RC4-MD5 : par défaut, l’indicateur Enable_RC4-MD5 est défini sur False.
      Définissez cet indicateur sur true pour activer la suite de chiffrement RC4-MD5.
    • Enable_RC4_128_SHA : par défaut, l’indicateur Enable_RC4_128_SHA est défini sur False.
      Définissez cet indicateur sur true pour activer la suite de chiffrement RC4_128_SHA.
  3. Enregistrez le fichier.

Le tableau suivant répertorie les suites de chiffrement compris dans chaque ensemble :

image localisée

Important

À l’avenir, Citrix ne prendra en charge que les trois suites de chiffrement suivantes :

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS 1.2 / DTLS 1.2, GOV / TOUS
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS 1.2 / DTLS 1.2, GOV / TOUS
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS 1.0 / 1.1 / 1.2, DTLS 1.0 / 1.2 COM / TOUS

Remarque

Toutes les suites de chiffrement ci-dessus 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.