<\/p>\n
Il est difficile de croire que l’indication du nom du serveur TLS<\/a> (SNI) existe depuis treize ans. Dans nos temps modernes, c’est un dinosaure, mais \u00e9trangement peu utilis\u00e9 ; bien que cela change enfin, et c’est dans ce blog que nous explorons comment les \u00e9quilibreurs de charge avanc\u00e9s d’edgeNEXUS peuvent prendre en charge cette fonctionnalit\u00e9. SNI r\u00e9sout l’un des plus grands probl\u00e8mes que beaucoup rencontrent avec SSL\/TLS\/HTTPS : la n\u00e9cessit\u00e9 de d\u00e9dier une adresse IP pr\u00e9cieuse \u00e0 chaque nom de domaine ou de sous-domaine qui doit \u00eatre s\u00e9curis\u00e9. Ceci est n\u00e9cessaire car SSL\/TLS s\u00e9curise la connexion avant que nous puissions inspecter la requ\u00eate HTTP initiale du client, qui contient ces pr\u00e9cieux d\u00e9tails sur le nom de domaine. <\/p>\n La seule fa\u00e7on 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\u00eates adress\u00e9es \u00e0 un nom de domaine sp\u00e9cifique sont achemin\u00e9es vers l’adresse IP d’un h\u00f4te qui fournit le bon certificat pour ce domaine. Dans une entreprise priv\u00e9e, nous pourrions peut-\u00eatre utiliser la m\u00eame adresse IP mais un port diff\u00e9rent, mais nous sommes alors oblig\u00e9s 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. <\/p>\n Nous pourrions utiliser des certificats de type \u00ab wildcard \u00bb qui prot\u00e8gent tous les sous-domaines possibles (*.jetnexus.co.uk par exemple), mais personne ne les aime, et encore moins les types de s\u00e9curit\u00e9. Quoi que vous puissiez penser des hommes et des femmes du monde de la s\u00e9curit\u00e9 de l’information, ils n’ont probablement pas tort. Il est difficile de faire confiance \u00e0 quelque chose qui, de par sa conception, repr\u00e9sente litt\u00e9ralement tout ou n’importe quoi au sein d’un domaine. Combien d’appareils stockent et combien de personnes ont acc\u00e8s au certificat et \u00e0 la cl\u00e9 utilis\u00e9s ? <\/p>\n Les certificats SAN (Server Alternative Name) ont toujours \u00e9t\u00e9 disponibles, mais ils n\u00e9cessitent la connaissance de chaque domaine sp\u00e9cifique \u00e0 prot\u00e9ger, au moment o\u00f9 ils sont g\u00e9n\u00e9r\u00e9s. Toute suppression ou ajout d’un nom de domaine n\u00e9cessite la r\u00e9g\u00e9n\u00e9ration du certificat et la mise \u00e0 jour de tous les h\u00f4tes concern\u00e9s. <\/p>\n C’est le choix de plus en plus difficile auquel nous avons tous \u00e9t\u00e9 confront\u00e9s \u00e0 maintes reprises (nos utilisateurs et nos clients aussi) : br\u00fbler 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\u00e9e dont la disponibilit\u00e9 diminue et la valeur augmente chaque jour. Heureusement pour nous, il existe une solution \u00e0 ce probl\u00e8me de longue date depuis de nombreuses ann\u00e9es. Elle nous offre le meilleur des mondes, mais n’a eu que peu d’impact jusqu’\u00e0 r\u00e9cemment. <\/p>\n SNI Fournit une m\u00e9thode permettant au client d’indiquer au serveur (dans notre cas, un jetNEXUS) le nom de domaine avec lequel il \u00e9tablit 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\u00e9 \u00ab en clair \u00bb afin qu’il puisse \u00eatre 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 \u00e9t\u00e9 fournis. <\/p>\n Ainsi, un seul service virtuel (et une seule adresse IP) peut \u00eatre configur\u00e9 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\u00e9di\u00e9 et valide, fourni correctement et sans erreur, sur la base des donn\u00e9es fournies par le client. Servez www.jetnexus.com<\/a> et www.loadbalance.co.uk<\/a> \u00e0 la m\u00eame adresse IP et fournissez des certificats valides pour les deux ; pas de compromis, pas d’ennui et pas de perte d’adresse IP. <\/p>\n De plus, vous pouvez modifier la liste des domaines pris en charge par le service virtuel \u00e0 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 \u00e0 jour votre DNS en m\u00eame temps. Vous souhaitez utiliser des serveurs r\u00e9els diff\u00e9rents pour un ou deux domaines de grande valeur, pas de probl\u00e8me, une r\u00e8gle flightPATH rapide est \u00e0 votre disposition en quelques minutes. Idem pour la compression HTTP, les r\u00e9\u00e9critures d’<\/a> URL ou tout ce dont vous avez besoin. Un seul service virtuel et une seule adresse IP pour plusieurs domaines sont tr\u00e8s souhaitables, mais ils ne doivent pas restreindre le traitement unique que vous pourriez vouloir appliquer au trafic des diff\u00e9rents domaines. <\/p>\n Je vous entends : \u00ab\u00a0Quel est le probl\u00e8me ?\u00a0\u00bb Eh bien, il y en avait certainement un et c’est la raison pour laquelle SNI existe depuis si longtemps mais n’appara\u00eet que maintenant dans l’\u00e9quilibrage de charge et d’autres produits. Cette raison ? Le support client. La long\u00e9vit\u00e9 de l’incroyablement populaire combinaison Windows XP et IE6, qui ne prend pas en charge SNI, a emp\u00each\u00e9 la plupart des utilisateurs de l’utiliser. Personne ne veut se priver de 10 \u00e0 20 % de son public. <\/p>\n Windows XP a largement d\u00e9pass\u00e9 la fin de son support, IE6 est utilis\u00e9 \u00e0 moins de 1% sur le web sauvage et la mise \u00e0 jour gratuite vers Windows 10 est pouss\u00e9e et adopt\u00e9e rapidement. Nous pouvons enfin \u00eatre s\u00fbrs que la mise en \u0153uvre de SNI n’aura pas d’impact sur nos clients et nos activit\u00e9s. IE 7 et plus (sur Vista ou version ult\u00e9rieure) et presque toutes les versions de Chrome, Firefox et Safari, \u00e0 l’exception des plus anciennes, supportent SNI. Si vous souhaitez v\u00e9rifier et \u00eatre s\u00fbr de votre base d’utilisateurs sp\u00e9cifique, il existe une r\u00e8gle flightPATH pour cela aussi. <\/p>\n En ce qui concerne la s\u00e9curit\u00e9, soyons clairs : le client fournit des informations en texte clair. Il s’agit d’informations qui peuvent \u00eatre captur\u00e9es sur le fil. Le client effectue une requ\u00eate DNS en texte clair avant de se connecter. Nous ne pouvons pas contr\u00f4ler cela, et il n’est donc pas consid\u00e9r\u00e9 comme un risque de r\u00e9v\u00e9ler cette information une seconde fois par la suite. Peut-\u00eatre voudrez-vous v\u00e9rifier que le nom de domaine SNI correspond \u00e0 celui trouv\u00e9 dans l’en-t\u00eate HTTP Host, avec une r\u00e8gle flightPATH, ou peut-\u00eatre vous en moquez-vous, tout le monde est diff\u00e9rent. Cela sugg\u00e8re-t-il un probl\u00e8me de s\u00e9curit\u00e9 ? Quoi qu’il en soit, le client est connect\u00e9 et la connexion est s\u00e9curis\u00e9e. \u00c0 moins que vous n’appliquiez une politique de s\u00e9curit\u00e9 bas\u00e9e sur le nom de domaine (et vous ne devriez pas le faire), tout va bien. <\/p>\n Si vous voulez vraiment plus de d\u00e9tails, jetez un coup d’\u0153il \u00e0 la RFC3546<\/a>originale (section 3.1), \u00e0 la RFC6066<\/a>plus r\u00e9cente (section 3) et, si vous pensez qu’elle est digne de confiance : Server Name Indication sur Wikipedi. Si vous avez besoin d’une s\u00e9curit\u00e9 au niveau de l’application, le WAF de edgeNEXUS est bas\u00e9 sur une technologie de pointe de pare-feu d’application renforc\u00e9e. Disponible via l’App Store de edgeNEXUS et utilisant la technologie de conteneur de nouvelle g\u00e9n\u00e9ration, le pare-feu applicatif de edgeNEXUS offre une protection de s\u00e9curit\u00e9 compl\u00e8te pour r\u00e9pondre aux exigences de conformit\u00e9 PCI-DSS et OWASP. Comme nous l’avons vu dans de pr\u00e9c\u00e9dents articles de blog, flightPATH est un moteur de r\u00e8gles dynamique, bas\u00e9 sur des \u00e9v\u00e9nements, d\u00e9velopp\u00e9 par edgeNEXUS pour manipuler et acheminer intelligemment le trafic IP, HTTP et HTTPS \u00e0 charge \u00e9quilibr\u00e9e. Pour en savoir plus sur la gestion du trafic flightPATH, veuillez cliquer ici, et pour d\u00e9couvrir comment tirer pleinement parti des r\u00e8gles disponibles, veuillez consulter le Guide de l’utilisateur edgeNEXUS. <\/p>\n <\/p>\n Un seul service virtuel (et une seule adresse IP) peut \u00eatre configur\u00e9 avec autant de certificats SSL pour autant de noms de domaine que vous souhaitez qu’il serve. Chacun peut avoir un certificat SSL d\u00e9di\u00e9 et valide, fourni correctement sans erreur, sur la base des donn\u00e9es fournies par le client. <\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":" 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 \u00e9trangement peu utilis\u00e9 ; bien que cela change enfin, et c’est dans ce blog que nous explorons comment les \u00e9quilibreurs de charge avanc\u00e9s d’edgeNEXUS peuvent prendre en charge cette […]<\/p>\n","protected":false},"author":13,"featured_media":34794,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[375],"tags":[1028,389,1026,1030,1032,1024],"class_list":["post-51178","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-fr","tag-certificats-ssl","tag-equilibreur-de-charge","tag-identification-du-nom-du-serveur","tag-securite-ssl","tag-ssl-fr","tag-tls-sni-fr"],"yoast_head":"\n