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
- Le client (navigateur web) effectue une connexion au Virtual Server de la VE et initie un SSL handshake
- Le Client Crypto extrait les informations requises (clé privée et payload de pre-master key chiffré) et envoie la requête au Serveur Crypto à travers la connexion sécurisée.
- Le Serveur Crypto effectue les fonctions cryptographiques et renvoie la réponse au Client Crypto à travers la connexion sécurisée. Le Client Crypto utilise ces informations pour terminer le handshake SSL.
- La connexion HTTPS est établie entre la VE et le client web
- La VE BIG-IP effectue une décision de load balancing et envoie la requête de connexion à un membre du pool de serveurs web.
- Le serveur web envoie une réponse à la requête
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.