SNI: hébergement virtuel pour HTTPS

Introduction

Hébergement virtuel est la pratique de servir plusieurs sites Web sur le même serveur. Bien que ce soit la norme de nos jours, cela n'était pas possible dans les premiers jours de HTTP (versions antérieures à 1.1).

Remarque: Bien que ce ne soit pas techniquement correct, aux fins de cet article, «même serveur» indique que tous les noms de domaine pointent vers le même adresse IP et numéro de port.

À l'origine, un serveur ne pouvait héberger que plusieurs sites Web sur la même machine (c'est-à-dire sous la même adresse IP) à condition que chaque site Web se voit attribuer un port dédié. Ce n'était pas une solution idéale car les navigateurs utilisent par défaut le port 80 pour HTTP, sauf si l'utilisateur en spécifie un autre. En conséquence, la plupart des propriétaires de sites Web ont opté pour un serveur dédié pour éviter le risque que les utilisateurs ne se souviennent pas du bon numéro de port et se retrouvent sur un autre site Web.

Hébergement de plusieurs sites sur plusieurs ports

Néanmoins, à mesure que de plus en plus d'utilisateurs ont rejoint le Web et que de plus en plus d'appareils réseau ont commencé à apparaître en ligne, le nombre d'adresses IP disponibles a commencé à diminuer à un rythme alarmant. Cet épuisement anticipé, appelé Épuisement de la plage d'adresses IPv4, a conduit l'industrie à concevoir et à mettre en œuvre diverses contre-mesures, telles que IPv6 (Successeur d'IPv4), qui peut prendre en charge plus d'adresses que nous n'aurons jamais besoin. Malheureusement, bien qu'IPv6 soit une solution viable, son adoption a été assez lente. Selon Statistiques IPv6 de Google, au moment d'écrire ces lignes, environ 25% des appareils Internet sont déployés sur IPv6.

L'hébergement virtuel a également été implémenté comme une atténuation précoce du problème d'épuisement, avec l'introduction du Host en-tête dans HTTP 1.1. Les navigateurs communiquant via HTTP 1.1 pouvaient désormais se connecter au port d'un serveur 80 et inclure le nom de domaine (par exemple www.ssl.com) du site Web qu'ils souhaitaient visiter dans le Host entête. Quel que soit le nombre de sites hébergés par un serveur sur le même port, il pourrait utiliser ces informations pour identifier le site Web correct et renvoyer son contenu.

Hébergement de plusieurs sites sur un seul port - hébergement virtuel

HTTPS et hébergement virtuel

Cependant, de nombreux rapports publiés sur les vulnérabilités du réseau et les attaques contre les internautes ont motivé l'industrie à commencer à s'éloigner du HTTP non sécurisé, à son alternative HTTPS plus sécurisée. La large adoption de HTTPS a amélioré la sécurité globale des utilisateurs. Cependant, ses améliorations supplémentaires ont également augmenté la complexité générale des communications Web.

En principe, HTTPS est assez similaire à HTTP, à l'exception du fait que les communications HTTPS entre les navigateurs et les serveurs sont cryptées. En bref, HTTPS exige que les serveurs fournissent aux navigateurs un certificat SSL valide émis par un public approuvé autorité de certification (CA), comme SSL.com. Un navigateur peut ensuite utiliser la clé publique contenue dans le certificat pour établir un canal de communication crypté avec le serveur. En outre, un certificat est émis pour un nom de domaine spécifique, que le navigateur vérifie pour une correspondance avec le domaine que l'utilisateur souhaite visiter. Ainsi, quel que soit le nombre de sites Web hébergés par le serveur, les navigateurs s'attendent à trouver un certificat SSL valide pour le site Web qu'ils ont demandé.

Le lecteur attentif peut déjà sentir le problème: le navigateur a besoin du bon certificat du site Web pour établir le canal crypté et envoyer le Host en-tête, tandis que le serveur a besoin de la Host en-tête pour localiser le certificat du site correct. C'est un problème classique de la poule et de l'œuf.

Remarque: Bien que le terme hébergement virtuel a été initialement inventé pour les sites HTTP, il a également été transféré sur HTTPS. Il fait référence à la même pratique d'hébergement de plusieurs sites Web sur un même serveur, quelle que soit la méthode de mise en œuvre réelle.

Il est évident que l'hébergement virtuel tel qu'il a été conçu pour HTTP ne fonctionne pas pour HTTPS, car les contrôles de sécurité empêchent les navigateurs d'envoyer les Host informations sur le serveur. Néanmoins, le problème d'épuisement d'IPv4 n'étant toujours pas résolu et l'adoption croissante par l'industrie des technologies cloud (qui nécessitent un équilibrage de charge et plusieurs serveurs backend de basculement), l'hébergement virtuel est toujours une nécessité.

Qu'en est-il des certificats multi-domaines?

Une solution proposée à ce problème est l'utilisation de plusieurs domaines ou Certificats SAN. Un seul certificat SAN peut sécuriser des centaines de noms de domaine différents, et les navigateurs ne se plaindront pas s'ils trouvent le nom de domaine qu'ils essaient de visiter dans la liste de domaines du certificat SAN. Une fois le canal crypté configuré, le navigateur peut envoyer le Host en-tête au serveur et continuez comme dans tout autre cas. C'est une excellente idée qui utilise une technologie déjà présente et disponible, mais les mêmes mécanismes qui assurent la sécurité des certificats SAN ont également introduit quelques effets secondaires potentiellement indésirables:

Les certificats SAN sont un excellent outil pour sécuriser plusieurs domaines appartenant à la même entité (personne, entreprise ou organisation), mais ils sont peu pratiques à utiliser dans l'hébergement partagé; chaque fois qu'un nouveau domaine est prêt à être ajouté ou supprimé du certificat, un nouveau certificat avec la dernière liste de domaines doit être émis par l'autorité de certification et redéployé sur tous les domaines.

De plus, les certificats SAN ne peuvent être émis que Organisation validée (OV) ou Extended Validated (EV) if TOUTE les domaines appartiennent à la même organisation. Ces niveaux de validation se réfèrent à la quantité et types d'informations sur le propriétaire potentiel du certificat vérifiées par l'autorité de certification avant de leur délivrer le certificat. Il a été démontré que plus le niveau de validation est élevé, plus les utilisateurs accordent de confiance au site Web et la confiance des utilisateurs peut affecter la reconnaissance de la marque et les taux de conversion.

Enfin, il est assez courant dans les environnements d'hébergement Web partagé qu'une entreprise partage un serveur avec d'autres entreprises ou organisations (même avec ses concurrents). Étant donné que les domaines des certificats SAN sont répertoriés publiquement, les propriétaires d'entreprise peuvent hésiter à partager le même certificat avec des sociétés tierces.

Bien que les certificats SAN soient des outils puissants et polyvalents avec d'innombrables applications, ces problèmes ont motivé l'IETF - l'organe directeur des normes Internet - à rechercher des approches mieux adaptées au problème spécifique des sites Web HTTPS virtuellement hébergés.

Indication du nom du serveur à la rescousse

La solution a été mise en œuvre sous la forme du Indication du nom du serveur (SNI) extension du TLS protocole (la partie de HTTPS qui traite du chiffrement).

SNI permet aux navigateurs de spécifier le nom de domaine auquel ils souhaitent se connecter TLS poignée de main (la négociation initiale du certificat avec le serveur). En conséquence, les sites Web peuvent utiliser leurs propres certificats SSL tout en restant hébergés sur une adresse IP et un port partagés, car les serveurs HTTPS peuvent utiliser les informations SNI pour identifier la chaîne de certificats appropriée requise pour établir la connexion.

Ensuite, lorsque le canal de communication crypté a été configuré, le navigateur peut continuer à inclure le nom de domaine du site Web dans le Host en-tête et continuez comme il le ferait normalement. Essentiellement, SNI remplit la même fonction que HTTP Host en-tête lors de la création de la connexion cryptée.

Hébergement virtuel de sites Web HTTPS avec SNI

Cette astuce simple a finalement permis aux serveurs d'héberger plusieurs sites Web HTTPS sur le même port. Cependant, comme avec la plupart des technologies Internet, SNI présente certaines limites.

Problèmes de support SNI

Bien que SNI soit assez mature depuis sa création en 1999, il existe encore quelques anciens navigateurs (IE sous Windows XP) et systèmes d'exploitation (versions Android <= 2.3) qui ne le prennent pas en charge. Pour une liste complète des navigateurs et des systèmes d'exploitation prenant en charge SNI, veuillez consulter cette table.

Bien que les parts de marché des navigateurs qui ne prennent pas en charge SNI (et par extension les occurrences de ce qui se passe) sont minuscules par rapport aux navigateurs modernes, si un navigateur ne reconnaît pas SNI, il reviendra au certificat SSL par défaut et produira potentiellement un erreur de discordance de nom commun.

De nombreuses entreprises, telles que Google, implémentent SNI pour les clients qui le prennent en charge et recourent aux certificats SAN pour les rares cas qui ne le font pas. Naturellement, ce problème devrait diminuer à mesure que de plus en plus d'utilisateurs et de propriétaires d'entreprises mettent à niveau leurs systèmes vers des technologies modernes.

Problèmes de confidentialité de SNI

La version stable actuelle de TLS (version 1.2) transmet la partie initiale de la poignée de main, et par extension les informations SNI, non cryptées. Par conséquent, un attaquant du réseau peut découvrir l'historique Web d'un utilisateur, même si les communications Web elles-mêmes sont entièrement chiffrées.

Divers fournisseurs de services cloud, tels qu'Amazon ou Google, ont autorisé une solution de contournement (sale) connue sous le nom de façade de domaine. La façade de domaine peut empêcher la divulgation de l'historique Web, car elle masque les informations SNI en utilisant le nom d'hôte du fournisseur de cloud dans le TLS négociation et le site cible dans l'en-tête HTTP. Cependant, cette méthode n'est plus viable, puisque Google et Amazon ont déclaré publiquement qu'ils prise en charge désactivée pour la façade de domaine dans leurs services en avril 2018.

Heureusement, une solution plus systémique a été proposée en tant que projet expérimental détaillant le SNI crypté (ESNI) extension pour le plus récent TLS version, 1.3. ESNI crypte les informations SNI, atténuant ainsi tous les problèmes de confidentialité. Malheureusement, TLS 1.3 n'est pas encore largement adopté par l'industrie, même si TLS 1.3 devient lentement le protocole de sécurité réseau de facto. Gardez un œil sur nos futurs articles sur le statut d'ESNI et la confidentialité de HTTPS et TLS.

Conclusion

En résumé, avec SNI, vous pouvez héberger des millions de sites Web HTTPS sur un seul serveur. Cependant, selon votre cas individuel, un certificat SAN peut mieux fonctionner pour vous. Les problèmes de confidentialité concernant SNI existent toujours, bien qu'il existe également une solution potentielle avec ESNI. Dans tous les cas, en utilisant une ou une combinaison de ces deux méthodes, vous pouvez facilement implémenter un hébergement virtuel pour tous vos sites Web avec un minimum d'effort.


Si vous avez d'autres questions sur SNI ou si vous ne savez pas comment choisir entre SAN et SNI, nous serons toujours heureux de répondre à toutes les questions de nos clients sur leur PKI Besoins. Envoyez-nous un e-mail à support@ssl.com et un expert vous aidera.

Abonnez-vous à la newsletter SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com

Restez informé et en sécurité

SSL.com est un leader mondial de la cybersécurité, PKI et les certificats numériques. Inscrivez-vous pour recevoir les dernières nouvelles de l'industrie, des conseils et des annonces de produits de SSL.com.

Nous aimerions recevoir vos commentaires

Répondez à notre enquête et faites-nous part de votre avis sur votre récent achat.