безопасность http до https redirect

Question

У меня есть сайт, который является 100% https и будет работать только как https. Мой сайт - это приложение asp.net mvc, работающее на IIS 7.5.

Он находится на нескольких серверах с распределением трафика через балансировщик нагрузки.

Я не контролирую оборудование.

Для http-запросов я надеялся, что он может быть остановлен на балансировщике нагрузки и перенаправлен на https в этот момент.

Однако аппаратная компания не сделает этого для меня, и вместо этого мне нужно сделать перенаправление с http на https в IIS на сервере. Поэтому незашифрованный трафик может войти во внутреннюю сеть с перенаправлением на уровне сервера. Я бы чувствовал себя более комфортно с такой передачей, происходящей на балансировщике нагрузки.

Есть ли у меня веские опасения?

Answer 1

Threat модель:

HTTP request: 

      Attacker 
       |   Security Boundary 
       V   V 
Client -- http request --> Load Balancer 
           | 
Client <-- redirect -----------+ 

угроз, которые происходят от разрешения HTTP перенаправления независимо от методологии:

• подмены: Клиент может подключиться к MITM подделать HTTP-сервер, который не проходит через редирект, но вместо проксирует соединения с фактическим сервером HTTPS
• Нарушение: Клиент может получать URL-адрес перенаправления с поддельного сервера MITM, который направляет их на другое действие (например: клиент получает перенаправление на https://yoursite.com/login.aspx?redirect=/deleteAllDocuments)
• Раскрытие информации: раскрывается первоначальный запрос HTTP, любая информация в POST или GET доступна для незашифрованного доступа к подслушивающим устройствам.

Аргументов для выполнения перенаправления на сервере, кроме целевого сервера:

• Firewall может быть ограничен HTTPS данных, ограничивая риск незашифрованных данных из-за неправильную
• Конфигурация и ответственность могут стать «Чужой проблема ", по крайней мере с политической точки зрения
• Уязвимости на HTTP-сервере будут изолированы и не могут использоваться для атаки на сервер HTTPS или базовое приложение

Аргументов для выполнения перенаправления на что-то другое, чем балансировки нагрузки:

• нагрузки балансиры не являются серверами
• нагрузки балансиров не являются серверами, и, следовательно, может быть легко использованы пути коды при использовании в качестве серверов, может быть более склонны к нераскрытым ошибок или проблем с производительностью
• Конфигурация не доступна для вас, но вы (или ваша компания) до сих пор, вероятно, несет ответственность за любой неправильной конфигурации, которые происходят (с юридической точки зрения)

В свете приведенного выше анализа, для самой высокой безопасности с минимальным риском:

• Я бы не поставить редирект на целевом сервере, ни балансировки нагрузки, но вместо этого на виртуальной машине, которая служит только для перенаправлять страницы. Минимальное окно Linux или окна должно быть надежно заблокировано для ограничения экспозиции.
• я не позволил бы перенаправляю с запросом струнных или POST данными (например, показывает 404 для любого не GET/HTTP/1.1 запроса)
• я бы назвал возможность подмены и подделок приемлемого риска, или показать страницу пользователя объясняя, что сайт должен быть доступен с использованием HTTPS вместо использования перенаправления

Но, если вы можете предположить, что выполняются следующие условия, размещение промежуточного сервера HTTP-сервера с сервером HTTPS не должно уменьшать безопасность.

• Любая ошибка в сервере HTTP присутствует на сервере HTTPS
• сервер HTTP правильно настроен, чтобы запретить доступ к защищенным ресурсам (созданных в качестве отдельного сайта в IIS, например. Безопасный сайт до сих пор нет HTTP не обязательный)
• ни одно другое приложение может создать сервер по протоколу HTTP (netsh urlacl имеет только IIS, например)
• Конфигурация аудит, чтобы обеспечить вышеуказанные конфигурации обслуживаются надлежащим образом (Периодическая перо тесты, ручной обзор конфигурации, управление изменениями конфигурации и система IDS или IPS)

В некоторых случаях уменьшенная сложность может быть даже легче защищена, чем отдельный сервер. Кроме того, если администратор не знаком с конфигурацией балансировщика нагрузки, они могут быть более склонны к критической ошибке в конфигурации, чем если бы они должны были сделать такую ​​же конфигурацию в хорошо известном продукте.

Answer 2

У меня есть веские опасения?

У вас есть веская озабоченность по поводу того, что начальное соединение связано с HTTP? Конечно. Исходный запрос может быть перехвачен, а ответ подменяется при атаке MitM. Затем злоумышленник может либо запретить пользователю использовать HTTP (добавление ssl/tls между злоумышленником и вашим сервером и ретрансляцию жертве в явном виде), либо может создать сеанс SSL-клиенту с клиентом, который завершается у злоумышленника, зашифрованы на вашем пути к вам (используя различные методы подмены, чтобы сделать атаку менее очевидной для случайного пользователя).

Однако, если бы такая атака была запущена, я был бы далеко больше беспокоился о транзите от клиента к вашему балансировщику нагрузки, а не между вашим балансировщиком нагрузки и IIS. Если вы подозреваете, что у вас есть опасные системы за балансиром нагрузки, у вас есть совершенно другой набор проблем.

Answer 3

См. my answer по адресу security.so для получения некоторой релевантной информации о перенаправлении с HTTP на HTTPS.