Il est difficile de croire que l’indication du nom du serveur TLS (SNI) existe depuis treize ans. Dans nos temps modernes, c’est un dinosaure, mais étrangement peu utilisé ; bien que cela change enfin, et c’est dans ce blog que nous explorons comment les équilibreurs de charge avancés d’edgeNEXUS peuvent prendre en charge cette fonctionnalité. SNI résout l’un des plus grands problèmes que beaucoup rencontrent avec SSL/TLS/HTTPS : la nécessité de dédier une adresse IP précieuse à chaque nom de domaine ou de sous-domaine qui doit être sécurisé. Ceci est nécessaire car SSL/TLS sécurise la connexion avant que nous puissions inspecter la requête HTTP initiale du client, qui contient ces précieux détails sur le nom de domaine.
La seule façon de s’assurer que nous fournissons le bon certificat est de n’en servir qu’un seul par adresse IP et d’utiliser le DNS pour s’assurer que les requêtes adressées à un nom de domaine spécifique sont acheminées vers l’adresse IP d’un hôte qui fournit le bon certificat pour ce domaine. Dans une entreprise privée, nous pourrions peut-être utiliser la même adresse IP mais un port différent, mais nous sommes alors obligés de nous assurer que tout le monde sait qu’il faut utiliser le port non standard. Cette option n’est pas vraiment viable lorsqu’il s’agit de services publics accessibles par l’internet.
Nous pourrions utiliser des certificats de type « wildcard » qui protègent tous les sous-domaines possibles (*.jetnexus.co.uk par exemple), mais personne ne les aime, et encore moins les types de sécurité. Quoi que vous puissiez penser des hommes et des femmes du monde de la sécurité de l’information, ils n’ont probablement pas tort. Il est difficile de faire confiance à quelque chose qui, de par sa conception, représente littéralement tout ou n’importe quoi au sein d’un domaine. Combien d’appareils stockent et combien de personnes ont accès au certificat et à la clé utilisés ?
Les certificats SAN (Server Alternative Name) ont toujours été disponibles, mais ils nécessitent la connaissance de chaque domaine spécifique à protéger, au moment où ils sont générés. Toute suppression ou ajout d’un nom de domaine nécessite la régénération du certificat et la mise à jour de tous les hôtes concernés.
C’est le choix de plus en plus difficile auquel nous avons tous été confrontés à maintes reprises (nos utilisateurs et nos clients aussi) : brûler une adresse IP ou accepter un compromis (dans tous les sens du terme). De plus en plus difficile parce que les adresses IP sont une ressource limitée dont la disponibilité diminue et la valeur augmente chaque jour. Heureusement pour nous, il existe une solution à ce problème de longue date depuis de nombreuses années. Elle nous offre le meilleur des mondes, mais n’a eu que peu d’impact jusqu’à récemment.
SNI Fournit une méthode permettant au client d’indiquer au serveur (dans notre cas, un jetNEXUS) le nom de domaine avec lequel il établit une connexion. Pour ce faire, un champ d’extension est rempli dans le premier paquet TLS du client (un hello) avec ce nom de domaine. Ce champ est envoyé « en clair » afin qu’il puisse être lu avant que le serveur n’envoie son certificat SSL/TLS. Cela permet clairement au serveur d’envoyer le certificat attendu (en supposant qu’il l’ait) parmi tous ceux qui lui ont été fournis.
Ainsi, un seul service virtuel (et une seule adresse IP) peut être configuré avec autant de certificats SSL pour autant de noms de domaine que vous souhaitez qu’il serve. Chacun d’entre eux peut disposer d’un certificat SSL dédié et valide, fourni correctement et sans erreur, sur la base des données fournies par le client. Servez www.jetnexus.com et www.loadbalance.co.uk à la même adresse IP et fournissez des certificats valides pour les deux ; pas de compromis, pas d’ennui et pas de perte d’adresse IP.
De plus, vous pouvez modifier la liste des domaines pris en charge par le service virtuel à tout moment, en quelques clics dans l’interface graphique. Ajoutez ou supprimez des certificats pour ajouter ou supprimer les domaines pris en charge par le service virtuel. N’oubliez pas de mettre à jour votre DNS en même temps. Vous souhaitez utiliser des serveurs réels différents pour un ou deux domaines de grande valeur, pas de problème, une règle flightPATH rapide est à votre disposition en quelques minutes. Idem pour la compression HTTP, les réécritures d’ URL ou tout ce dont vous avez besoin. Un seul service virtuel et une seule adresse IP pour plusieurs domaines sont très souhaitables, mais ils ne doivent pas restreindre le traitement unique que vous pourriez vouloir appliquer au trafic des différents domaines.
Je vous entends : « Quel est le problème ? » Eh bien, il y en avait certainement un et c’est la raison pour laquelle SNI existe depuis si longtemps mais n’apparaît que maintenant dans l’équilibrage de charge et d’autres produits. Cette raison ? Le support client. La longévité de l’incroyablement populaire combinaison Windows XP et IE6, qui ne prend pas en charge SNI, a empêché la plupart des utilisateurs de l’utiliser. Personne ne veut se priver de 10 à 20 % de son public.
Windows XP a largement dépassé la fin de son support, IE6 est utilisé à moins de 1% sur le web sauvage et la mise à jour gratuite vers Windows 10 est poussée et adoptée rapidement. Nous pouvons enfin être sûrs que la mise en œuvre de SNI n’aura pas d’impact sur nos clients et nos activités. IE 7 et plus (sur Vista ou version ultérieure) et presque toutes les versions de Chrome, Firefox et Safari, à l’exception des plus anciennes, supportent SNI. Si vous souhaitez vérifier et être sûr de votre base d’utilisateurs spécifique, il existe une règle flightPATH pour cela aussi.
En ce qui concerne la sécurité, soyons clairs : le client fournit des informations en texte clair. Il s’agit d’informations qui peuvent être capturées sur le fil. Le client effectue une requête DNS en texte clair avant de se connecter. Nous ne pouvons pas contrôler cela, et il n’est donc pas considéré comme un risque de révéler cette information une seconde fois par la suite. Peut-être voudrez-vous vérifier que le nom de domaine SNI correspond à celui trouvé dans l’en-tête HTTP Host, avec une règle flightPATH, ou peut-être vous en moquez-vous, tout le monde est différent. Cela suggère-t-il un problème de sécurité ? Quoi qu’il en soit, le client est connecté et la connexion est sécurisée. À moins que vous n’appliquiez une politique de sécurité basée sur le nom de domaine (et vous ne devriez pas le faire), tout va bien.
Si vous voulez vraiment plus de détails, jetez un coup d’œil à la RFC3546originale (section 3.1), à la RFC6066plus récente (section 3) et, si vous pensez qu’elle est digne de confiance : Server Name Indication sur Wikipedi. Si vous avez besoin d’une sécurité au niveau de l’application, le WAF de edgeNEXUS est basé sur une technologie de pointe de pare-feu d’application renforcée. Disponible via l’App Store de edgeNEXUS et utilisant la technologie de conteneur de nouvelle génération, le pare-feu applicatif de edgeNEXUS offre une protection de sécurité complète pour répondre aux exigences de conformité PCI-DSS et OWASP. Comme nous l’avons vu dans de précédents articles de blog, flightPATH est un moteur de règles dynamique, basé sur des événements, développé par edgeNEXUS pour manipuler et acheminer intelligemment le trafic IP, HTTP et HTTPS à charge équilibrée. Pour en savoir plus sur la gestion du trafic flightPATH, veuillez cliquer ici, et pour découvrir comment tirer pleinement parti des règles disponibles, veuillez consulter le Guide de l’utilisateur edgeNEXUS.
Un seul service virtuel (et une seule adresse IP) peut être configuré avec autant de certificats SSL pour autant de noms de domaine que vous souhaitez qu’il serve. Chacun peut avoir un certificat SSL dédié et valide, fourni correctement sans erreur, sur la base des données fournies par le client.
