on 22-Dec-2014 08:49
Dans les déploiements Cloud, qu’ils soient Public, Hybrides ou Privés, les performances cryptographiques des machines virtuelles qui portent les services de chiffrement dépendent directement de la puissance CPU et du nombre de vCPU alloués à la machine virtuelle.
Lorsqu’on on utilise des clés RSA de plus de 1024bits, les temps de calcul s’allongent de façon exponentielle.
Si je prends l’exemple de services Web virtualisés dans le Cloud, lorsqu’on active la terminaison SSL/TLS –soit sur les serveurs Web soit sur le reverse proxy - et que l’on doit tenir un certain nombre de transactions par seconde en SSL/TLS, il devient nécessaire de passer sur des instances virtuelles typées « haute performance » et l’équation économique peut rapidement devenir défavorable.
La fonctionnalité de Délestage Cryptographique Externe (External Crypto Offload) permet à une édition virtuelle de BIG-IP d’atteindre sa performance TPS maxi (c’est la licence VE qui détermine la capacité TPS SSL maxi), de réduire la charge CPU induite par le handshake SSL et ce, en tirant parti des ressources d’accélération matérielle SSLT/TLS d’un BIG-IP.
Le Délestage Cryptographique Externe apporte de la flexibilité dans les modes de déploiements Cloud (par exemple en multi-Cloud ou en Cloud hybride) tout en d’optimisant l’utilisation de la capacité SSL/TLS du hardware.
Exemple de délestage Crypto SSL en Cloud hybride
Comment ca marche ?
Cette fonctionnalité introduit le concept de Client Crypto et de Serveur Crypto.
Le Client Crypto (la VE Big-IP) possède les informations de connexion au Serveur Crypto (l'Appliance Big-IP) tels que l’adresse IP, le port TCP, les paramètres de timeout et va utiliser un profil serveur SSL (car l'Appliance Big-IP est vue comme un noeud d’un pool).
De son coté, le Serveur Crypto va posséder la liste blanche des Clients Crypto qui vont pouvoir se connecter et venir consommer les services cryptographique et, va utiliser un profil client SSL (les VE sont vues comme des clients d’un VS).
Chaque thread TMM du client crypto va se connecter en TCP à un thread TMM du Serveur Crypto.
Au niveau de l'Appliance BIG-IP, c’est le disaggregator (DAG) qui détermine quel thread TMM va prendre la connexion TCP du thread TMM du Client Crypto. Il va pour cela utiliser un algorithme de hachage pour distribuer les connexions sur les threads TMMs.
Les connexions TCP entre le client crypto et le serveur crypto sont chiffrées en TLS 1.2.
Exemple de connexion
Et la haute disponibilité dans tout cela ?
Il est possible d’avoir plusieurs VE qui se connectent à une seule Appliance Big-IP.
On peut aussi avoir des VE en clustering qui vont utiliser la même Appliance physique.
De même, chaque VE peut effectuer du délestage sur plusieurs Appliances physiques en utilisant du Round Robin.