來自中國 Web 伺服器的 HTTPS 被 RST TCP 數據包（防火牆？）
我希望有人能對我們在 2019 年 2 月 3 日遇到的一個奇怪問題提供一些見解。
TL;博士
- 中國 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 版本和密碼在瀏覽器中顯示為 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給出了一個相當有趣的數據包擷取：它顯示了TLS 握手/客戶端 Hello後出現的 RST 數據包，代替密碼協商或任何有效負載：通過 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 等人中描述的完全相同的模式，但它們在每種情況下都非常接近。這有意義嗎？如果是這樣，我們是否可以做任何其他測試來最終證明是這種情況？（為問題清晰而編輯）
我無權訪問用於託管這台機器的雲“儀表板”，但一位同事正在對此進行檢查，以防出現一些我們可以通過這種方式解決的網路級問題。有什麼我們應該特別檢查的地方嗎？
我們確實有一個 ICP 號碼，如果需要，可以為我們的 .CN 域名申請。（為清楚起見進行了編輯）
顯然，我們希望能夠像以前一樣，使用我們的萬用字元證書，通過 HTTPS，從我們現有的伺服器，為他們的 .COM 域為中國境內外的訪問者提供我們的網站。我們應該做什麼？
當發送任何有效載荷 TCP 數據包時，是否會發回 RST？或者它是否必須是 TLS / Client Hello？IE。如果您在建立 telnet 連接後鍵入某些內容，連接會關閉/重置嗎？
許多年前，我曾在一家開發採用類似機制的技術的公司工作。從個人的角度來看，當我仍然是那裡的一名員工時，我能夠想出一個解決方法，當它們被發送到客戶端時過濾/延遲這些數據包，有效地破壞這種 TCP 混蛋，但我觀察到他們有他們袖手旁觀的一個小把戲，這使我在方法論方面的工作完全多餘。基本上，通過他們可以控制的自定義配置，他們可以在兩者上重置 TCP 連接雙方，客戶端和伺服器，通過向發起請求的客戶端和目標伺服器注入數據包，所以即使我想出了過濾，遠端伺服器也被弄亂了，流中斷了。如果這就是這裡發生的事情，我對存在任何解決它的方法不抱太大希望。
我意識到這不是一個有用的答案，但我想在上面輸入的內容不適合作為評論。只是想讓您知道，在進出您的伺服器託管位置的路由上顯然存在惡意數據包注入器。
您提到它適用於 .CN 網站，但不適用於託管在同一伺服器上的 .COM 網站（正確嗎？）。您是否測試過如果您完全停止網路伺服器以使 443 埠沒有監聽，然後從中國境外通過 443 埠遠端登錄會發生什麼？如果你得到一個看起來像開放埠的東西，那麼有一個內聯設備充當中間人，它清楚地證明了某種過濾/防火牆設備的存在，即“防火牆”。