HttpWebRequest для SSL не удается

StackOverflow https://stackoverflow.com/questions/228931

  •  04-07-2019
  •  | 
  •  

Вопрос

Я использую этот код, чтобы сделать запрос на заданный URL: 

private static string GetWebRequestContent(string url)
{
  string sid = String.Empty;

  HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(url);
  req.KeepAlive = false;

  using (HttpWebResponse res = (HttpWebResponse)req.GetResponse())
  {
    using (StreamReader sr = new StreamReader(res.GetResponseStream()))
    {
      sid = sr.ReadToEnd().Trim();
    }
  }

  return sid;
}

Я использую его для проверки липкости Work Load Balancer, за которой стоят 3 сервера. Все они имеют статический HTM-файл с именем sid.htm, в который записывается идентификатор сервера.

Для URL с HTTP это работает нормально. Но с HTTPS это не работает. Я получаю это исключение:

  

Запрос был прерван: не удалось создать безопасный канал SSL / TLS.

На данный момент у меня есть только 2 сервера за WLB и один отдельно с публичным IP за брандмауэром. HTTPS-запросы работают нормально, если я подключаюсь к автономному серверу, но когда я подключаюсь к WLB, я получаю вышеуказанную ошибку.

Одно: чтобы переключаться между попаданием на один сервер и WLB, я использую файл hosts. Записи DNS для моего домена в данный момент указывают на один сервер. Поэтому я поместил запись в файл хостов, чтобы попасть в WLB. Это не должно вызывать проблем ...

Мой вопрос . Какие учетные данные / сертификаты SSL использует HttpWebRequest? Если он использует 40-битный DES или 56-битный DES, это причина, потому что они отключены в WLB. Но эти сертификаты не использовались в браузерах начиная с IE3 и Netscape 1 и 2.

Это было полезно?

Решение

Он отлично работает в моем браузере.

Я нашел решение через 1 минуту после того, как опубликовал вопрос: 

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

И это означает, что HttpWebRequest использовал TLS 1.0 - я не знаю, но я предполагаю, что это 40-битный DES или 56-битный DES, который отключен в WLB.

Другие советы

Есть что-то, что вы могли бы рассмотреть с балансировщиком нагрузки. Те, которые мы используем, перенаправляют защищенный трафик HTTPS на серверы за ним по небезопасному HTTP-соединению. Соединение между балансировщиком нагрузки и браузером по-прежнему защищено, но нет необходимости в дополнительном заголовке защищенного протокола между балансировщиком и веб-серверами.

Мы хотели обнаружить безопасное соединение на наших веб-серверах, но изначально никогда не видели HTTPS-соединение. Тогда мы поняли, что движение за балансировщиком было небезопасным. Имело смысл, как только мы знали.

Теперь мы пересылаем весь безопасный трафик, поступающий в балансировщик (порт 443), на порт 81 (альтернативный HTTP), а затем пересылаем весь обычный трафик HTTP (порты 80 и 81) на порт 80. Затем мы можем проверить порт на веб-сервере и знаю, что 80 небезопасен, а 81 - защищенный трафик между браузером и балансировщиком, несмотря на то, что все это HTTP на веб-сервере.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top