Le protocole SSL (Secure Sockets Layer) est un système permettant de chiffrer automatiquement les informations transmises sur Internet, puis de les déchiffrer avant de les utiliser. Cela permet de protéger les données confidentielles telles que les numéros de cartes de crédit lors de leur transmission via Internet.
Caching Proxy utilise le protocole SSL pour sécuriser les serveurs de remplacement et l'administration à distance, comme le décrivent les sections qui suivent. SSL peut être utilisé pour protéger les connexions aux serveurs dorsaux (par exemple, les serveurs de contenu ou d'applications) et pour sécuriser les communications entre le serveur proxy et les clients.
Pour les serveurs proxy d'acheminement, Caching Proxy prend en charge l'établissement de tunnels SSL qui contournent le protocole SSL et transmettent les données déjà chiffrées sans les modifier à nouveau.
La protection SSL est appliquée lorsqu'un système envoie une demande de connexion sécurisée à un autre système ; par exemple, un navigateur envoie une demande à un serveur proxy de remplacement. La syntaxe de la demande https:// au lieu de http:// indique au navigateur que la demande doit être envoyée sur le port 443, utilisé par le serveur pour identifier les demandes de connexion sécurisées (à la place du port 80 pour les demandes de routine). Pour mettre en place une session sécurisée entre les deux systèmes, les deux machines établissent un échange, appelé liaison SSL, afin de convenir d'une spécification de chiffrement, puis choisissent une clé pour chiffrer et déchiffrer les informations. Les clés sont automatiquement générées. Elles arrivent à expiration en même temps que la session. Le scénario classique (avec SSL version 3) se déroule de la manière suivante :
Le client établit une session SSL avec Caching Proxy en envoyant un message Client Hello décrivant ses capacités de chiffrement.
Le serveur envoie son certificat au client et sélectionne un algorithme de cryptographie pour effectuer le chiffrement des données.
Le client envoie des informations permettant de créer des clés de chiffrement symétriques pour les données chiffrées. Ces informations sont appelées secret maître et sont chiffrées à l'aide de la clé publique du serveur (obtenue à partir du certificat du serveur). Voir Gestion des clés et des certificats. Le serveur et le client peuvent définir les clés de chiffrement symétriques pour la lecture et l'écriture à partir du "secret maître".
Le serveur envoie la confirmation finale et un code d'authentification du message (MAC) pour l'ensemble du protocole de liaison.
Le client envoie un message de validation du message de fin du serveur.
Si le client valide le message de fin du serveur, la transmission des données chiffrées peut commencer.
Lors de connexions sécurisées, l'utilisation de Caching Proxy sous la forme d'un noeud final permet de réduire la charge de traitement des serveurs de contenu ou d'applications. Quand Caching Proxy gère une connexion sécurisée, il effectue des opérations de traitement particulièrement lourdes (chiffrement, déchiffrement, création de clés). Il permet également de configurer les délais d'expiration de la session SSL pour optimiser l'utilisation de chaque clé.
Limites du protocole SSL
Le protocole SSL présente les limites suivantes dans Caching Proxy de WebSphere Application Server :
En présence de volumes de trafic HTTPS élevés, le serveur Caching Proxy peut entraîner une utilisation intensive de la CPU. Vous pouvez aider le serveur proxy à gérer la charge et réduire l'utilisation de la CPU en modifiant la variable d'environnement (GSK_V3_SIDCACHE_SIZE).
L'ID de session SSL identifie les sessions SSL réutilisables, y compris les clés de chiffrement et de déchiffrement utilisées par les navigateurs et les serveurs, et permet d'éviter les établissements de liaison SSL inutiles sur les nouvelles connections, qui sont de gros consommateurs de temps CPU du serveur. La bibliothèque GSKit du serveur Caching Proxy prend en charge l'ID de session SSL et contient un cache d'ID de session SSL. Par défaut, le cache de l'ID de session SSL contient 512 entrées. A la saturation de limite des entrées, l'entrée de session la plus ancienne est supprimée et la nouvelle entrée est ajoutée dans le cache.
Servez-vous de la variable d'environnement GSK_V3_SIDCACHE_SIZE pour modifier la taille par défaut du cache d'ID de session SSL. Les valeurs correctes pour la variable sont comprises entre 1 et 4096. Augmenter la taille augmente le temps de consultation requis pour localiser une session SSL mise en cache. Toutefois, cette augmentation de temps est insignifiante par rapport au temps système requis pour établir une connexion SSL. Augmenter la taille du cache permet au serveur proxy de gérer un plus grand nombre de sessions SSL simultanées tout en réduisant l'utilisation de la CPU lorsque le serveur proxy est soumis à des charges HTTPS élevées.
Caching Proxy dispose également d'une directive ajustable SSLV3Timeout. (Voir SSLV3Timeout — Indique le délai d'inactivité au-delà duquel une session SSLV3 expire.) La valeur par défaut de la directive est 1000 secondes. Cette directive définit la durée de vie d'une session SSL dans le cache des sessions. Si aucune connexion SSL entrante n'utilise de session SSL existante et que la durée de vie de la session dépasse la valeur, cette session est supprimée du cache. Il est recommandé de choisir comme valeur SSLV3Timeout la longueur d'une session client sécurisée classique. Si le délai d'attente défini est trop court, les performances du proxy risquent d'être ralenties car plusieurs sessions d'établissement de liaison SSL sont nécessaires pour une seule session sécurisée. En revanche, si la valeur définie est trop longue, la sécurité d'une session sécurisée peut s'en trouver compromise.
S'applique aux configurations avec proxy d'acheminement uniquement.
Lorsque Caching Proxy est configuré comme serveur proxy d'acheminement, il utilise la fonction de création de tunnels SSL pour prendre en charge les connexions sécurisées entre les clients et les serveurs de données. Lors de l'établissement des tunnels SSL, les données chiffrées sont transmises telles quelles via le serveur proxy. Comme le serveur proxy ne déchiffre pas les données, les fonctions demandant au serveur proxy de lire les demandes ou les en-têtes de documents ne sont pas prises en charge. Les demandes traitées via les tunnels SSL ne sont pas mises en mémoire cache.
La figure 2 décrit le mode d'établissement d'une connexion via des tunnels SSL.
Le processus d'établissement de tunnels SSL se déroule de la manière suivante :
Lors de la configuration d'un serveur proxy d'acheminement, seule la fonction d'établissement des tunnels SSL est disponible. Pour configurer les paramètres des tunnels dans les formulaires de configuration et d'administration, sélectionnez Configuration du proxy –> Paramètres du proxy. Cochez la case Etablissement de tunnels.
La méthode CONNECT (désactivée par défaut) doit également être activée pour les connexions utilisant les tunnels SSL. Pour l'activer avec les formulaires configuration, sélectionnez Configuration du serveur –> Traitement des demandes et utilisez le formulaire Méthodes HTTP.
Trois options (OutgoingPorts, OutgoingIPs, IncomingIPs) sont fournies pour la directive Enable CONNECT pour une meilleure sécurité lors de l'établissement de tunnels SSL. Vous devez indiquer une valeur pour OutgoingPorts au moins, sinon, la méthode CONNECT n'est pas activée.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]
Pour permettre aux clients de se connecter uniquement au port 443 des serveurs distants pour l'établissement de tunnels SSL, définissez les directives suivantes. (Le port 443 est normalement réservé aux demandes HTTPS sur le serveur distant.)
Enable CONNECT OutgoingPorts 443
SSLTunneling on
Pour permettre aux clients de se connecter à n'importe quel port sur les serveurs distants pour l'établissement de tunnels SSL, définissez les directives suivantes:
Enable CONNECT OutgoingPorts all
SSLTunneling on
Pour permettre aux clients de se connecter aux ports 80, 8080-8088, 9000 et suivants sur les serveurs distants pour l'établissement de tunnels SSL, définissez les directives suivantes:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-*
SSLTunneling on
Séparez les numéros de ports et séries de ports par une virgule, sans ménager d'espace.
IMPORTANT : Pour les configurations avec serveur proxy d'acheminement, spécifiez au moins 443 ou all avec l'option OutgoingPorts pour activer l'établissements de tunnels SSL normal.
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]
Par exemple, pour permettre aux clients de se connecter à n'importe quel port sur les serveurs distants correspondant à l'adresse IP/au nom d'hôte *.ibm.com et ne devant pas correspondre à 192.168.*.*, définissez les directives suivantes :
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.*
SSLTunneling on
Enable CONNECT IncomingIPs [[!]modèle_IP,...]
Par exemple, pour permettre aux clients provenant de l'adresse IP 192.168.*.* de se connecter à n'importe quel port sur les serveurs distants pour l'établissement de tunnels SSL, définissez les directives suivantes :
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.*
SSLTunneling on
Pour plus d'informations sur l'activation de la fonction d'établissement des tunnels SSL et les directives CONNECT en modifiant le fichier de configuration du proxy, voir les sections de référence dans l'Annexe B. Directives du fichier de configuration pour les directives suivantes :
Vous pouvez administrer à distance Caching Proxy en utilisant les fonctions de sécurité proposées par le protocole SSL (Secure Sockets Layer) et l'authentification du mot de passe. Cette fonction permet de réduire fortement le risque d'accès au serveur proxy par des personnes non autorisées.
Pour utiliser le protocole SSL lors de l'administration à distance du serveur, lancez une demande https:// et non une demande http:// pour ouvrir les formulaires de configuration et d'administration. Par exemple :
https://nom.serveur/pagedegarde.html
Avant de configurer le protocole SSL, vous devez définir une base de données de clés et obtenir un certificat ou en créer un. Les certificats permettent d'authentifier l'identité du serveur. Vous devez lancer l'utilitaire IBM Key Management (appelé parfois iKeyman) pour définir les fichiers de configuration. Cet utilitaire fait partie du kit JDK (Java Development Kit). iKeyman contient également une interface graphique Java pour ouvrir les fichiers de certificat.
Pour définir les clés et les certificats SSL suivez les étapes de base suivantes :
Pour tous les systèmes d'exploitation à l'exception de Linux, si le certificat a expiré, Caching Proxy ne démarre pas correctement et un message d'erreur s'affiche pour indiquer que la base de données de clés a expiré. Sous Linux, le proxy semble avoir démarré mais le processus disparaît rapidement et aucun message d'erreur n'est généré.
Pour éviter cet incident sur les systèmes Red Hat Enterprise Linux 3.0, assurez-vous que les packages GCC ont au moins le niveau suivant :
La clé publique doit être associée à un certificat doté d'une signature numérique et émis par une autorité de certification (CA) reconnue sur le serveur. Vous pouvez vous procurer un certificat signé en soumettant une demande à une autorité de certification (CA). Caching Proxy accepte les autorités de certification externes suivantes :
Par défaut, les autorités de certification suivantes sont considérées comme sécurisées :
Cette section constitue un guide de référence d'utilisation de l'utilitaire IBM Key Manager (iKeyman). Utilisez le gestionnaire de clés pour créer une base de données de clés SSL, des paires de clés publiques et privées et une demande de certificat. Une fois que vous avez reçu le certificat signé par l'autorité de certification, vous pouvez utiliser le gestionnaire de clés pour placer le certificat dans la base de données de clés où la demande de certificat initiale a été créée.
Une documentation détaillée sur les programmes IBM Key Manager et GSKit est fournie avec le logiciel GSKit.
Configuration du système pour exécuter le gestionnaire de clés
Avant de lancer l'interface graphique utilisateur IKeyman, procédez aux opérations ci-dessous.
Mettez le fichier JAVA_HOME/jre/lib/security/java.security à jour en ajoutant les fournisseurs IBM CMS et IBM JCE dans les emplacements indiqués dans l'exemple suivant :
Lancement du gestionnaire de clés
Démarrez l'interface graphique du gestionnaire de clés en exécutant l'outil iKeyman depuis le kit JDK. Par exemple, utilisez la commande suivante :
La base de données de clés est un fichier utilisé par le serveur pour stocker des certificats et une ou plusieurs paires de clés. Vous pouvez utiliser une base de données de clés pour toutes les paires de clés et les certificats, ou créer plusieurs bases de données. L'utilitaire de gestion des clés permet de créer des bases de données et de définir leurs mots de passe et leurs fichiers de stockage.
Pour créer une base de données de clés et un fichier de stockage, procédez comme suit :
Le mot de passe défini lors de la création de la base de données permet de protéger la clé privée. La clé privée est la seule clé disponible pour signer des documents ou déchiffrer des messages chiffrés à l'aide de la clé publique.
Lors de la définition du mot de passe, respectez les instructions suivantes :
Il est bon de redéfinir fréquemment le mot de passe de la base de données de clés. Toutefois, si vous définissez une date d'expiration du mot de passe, n'oubliez pas de noter la date à laquelle il doit être changé. Si le mot de passe arrive à expiration avant que vous ne le redéfinissiez, un message est consigné dans le journal ; le serveur démarre mais il ne peut pas établir de connexions réseau sécurisées.
Pour changer le mot de passe de la base de données de clés, effectuez les opérations suivantes :
Pour établir une connexion SSL entre un serveur proxy et un serveur LDAP, placez le mot de passe de la base de données de clés dans le fichier pac_keyring.pwd. (Le fichier pac_keyring.pwd n'est pas un fichier de dissimulation généré par IKeyMan.)
Création d'une paire de clés et d'une demande de certificat
La base de données stocke des paires de clés et des demandes de certificats. Pour créer une paire de clés publique-privée, procédez comme suit :
Une
demande de certificat a été créée
dans le fichier nom_base_fichier_clés.
Création d'un certificat d'auto-signature
En attendant, vous pouvez lancer l'utilitaire de gestion des clés pour créer un certificat d'auto-signature et activer des sessions SSL entre les clients et le serveur proxy. Vous pouvez également utiliser des certificats d'auto-signature à des fins de test.
Pour créer un certificat d'auto-signature, procédez comme suit :
Exportation des clés
Pour exporter des clés dans une autre base de données, procédez comme suit :
Importation des clés
Pour importer des clés à partir d'une autre base de données, procédez comme suit :
Affichage des autorités de certification
Pour afficher la liste des autorités de certification reconnues (CA) dans la base de données de clés :
Suivez la procédure ci-après pour recevoir un certificat adressé par courrier électronique par une autorité de certification (AC) considérée comme sécurisée par défaut (voir la liste de la section Autorités de certification). Si l'autorité émettrice du certificat signé n'est pas considérée comme une autorité sécurisée dans la base de données, vous devez d'abord stocker le certificat et définir l'autorité comme une entité sécurisée. Vous pouvez ensuite recevoir le certificat signé par l'autorité dans la base de données. Vous ne pouvez pas recevoir le certificat signé d'une autorité qui n'est pas considérée comme sécurisée (voir la section Stockage d'un certificat signé par une autorité de certification).
Pour recevoir un certificat signé dans la base de données, procédez comme suit :
Seuls les certificats signés par des autorités agréées sont acceptés pour l'établissement de connexions sécurisées. Pour ajouter une autorité de certification à la liste des autorités agréées (sécurisées), vous devez vous procurer son certificat et le stocker en indiquant qu'il s'agit d'un certificat sécurisé. Pour stocker un certificat émis par une nouvelle autorité, procédez comme suit avant de l'enregistrer dans la base de données :
Affichage de la clé par défaut dans la base de données
Affichez l'entrée de clé par défaut comme suit :
Les algorithmes de chiffrement et les modules de hachage utilisés par SSL versions 2 et 3 sont répertoriés dans les tableaux ci-après :
Génération de paires de clés : Tailles des clés privées RSA 512–1024
SSL version 2
Version utilisée aux Etats-Unis | Version utilisée dans les autres pays |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56 bits | non applicable |
Triple DES US | non applicable |
RC4 Export | non applicable |
RC2 Export | non applicable |
SSL version 3
Version utilisée aux Etats-Unis | Version utilisée dans les autres pays |
Triple DES SHA US | DES SHA Export |
DES SHA Export | RC2 MD5 Export |
RC2 MD5 Export | RC4 MD5 Export |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 Export | NULL NULL |
RC4 SHA 56 bits | non applicable |
DES CBC SHA | non applicable |
NULL SHA | non applicable |
NULL MD5 | non applicable |
NULL NULL | non applicable |
Ces spécifications SSL peuvent également être configurées en modifiant directement le fichier de configuration du proxy. Pour plus d'informations, voir les sections de référence dans le Annexe B. Directives du fichier de configuration pour les directives suivantes :
Chiffrement sur 128 bits pour Caching Proxy
Seule une version de chiffrement sur 128 bits est fournie avec Caching Proxy. La version de chiffrement sur 56 bits n'est plus disponible. Si vous mettez à jour une version précédente, vous pouvez installer Caching Proxy directement sur la version de chiffrement 128 ou 56 bits déjà installée. Si vous utilisiez un navigateur (pour l'export) 56 bits, vous devez le mettre à niveau pour obtenir un navigateur 128 bits afin de profiter du chiffrement sur 128 bits du proxy.
Après la mise à niveau de la version de chiffrement sur 56 bits de Caching Proxy vers une version de chiffrement sur 128 bits, vérifiez la valeur de la taille de la clé utilisée pour le chiffrement des certificats. Si cette valeur est égale à 1024, il n'est pas nécessaire de modifier la configuration. Cependant, si la taille de la clé a une valeur égale à 512, vous devez créer de nouveaux certificats dotés d'une clé dont la taille est égale à 1024 pour pouvoir bénéficier du chiffrement sur 128 bits du proxy. Créez des clés avec l'utilitaire IBM Key Manager (iKeyman).
Pour plus d'informations sur l'utilitaire IBM Key Manager, voir Gestion des clés et des certificats.
Cette version ne prend pas en charge le chiffrement dans l'environnement Linux SUSE.