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

Question

Я использую этот код, чтобы сделать запрос на указанный 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.

Answer 1

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

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

Answer 2

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

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

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