Vous connaissez tous le SSL, acronyme de Secure Socket Layer, cette technologie de chiffrement qui nous fait nous sentir à l’abris des regards indiscrets lorsque nous consultons un site web ou que nous utilisons un portail d’entreprise bien nommé de type “VPNSSL”. Etant utilisé massivement sur le Net depuis des années, on imagine fort bien la pression que mettent les ingénieurs en sécurité pour trouver des failles ou des faiblesses dans les algorithmes employés au sein de la technologie. Quels sont les impacts à la lumière des failles SSLv3 découvertes sur nos environnement VMWare ? Plus d’explication dans la suite de ce billet.
En fin d’année dernière, un groupe de chercheurs (chez Google) à trouvé – et prouvé – que la dernière version majeure, SSLv3, qui date quand même de plusieurs années, était victime d’une faiblesse algorithmique intrinsèque conduisant à autoriser un “man in the middle” dé-chiffrer relativement facilement un flux de ce type, sans avoir des super-ordinateurs à la Skynet à disposition. Ils ont l’ont appelé la faille “PODDLE”.
Après cette découverte et plutôt que d’essayer de patcher SSLv3 une nouvelle fois, la communauté de chercheurs et les principaux acteurs du monde de la cyber-sécurité ont proposé une approche plus souple et évolutive basée sur TLS (Transport Layer Security). La différence majeure entre SSLv3 et TLS est la méthode de négociation. Dans le premier, on réalise une connexion explicite sur un port sécurisé via SSL et la négociation du chiffrement est figée, lié uniquement à la version du protocole utilisé. Dans TLS, au contraire, on se connecte à un port banalisé, ensuite le serveur et le client négocient le chiffrement à l’intérieur du tuyau avant d’échanger des données. Je ne vais pas aller trop loin dans cette description, mais en gros, sachez que TLS est maintenant la méthode recommandée pour la négociation des échanges chiffrés. Si vous souhaitez plus d’info, je vous conseille la lecture de ces 2 billets du site LuxSCI, particulièrement précis et bien écrits : une infographie et plus en détail.
Pour terminer le “tableau”, il faut savoir que SSL est utilisé massivement par VMWare pour sécuriser les communications entre les différents éléments d’infrastructure : vCenter-ESX , discussion avec les nombreuses API, etc. … Dans la pratique, vCenter 5.x et 6.x sont déjà nativement compatibles avec TLS depuis assez longtemps, mais le SSLv3 restait activé pour des raisons de historiques et tout se passait bien.
Or, les nouvelles releases récentes de ESXi et vCenter (6.0u1 et 5.5u3b) désactivent par défaut cette compatibilité et peuvent provoquer des dysfonctionnements si les mises à jours ne sont pas faites dans l’ordre. Dans la pratique, nous avons nous même été très récemment “victimes” de ce problème (à lire dans ce petit billet).
Sans rentre trop dans le détail (vous trouverez tout un tas de liens spécifiques en fin d’article), il faut faire surtout attention aux patchs ESXi. En gros, lorsque vous appliquez des correctifs de sécurité estampillés “Security” dans Update Manager, vérifiez bien les détails des patchs et leur compatibilité avec votre version de vCenter. Aujourd’hui, 17 Décembre, vCenter 5.5u3b est la seule version de vCenter prenant en charge les ESXi dont SSLv3 est désactivé.
Je n’ai pas réussi à trouver de page chez VMWare permettant de faire le point globalement sur leurs produits vis à vis de l’obsolescence du SSLv3, donc je ne peux pas vraiment être exhausitf, mais une petite recherche sur la base de connaissance montre que le sujet est chaud (de nombreux articles décrivent notamment les méthodes pour ré-activer SSLv3).
Pour en savoir plus, voici une liste (non exhaustive bien sûr) de notes et billets qui précisent les choses :
Un article très intéressant sur la faille PODDLE sur NextINpact, ici.
Une note spécifique sur la faille PODDLE et les produits VMWare, ici.
Les release notes de vCenter 5.5u3b, ici.
Les release notes de vCenter 6.0u1, ici.