Comment les clients SNI envoyer nom_serveur dans CLIENT BONJOUR

Question

J'espère que je suis au bon endroit posant cette question, son sujet compréhension de la SNI

Selon https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication#.U5wEnfmSzOz « Avec l'introduction de la SNI, le client peut indiquer le nom du serveur auquel il tente de se connecter dans le cadre du message "Client Hello" dans le processus de prise de contact "

Ma question est de savoir comment un client comme navigateur ou n'importe quel client HTTP (disons java.net) envoie ce nom de serveur chez CLIENT HELLO ?? Est-ce que le client faire lui-même ou vous devez ajouter demande Programmatically à https (par exemple, comment dans JAVA.net HttpsURLConnection)

lecture de http://www.ietf.org/rfc/rfc4366.txt « Actuellement, les seuls noms de serveurs pris en charge sont les noms d'hôte DNS » donc le nom d'hôte est le nom_serveur envoyé par le client SNI complient ou tout autre nom peut être envoyé par le client ..

J'espère que je suis clair, qui améliore effectivement la question/libellé si elle sait pas ou me faire savoir si ses pas claires grâce

Answer 1

Si vous utilisez une bibliothèque https, vous pouvez donner une URL et la bibliothèque récupérera le contenu de Si cette URL est pour vous, la meilleure façon d'ajouter le support SNI est de l'exécuter entièrement dans la bibliothèque.

C'est la bibliothèque qui analyse l'URL pour trouver le nom d'hôte, l'appelant ne saura jamais quelle partie de l'URL est le nom d'hôte, donc l'appelant n'a pas pu dire à la bibliothèque quel nom d'hôte envoyer dans la demande SNI. Si l'appelant devait trouver le nom de l'hôte pour le dire à la bibliothèque, alors ce serait une bibliothèque mal conçue.

Vous pouvez regarder un niveau plus profond dans la pile logicielle et constater qu'une bibliothèque https peut être construite au-dessus d'une bibliothèque SSL. Dans ce cas, même la bibliothèque https n'a pas besoin de connaître SNI. La bibliothèque https indique simplement à la bibliothèque SSL qu'elle souhaite une connexion à un nom d'hôte particulier. La bibliothèque SSL résoudrait le nom d'hôte pour obtenir l'adresse IP à laquelle se connecter, la bibliothèque SSL effectuerait également la négociation SSL au cours de laquelle le client pourrait envoyer un nom d'hôte dans le SNI et le serveur enverrait un nom d'hôte client à vérifier.

Lors de la configuration de la connexion, la bibliothèque cliente SSL doit utiliser le nom d'hôte à trois fins différentes. Il serait trivial de prendre en charge l'utilisation de trois noms d'hôte différents pour ces trois objectifs. La bibliothèque https connaît déjà le nom d'hôte, et transmettre ce nom d'hôte trois fois à la bibliothèque SSL plutôt qu'un seul ne serait pas une quantité importante de travail supplémentaire. Mais il ne serait guère logique de soutenir cela de toute façon. En fait, SNI pourrait être entièrement transparent pour la bibliothèque https. Il serait logique d'étendre la bibliothèque SSL avec le support SNI sans changer l'API pour la bibliothèque https. Il y a peu de raison de désactiver le support SNI dans un client, qui le supporte. Par conséquent, l'activation de SNI est logique.