[AIX Solaris HP-UX Linux Windows][IBM i]

Conseils pour les performances de SSL (Secure Sockets Layer)

Vous trouverez dans cette page des informations sur les conseils qui vous seront utiles pour améliorer les performances de la couche Secure Sockets Layer (SSL). Il est indispensable de garder à l'esprit que les problèmes de performance entraînent généralement des compromis entre le nombre de fonctionnalités et la vitesse de traitement. Habituellement, plus le nombre de fonctions et de traitements est important, plus le système est lent.

Les performances SSL (Secure Sockets Layer) se divisent en deux catégories :
  • Prise de contact
  • Chiffrement/déchiffrement en masse

Lorsque une connexion SSL est établie, un établissement de liaison SSL est effectué. Une fois qu'une connexion est établie, SSL effectue des opérations de chiffrement et de déchiffrement en bloc pour chaque lecture/écriture. La prise de contact SSL a des répercussions beaucoup plus sérieuses sur les performances que le chiffrement et le déchiffrement en masse.

Pour améliorer les performances SSL, il convient de réduire le nombre de connexions SSL et de prises de contact individuelles.

La réduction du nombre des connexions améliore les performances des communications sécurisées par le biais des connexions SSL, ainsi que celles des communications non sécurisées par le biais des connexions TCP/IP simples. L'une des méthodes permettant de réduire le nombre des connexions SSL individuelles consiste à utiliser un navigateur prenant en charge HTTP 1.1. Cette opération peut s'avérer impossible si vous ne pouvez pas effectuer la mise à niveau vers HTTP 1.1.

Une autre approche standard consiste à réduire le nombre des connexions (TCP/IP et SSL) entre deux composants WebSphere Application Server. Les consignes suivantes sont destinées à vous aider à vérifier si le transport HTTP du serveur d'applications est configuré de telle sorte que le plug-in du serveur Web n'ouvre pas à chaque fois de nouvelles connexions au serveur d'applications :
  • Vérifiez que le nombre maximal d'objets actifs est, au minimum, égal au nombre maximal de demandes par unité d'exécution du serveur Web (ou au nombre maximal de processus pour IBM® HTTP Server sous UNIX). Assurez-vous que le plug-in du serveur Web peut obtenir une connexion persistante pour chaque connexion concurrente possible au serveur d'applications. Si ce n'est pas le cas, le serveur d'applications ferme la connexion une fois le traitement d'une demande terminé. De plus, le nombre maximal d'unités d'exécution dans le pool d'unités d'exécution du conteneur Web doit être supérieur au nombre maximal de connexions actives, afin d'éviter que ces dernières utilisent les unités d'exécution du conteneur Web.
    Remarque : L'utilisation des transports HTTP est déconseillée. Pour les instructions de définition d'une valeur de signal de présence maximale pour les configurations basées canal, voir Paramètres du canal de transport HTTP
  • Augmentez le nombre maximal de demandes par connexion persistante. La valeur par défaut est 100, ce qui signifie que le serveur d'applications ferme la connexion à partir du plug-in au bout de 100 demandes. Le plug-in doit alors ouvrir une nouvelle connexion. Ce paramètre a pour but d'interdire les refus d'attaques de service lors de la connexion au serveur d'applications et d'envoyer des requêtes en continu afin d'attacher les unités d'exécution sur le serveur d'applications.
  • Utilisez un accélérateur matériel si le système effectue plusieurs prises de contact SSL.

    Les accélérateurs matériels pris en charge actuellement par WebSphere Application Server améliorent les performances d'établissement de liaison SSL, et non pas celles du chiffrement et du déchiffrement en bloc. Généralement, le serveur Web bénéficie de la présence d'un accélérateur car les connexions au serveur Web ont une durée de vie réduite. Toutes les autres connexions SSL dans WebSphere Application Server ont une longue durée de vie.

    [IBM i]Le coprocesseur de cryptographie IBM (IBM Cryptographic Coprocessor) n'est pas pris en charge lorsqu'il est utilisé avec WebSphere Application Server. Cependant, vous pouvez utiliser le coprocesseur de cryptographie IBM pour améliorer les performances SSL d'autres produits, comme IBM HTTP Server for iSeries, qui est basé sur la technologie Apache.

  • Utilisez une autre série de codes de chiffrement plus performante.

    Les performances d'une suite de chiffrement ne sont pas les mêmes selon qu'il s'agit de logiciel ou de matériel. Le fait qu'une suite de chiffrement soit plus efficace sur un logiciel ne signifie pas qu'il en sera de même pour du matériel. Certains algorithmes sont généralement inefficaces sur le matériel, les normes DES (Data Encryption Standard) et 3DES (triple-strength DES) en sont des exemples. Cependant, du matériel spécialisé peut fournir des implémentations efficaces de ces mêmes algorithmes.

    Les performances du chiffrement et du déchiffrement en bloc sont affectées par la suite de chiffrement utilisée pour une connexion SSL individuelle. Le schéma ci-après indique les performances de chaque série de codes de chiffrement. Le logiciel de test, Java™ Secure Socket Extension (JSSE), auquel fait appel le logiciel client et serveur pour calculer les données, n'utilise pas le support matériel de chiffrement. Le test ne prend pas en compte le temps nécessaire à l'établissement d'une connexion mais uniquement la durée de la transmission des données par le biais d'une connexion établie. Ainsi, les données révèlent les performances SSL relatives des différentes séries de code de chiffrement pour les connexions de longue durée.

    Avant d'établir une connexion, le client active une série de codes de chiffrement unique pour chaque scénario de test. Une fois la connexion établie, le client calcule le temps nécessaire à l'enregistrement d'un entier sur le serveur et le temps nécessaire au serveur pour l'enregistrement d'un nombre d'octets déterminé sur le client. La variation de la quantité de données a eu peu d'effet sur les performances relatives des codes de chiffrement.

    Une fois la connexion établie, le client calcule le temps nécessaire à l'enregistrement d'un entier sur le serveur et le temps nécessaire au serveur pour l'enregistrement d'un nombre d'octets déterminé sur le client. La variation de la quantité de données a eu peu d'effet sur les performances relatives des codes de chiffrement.

L'analyse des données précédentes révèle les éléments suivants :
  • Les performances de chiffrement en bloc sont uniquement affectées par la section située après WITH dans la suite de chiffrement vu que la section qui précède WITH identifie l'algorithme utilisé uniquement lors de la phase d'établissement de liaison SSL.
  • MD5 et Secure Hash Algorithm SHA(Secure Hash Algorithm) sont les deux algorithmes de hachage utilisés pour garantir l'intégrité des données. MD5 est généralement plus rapide que SHA. Par contre, SHA est plus sécurisé que MD5.
  • DES et RC2 sont plus lents que RC4. Triple DES est l'algorithme le plus sécurisé mais avec un impact élevé sur les performances s'il est utilisé uniquement avec le logiciel.
  • La suite de chiffrement offrant les performances les plus élevées tout en garantissant la confidentialité est SSL_RSA_WITH_RC4_128_MD5. Même si SSL_RSA_EXPORT_WITH_RC4_40_MD5 est moins efficace en termes de chiffrement que RSA_WITH_RC4_128_MD5, les performances du chiffrement en bloc sont identiques. Par conséquent, lorsque la connexion SSL est de longue durée, la différence de performances entre les niveaux de sécurité élevé et moyen est négligeable. Il est conseillé d'utiliser un niveau de sécurité élevé, et non moyen, pour tous les composants mis en oeuvre lors des communications entre les produits WebSphere Application Server. Assurez-vous que les connexions ont une exécution longue.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ssl
Nom du fichier : rprf_ssl.html