Это довольно старое сообщение, но этот ответ может помочь некоторым людям, по крайней мере, это стоило мне нескольких дней.
По умолчанию для платформы .NET Framework поддерживается указатель имени сервера. (Проверено на 4.5.1 но я предполагаю, что это то же самое, по крайней мере для .NET 4.5+)
короткий пример:
HttpResponseMessage response;
var httpRequestMessage = new HttpRequestMessage(HttpMethod.Get, "https://www.google.com");
var handler = new HttpClientHandler
{
CookieContainer = new CookieContainer()
};
using (var client = new HttpClient(handler))
{
response = client.SendAsync(httpRequestMessage).Result;
}
Это очень стандартный способ создания запроса GET в пределах C#. Вы увидите, что этот пример запускается с использованием, в моем случае, TLS 1.2 с SNI. Если вы используете Wireshark для просмотра фактических пакетов, которые будут отправлены, вы увидите Client Hello с указателем имени сервера, установленным на www.google.com.
Проблема, с которой мы столкнулись: Тег SNI установлен .NET Framework (или Schannel by Windows, не уверен) на основе URL-адреса, переданного в конструкторе HttpRequestMessage. Если вы знаете, инициализировать запрос, основанные на некоторую URL (например, https://www.google.com), а позже вы переключите RequestUriИЛИ Локальной заголовка , тег SNI еще будет создан на основе оригинального URL URL. Это может иметь место, например, если вы передадите запрос и переназначаете все исходные заголовки на вновь созданный запрос.
Наш SecureBlackbox полностью поддерживает SNI в клиентских и серверных компонентах TLS –
Спасибо, я проверю это. – woollybrain
SNI - это расширение TLS, а не SSL, поэтому первый шаг - выбор правильного протокола. Но да, .NET с 4.5 не поддерживает SNI, что позорно. http://connect.microsoft.com/VisualStudio/feedback/details/729925/net-4-4-5-sslstream-no-supports-the-tls-server-name-indication-sni –