Я надеюсь, что кто-нибудь сможет прояснить странную проблему, которая возникает у нас по состоянию на 3 февраля 2019 года.
У нас есть веб-сервер Windows (2008R2, IIS7.5) в облаке AliYun (например, китайский AWS, поэтому этот ящик является виртуальной машиной, как экземпляр EC2). На сервере IIS размещено несколько сайтов на поддоменах, для которых у нас есть групповой сертификат (например, https://app.example.com/ и https://api.example.com, а наш подстановочный знак - для * .example.com). Недавно мы обновили этот сертификат, установив полностью связанный файл PFX, как обычно. Сразу после тестирования сайтов все было нормально, и HTTPS-сайты обслуживались с новым сертификатом.
Вскоре после этого (например, через день) HTTPS перестал работать должным образом. Клиенты, подключающиеся из вне из Китая получит сообщение об ошибке после подтверждения TLS, указывающее, что сервер сбросил соединение. Те же сайты будут нормально загружаться с самого сервера или из любого другого места. в пределах Китай из которого мы тестировали. В любом месте вне Китая, из которого мы тестировали, получили такие же ошибки сброса соединения.
Откат подстановочного сертификата к предыдущему (хотя срок его действия скоро истекал) никак не повлиял на проблему. Кроме того, обновленный сертификат был признан действительным клиентами в Китае, наша версия TLS и шифры отображались как OK в браузерах и т. Д. IIS и SChannel на сервере не сообщали о проблемах - на самом деле, неудачные соединения даже не появляются в журналах IIS.
Мы дважды проверили привязки в IIS (все правильно и с использованием обновленного сертификата), настройки брандмауэра Windows (не включены), свойства сертификата (полностью связанные, включая понятное имя, правильный SAN и т. Д.). Мы прочесали наши настройки TLS на предмет версии и шифров, например с участием IISCrypto и правки реестра, и все они были обновлены, насколько может поддерживать .NET4.0.
Ни один из этих параметров не повлиял на возможность подключения к сайтам HTTPS на сервере изнутри, но не за пределами Китая.
Большинство дополнительных тестов я проводил на компьютере в Нью-Йорке.
telnet, мы можем подключиться к серверу через порт 443, исключая простое правило сетевого брандмауэра на основе порта TCP. traceroute, мы видим таймауты, когда запрос попадает в Китай, но ничего сумасшедшего - и, как обычно, обычный текстовый HTTP работает нормально из любого места.nslookup, серверы разрешения и имен находятся там, где они должны бытьtcpdump -vv -i any host x.x.x.x and port 443 дал достаточно интересный захват пакетов: он показывает, что пакеты RST появляются после рукопожатие TLS / приветствие клиента вместо согласования шифров или любой полезной нагрузки: снимок экрана из Wireshark, вид файла pcap, полученного с помощью tcpdump, с удаленным IP-адресом сервераКогда я включил CloudFlare в домене для проксирования DNS и завершения SSL (т.е. чтобы исходный сервер в Китае обслуживал CloudFlare через простой HTTP на порт 80, но использовал общий SSL CloudFlare для клиентов (он же «Гибкий» SSL в плане CloudFlare) ), симптомы были перевернутый - только клиенты за пределами Китая будут видеть сайты HTTPS, в то время как клиенты в Китае, включая локальный сервер, увидят сброс соединения по URL-адресу HTTPS.
У нас есть домен .CN, указывающий на тот же сервер IIS, что и поддомены example.com. При посещении через этот домен - например, https://example.cn/ - соединение загружается должным образом (вы должны согласиться с тем, что используемый сертификат SSL является подстановочным знаком для * .example.com, а затем вы можете загрузить сайт с предупреждением). Пакеты RST также не появляются в захватах пакетов. К слову, домен .CN дает почти идентичные результаты в nslookup, traceroute, и т.д.
Мне кажется, что так называемый «Великий брандмауэр» работает, то есть подделывает и вводит RST-пакеты в это соединение. Пакеты RST не следуют тем же шаблонам, которые описаны в Уивер и др. или Клейтон и др., но в каждом случае они довольно близки. Имеет ли это смысл? Если да, то есть ли какой-нибудь другой тест, который мы могли бы провести, чтобы окончательно показать, что это так? (отредактировано для ясности вопроса)
У меня нет доступа к облачной «приборной панели» для хостинга для этого компьютера, но мой коллега проверяет это на случай, если возникнет проблема сетевого уровня, которую мы могли бы решить таким образом. Что мы должны проверить, в частности, там?
У нас есть номер ICP, который при необходимости можно применить для нашего домена .CN. (отредактировано для ясности)
Очевидно, мы хотели бы иметь возможность обслуживать наши сайты на их доменах .COM для посетителей как в Китае, так и за его пределами, через HTTPS, с нашего существующего сервера, используя наш сертификат с подстановочными знаками, как мы это делали раньше. Что нам делать?
Это тот случай, когда отправляется любой TCP-пакет полезной нагрузки, RST отправляется обратно? Или это должно быть именно TLS / Client Hello? т.е. если вы вводите что-то после установления соединения telnet, соединение закрывается / сбрасывается?
Много лет назад я работал в компании, которая разрабатывала технологии, использующие аналогичные механизмы. С точки зрения частного лица, пока я был там сотрудником, я смог придумать работу, которая отфильтровывала / задерживала такие пакеты, когда они были отправлены клиенту, эффективно нарушая такую глупость TCP, но я заметил, что они небольшая хитрость в рукаве, которая сделала мою работу с методологией полностью излишней. По сути, через настраиваемую конфигурацию, которую они контролировали, они могли сбросить TCP-соединение на обе сторонам, клиенту и серверу, путем инъекции пакетов как исходному запрашивающему клиенту, так и целевому серверу, поэтому даже с фильтрацией, которую я придумал, удаленный сервер также был испорчен, и поток прервался. Если это то, что здесь происходит, я не очень надеюсь на существование какого-либо решения для этого.
Я понимаю, что это бесполезный ответ, но то, что я хотел напечатать выше, не подходило для комментария. Просто хотел сообщить вам, что очевидно, что существует вредоносный инжектор пакетов на маршруте туда и обратно, где размещен ваш сервер.
Вы упомянули, что это работает для веб-сайта .CN, но не для .COM, размещенного на том же сервере (правильно?). Вы проверяли, что произойдет, если вы полностью остановите веб-сервер, чтобы ничего не прослушивалось на порту 443, а затем подключились к нему через порт 443 из-за пределов Китая? Если вы получаете то, что выглядит как открытый порт, значит, есть встроенное устройство, действующее как человек посередине, что ясно демонстрирует существование какого-то устройства фильтрации / брандмауэра, известного как «Великий брандмауэр».
