我希望有人能对我们截至 2019 年 2 月 3 日遇到的一个奇怪问题提供一些见解。
总结
- 中国 IIS 服务器上的 HTTPS 站点在初始 TLS 握手后返回 TCP RST 数据包。
- 这些网站向中国境外的客户端显示“连接重置”错误。 * 在中国境内可以通过 HTTPS 访问相同的网站。
- 使用 CloudFlare 代理连接，进行 DNS 和终止 SSL，可以解决此问题（只能从中国境外访问，从内部重置连接）。
- 同一服务器上的 .CN 域名可以使用 .COM 域名的通配符证书（接受无效证书后）在中国境外提供 HTTPS 服务。
背景
我们在阿里云上有一个 Windows Web 服务器（2008R2，IIS7.5）（类似于中国的 AWS，因此这个盒子是一个类似于 EC2 实例的 VM）。IIS 服务器在子域上托管了几个站点，我们为这些站点提供了通配符证书（例如https://app.example.com/和https://api.example.com，我们的通配符是 *.example.com ）。我们最近更新了该证书，方法是像往常一样安装一个完全链接的 PFX 文件。之后立即测试网站，一切正常，HTTPS 网站使用新证书提供服务。
此后不久（大约一天后），HTTPS 停止正常工作。客户端从外部中国的服务器在 TLS 握手后会收到错误，表明服务器已重置连接。相同的网站可以从服务器本身或任何其他位置正常加载之内我们测试的地点是中国。任何地点外部我们测试的中国地区也收到了同样的连接重置错误。
故障排除和测试
将通配符证书回滚到之前的版本（即使它很快就要过期）对问题没有任何影响。此外，更新的证书被中国客户视为有效，我们的 TLS 版本和密码在浏览器中显示为正常，等等。服务器上的 IIS 和 SChannel 没有报告任何问题——事实上，失败的连接甚至没有显示在 IIS 日志中。
我们仔细检查了 IIS 中的绑定（全部正确并使用更新的证书）、Windows 防火墙设置（未启用）、证书属性（完全链接并包括友好名称、正确的 SAN 等）。我们仔细检查了 TLS 设置的版本和密码，例如加密和注册表编辑，并且所有这些都是最新的，只要.NET4.0 可以支持。
这些设置都不会影响在中国境内连接服务器上 HTTPS 站点的现象，但在中国境外则无法连接。
研究
大多数附加测试都是我在纽约的一台计算机上进行的。
- 使用
telnet，我们能够连接到端口 443 上的服务器，从而排除基于 TCP 端口的简单网络防火墙规则。 - 使用时
traceroute，一旦请求进入中国，我们就会发现超时，但没有什么奇怪的——和往常一样，纯文本 HTTP 在任何地方都可以正常工作。 - 有了
nslookup，解析和名称服务器就位了 tcpdump -vv -i any host x.x.x.x and port 443给出了一个相当有趣的数据包捕获：它显示了 RST 数据包后TLS 握手/客户端 Hello，代替密码协商或任何有效载荷：通过 tcpdump 获取的 pcap 文件的 Wireshark 视图截图，其中已删除服务器 IP- （编辑以添加：）服务器上的数据包捕获显示出类似的模式：在 TLS 握手和客户端 Hello 之后立即收到 RST 数据包 - 表面上是来自客户端。
当我在域上启用 CloudFlare 来代理 DNS 并终止 SSL 时（即让中国的原始服务器通过端口 80 上的纯 HTTP 为 CloudFlare 提供服务，但对客户端使用 CloudFlare 的共享 SSL（也称为 CloudFlare 计划中的“灵活”SSL）），症状如下反转——只有中国以外的客户端才能看到 HTTPS 站点，而中国境内的客户端（包括本地服务器）会看到 HTTPS URL 上的连接重置。
我们有一个 .CN 域名，它与 example.com 子域名指向同一个 IIS 服务器。通过该域名访问时——例如https://example.cn/-- 连接按预期加载（您必须接受正在使用的 SSL 证书是 *.example.com 的通配符，然后才能加载带有警告的站点）。 RST 数据包也不会出现在数据包捕获中。 顺便说一下，.CN 域在 、nslookup等traceroute中给出的结果几乎相同。
结论问题
在我看来，这似乎是所谓的“防火墙”在作怪，即伪造并向此连接注入 RST 数据包。RST 数据包并不遵循Weaver 等人或者Clayton 等人，但它们在每种情况下都非常接近。这有意义吗？如果是，我们还可以做其他测试来最终证明情况确实如此吗？（已编辑，以便问题清晰）
我无法访问用于托管此机器的云“仪表板”，但一位同事正在检查它，以防我们可以通过这种方式解决某些网络级问题。我们应该特别检查那里有什么吗？
对于我们的 .CN 域名，我们确实有一个 ICP 编号，如有需要可以申请。（为清晰起见已编辑）
显然，我们希望能够像以前一样，使用我们的通配符证书，通过 HTTPS 从我们现有的服务器向中国境内外的访问者提供 .COM 域名的网站服务。我们应该怎么做？
答案1
是否在发送任何有效负载 TCP 数据包时，都会发回 RST？或者它是否必须是 TLS / Client Hello？即，如果您在建立 telnet 连接后输入某些内容，连接是否会关闭/重置？
很多年前，我曾在一家开发采用类似机制技术的公司工作。从个人角度来看，当我还是那里的一名员工时，我能够想出一个解决方法，在将此类数据包发送到客户端时对其进行过滤/延迟，从而有效地阻止这种 TCP 恶作剧，但我发现他们有一个小技巧，使我的解决方法完全多余。基本上，通过他们可以控制的自定义配置，他们可以重置 TCP 连接两个都通过向发起请求的客户端和目标服务器注入数据包，客户端和服务器双方都陷入了混乱，因此即使我采用了过滤方法，远程服务器也会受到干扰，流也会中断。如果这里的情况就是这样，我对是否有任何解决方法不抱太大希望。
我意识到这不是一个有用的答案，但我想在上面输入的内容不适合作为评论。只是想让你知道，很明显，在你的服务器托管位置的进出路线上有一个恶意数据包注入器。
您曾提到，它适用于托管在同一台服务器上的 .CN 网站，但不适用于 .COM 网站（对吗？）。您是否测试过，如果您完全停止 Web 服务器，使端口 443 上没有任何内容监听，然后从中国境外通过端口 443 远程登录到 Web 服务器，会发生什么情况？如果您看到看起来像是开放端口，那么就有一个内联设备充当中间人，这清楚地表明存在某种过滤/防火墙设备，即“防火长城”。