中国のWebサーバーからのHTTPSがRST TCP=パケット（偉大なファイアウォール？）
2019年2月3日の時点で発生している奇妙な問題について、誰かが洞察を提供してくれることを願っています。
TL; DR
- IISサーバー上のHTTPSサイトは、最初のTLSハンドシェイク後にTCP RSTパケットを返しています。
- これらのサイトは、中国以外のクライアントに「接続リセット」エラーを表示しています。 *同じサイトに中国国内からHTTPS経由でアクセスできます。
- DNSとSSLを終了するためにCloudFlareとの接続をプロキシすると、この問題が逆転します（中国国外からのみアクセス可能、接続は内部からリセットされます）。
- 同じサーバー上の.CNドメインは、（無効な証明書を受け入れた後）.COMドメインのワイルドカード証明書を使用して、中国国外のHTTPSに対応できます。
バックグラウンド
AliYun CloudにWindows Webサーバー（2008R2、IIS7.5）があります（中国のAWSのように、このボックスはVM）です。）IISサーバーは、ワイルドカード証明書があるサブドメインでいくつかのサイトをホストします（例 https://app.example.com/ および https://api.example.com で、ワイルドカードは* .example.comです。通常どおりに完全にチェーン化されたPFXファイルをインストールすることにより、この証明書を最近更新しました。直後にサイトをテストすると、すべて正常で、HTTPSサイトが提供されました新しい証明書で。
この直後（1日後など）、HTTPSは期待どおりに機能しなくなりました。中国のoutsideから接続するクライアントは、サーバーが接続をリセットしたことを示すTLSハンドシェイク後にエラーを受け取ります。同じサイトは、サーバー自体またはその他の場所から完全に正常に読み込まれますwithinテストした中国。テストした中国のどの場所outsideでも、同じ接続リセットエラーが発生しました。
トラブルシューティングとテスト
ワイルドカード証明書を以前の証明書にロールバックしても（すぐに有効期限が切れますが）、問題にはまったく影響がありませんでした。さらに、更新された証明書は中国のクライアントによって有効であると認識され、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パケットが表示されますafter TLSハンドシェイク/クライアントHello： pcapのWiresharkビューからのスクリーンショット）サーバーIPが削除されたtcpdumpを通じて取得されたファイル- （追加するように編集:)サーバーでのパケットキャプチャは同様のパターンを示します：TLSハンドシェイクとClient Helloの直後に受信されたRSTパケット-表面上はクライアントから-.
ドメインでCloudFlareを有効にしてDNSをプロキシし、SSLを終了したとき（つまり、中国のオリジンサーバーがポート80でプレーンHTTPを介してCloudFlareにサービスを提供するが、CloudFlareの共有SSLをクライアントに使用する場合（CloudFlareの計画では「フレキシブル」SSL） ）、症状はreversed-中国の外部のクライアントのみがHTTPSサイトを参照し、中国内のクライアント（ローカルサーバーを含む）はHTTPS URLで接続リセットを確認します。
Example.comサブドメインと同じIISサーバーを指す.CNドメインがあります。そのドメイン経由でアクセスする場合 https://example.cn/ など=-接続は期待どおりにロードされます（使用中のSSL証明書が* .example.comのワイルドカードであることを受け入れる必要があります。その後、警告を表示してサイトをロードできます）。RSTパケットもパケットに表示されません記録。レコードの場合、.CNドメインはnslookup、tracerouteなどでほぼ同じ結果を示します。
結論の質問
私には、いわゆる「グレートファイアウォール」が機能しているようです。つまり、この接続にRSTパケットを偽造して注入しています。 RSTパケットは Weaver et al または Clayton et al で説明されているものとまったく同じパターンには従いませんが、どちらの場合もかなり接近しています。これは理にかなっていますか？もしそうなら、これが事実であることを最終的に示すために私たちができる他のテストはありますか？ （質問を明確にするために編集）
このマシンをホスティングするためのクラウド「ダッシュボード」にアクセスできませんが、ネットワークレベルの問題が発生した場合に備えて、同僚が確認しています。特にチェックすべきことはありますか？
.CNドメインには、必要に応じて適用できるICP番号があります。 （明確にするために編集）
以前と同じように、ワイルドカード証明書を使用して、既存のサーバーからHTTPS経由で、中国内外の訪問者に.COMドメインでサイトを提供できるようにしたいと思います。私たちは何をすべき？
ペイロードTCPパケットが送信されると、RSTが返送されますか？それとも具体的にはTLS/Client Helloである必要がありますか？たとえば、telnetの後に何かを入力した場合接続が確立された後、接続はクローズ/リセットされますか？
何年も前に、私は同様のメカニズムを使用する技術を開発していた会社で働いていました。私的個人の観点から、私はまだそこにいる従業員でしたが、クライアントに送信されたときにそのようなパケットをフィルター処理/遅延させて、そのようなTCP = douchebaggery、しかし私は彼らが袖を少しトリックしていて、私の方法論の周りの作業を完全に冗長にすることに気づきました。基本的に、彼らが制御していたカスタム構成を介して、TCP接続bothサイド、クライアント、サーバー、要求元のクライアントと宛先サーバーの両方にパケットを注入することで、私が思いついたフィルタリングを使用しても、リモートサーバーも混乱し、ストリームが中断されました。これがここで起こっていることです。私はそのための回避策が存在することを望んでいません。
これは有用な回答ではないことに気づきましたが、上記で入力したい内容がコメントとしてふさわしくありませんでした。サーバーがホストされている場所の内外のルートに悪意のあるパケットインジェクターが配置されているように見えることをお知らせしたかっただけです。
同じサーバーでホストされている.CNのWebサイトでは機能するが、.COMのWebサイトでは機能しないとおっしゃっていました（正しいですか）。 Webサーバーを完全に停止して、ポート443で何もリッスンしていない場合に何が起こるかをテストしました。その後、中国国外からポート443でtelnetを実行しますか？開いているポートのように見える場合は、中間者として機能するインラインデバイスがあり、ある種のフィルタリング/ファイアウォールアプライアンス、つまり「グレートファイアウォール」の存在を明確に示しています。