HTTPS от веб-сервера в Китае блокируется TCP-пакетами RST (Великий брандмауэр?)

Я надеюсь, что кто-то может дать некоторое представление о странной проблеме, которая у нас возникла по состоянию на 3 февраля 2019 года.

TL; DR

• HTTPS-сайты на сервере IIS в Китае возвращают пакеты TCP RST после первоначального подтверждения связи TLS.
• Сайты показывают ошибки "сброса соединения" клиентам за пределами Китая. * Те же сайты доступны из Китая через HTTPS.
• Прокси-соединение с CloudFlare для DNS и прекращение SSL устраняет эту проблему (доступно только из-за пределов Китая, сброс соединения изнутри).
• Домен.CN на том же сервере может обслуживать HTTPS за пределами Китая, используя сертификат подстановочного знака для домена.COM (после принятия недействительного сертификата).

Фон

У нас есть веб-сервер Windows (2008R2, IIS7.5) в облаке AliYun (например, китайский AWS, поэтому этот блок представляет собой виртуальную машину, похожую на экземпляр EC2). Сервер IIS размещает несколько сайтов на поддоменах, для которых у нас есть сертификат с подстановочными знаками (например, https://app.example.com/ и https://api.example.com/, и наш подстановочный знак предназначен для *.example.com). Недавно мы обновили этот сертификат, установив полностью связанный файл PFX, как это обычно делается. Сразу после тестирования сайтов все было нормально, и HTTPS-сайты получили новый сертификат.

Вскоре после этого (например, через день) HTTPS перестал работать, как ожидалось. Клиенты, подключающиеся из- за пределов Китая, получат сообщение об ошибке после квитирования TLS, указывающее, что сервер сбросил соединение. Эти же сайты будут нормально загружаться с самого сервера или любого другого места в Китае, с которого мы тестировали. Любое местоположение за пределами Китая, из которого мы тестировали, получало те же ошибки сброса соединения.

Устранение неисправностей и тестирование

Откат сертификата с подстановочными знаками к предыдущему сертификату (хотя срок его действия истекает) не повлиял на проблему вообще. Кроме того, обновленный сертификат был признан действительным клиентами в Китае, наша версия TLS и шифры в браузерах показывали, что они в порядке, и т. Д. 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 / клиента Hello, вместо согласования шифра или любой полезной нагрузки: снимок экрана с видом Wireshark файла pcap, полученного через tcpdump, с удаленным IP-адресом сервера
• (отредактировано, чтобы добавить:) Захват пакетов на сервере показывает аналогичные схемы: RST-пакеты, полученные - якобы от клиента - сразу после рукопожатия TLS и Client Hello.

Когда я включил 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 не следуют точно тем же шаблонам, которые описаны в Weaver et al. Или Clayton et al., Но они довольно близки в каждом случае. Имеет ли это смысл? Если да, можем ли мы провести какой-либо другой тест, чтобы убедительно показать, что это так? (отредактировано для ясности вопроса)

У меня нет доступа к облачной "приборной панели" для хостинга на этом компьютере, но коллега проверяет это на случай, если есть какая-то проблема сетевого уровня, которую мы могли бы решить таким образом. Что-нибудь, что мы должны проверить, в частности, там?

У нас есть номер ICP, который можно применить в случае необходимости для нашего домена.CN. (отредактировано для ясности)

Очевидно, что мы хотели бы иметь возможность обслуживать наши сайты в их доменах.COM, посетителям как внутри, так и за пределами Китая, через HTTPS, с нашего существующего сервера, используя наш сертификат подстановочного знака, как мы это делали ранее. Что нам делать?