接続が存在することをTLSネゴシエーションエラーでエラーしていますか？

Question

私たちは、クライアントがQA環境の1つにアクセスできるようにしようとしています。

このページを表示することができない高度な設定でTLS 1.0、TLS 1.1、およびTLS 1.2の 電源を入れ、再びhttps://oursite.comに接続してみてください。彼らは、IEで、次のエラーが表示されます。このエラーが続く場合は、このサイトでサポートされていないプロトコルまたは暗号スイート（RC4など）を使用している可能性があります。詳細についてはリンクを参照してください。サイト管理者に連絡してください。

私はこの問題を解決するためにstackoverflowユーザーに求めていません。私たちは、このエラーが表示されているので

、はこれが私たちのファイアウォールは、それらを経由させて頂いており、すなわち、その接続性が存在することを証明ん：

私は、次の非常に具体的な質問をするのですか？ファイアウォールでブロックされた場合、タイムアウトまたはおそらく403または500エラーが発生すると思います。 TLSプロトコルがWebサーバーでサポートされているかどうかを知ることができるようになって以来、私はOSIレベル1〜4でTLSプロトコルと通信できる必要があると推測しています。私は正しいですか？ （ファイアウォールを実行するネットワークチームに従事するか、TLS設定を設定するアプリケーションサポートチームに従事するかを知る必要がある）。

SSLはIIS Webサーバーで終了することに注意してください（SSLオフロードはありません）。

残念ながら、ポート80はブロックされており、443でしかテストできません。それ以外の場合は、httpアクセスを使用して問題を特定することをお勧めします。

Answer 1

...ファイアウォールでブロックされた場合、タイムアウトまたはおそらく403または500エラーが発生します。

403または500のエラーを返信するには、HTTP応答（ステータスコード、つまり403,600など）が送信されるだけなので、ファイアウォールはクライアントとのSSLハンドシェイクを正常に完了している必要があります暗号化された接続の内部。すでにSSLハンドシェイクの内部に403または500を返す方法はありません。

ファイアウォールを使用した一般的な動作は、タイムアウト（ファイアウォールのドロップパケット）または接続のリセットまたは終了（ファイアウォールのリセットまたは接続の切断）の可能性があります。単純なパケットフィルタファイアウォールでは、通常TCP接続をブロックして接続が拒否されます。しかし、DPIを使用するファイアウォールは、実際にTCP接続を確立させ、このペイロードの内容に基づいて実際のデータを取得した後にのみブロックします（つまりアプリケーション検出）。

最後のケースでは、表示されるエラーが発生する可能性があります。しかし、サーバーが単に接続を閉じたりリセットしたりするサーバー側に問題がある場合、まったく同じ動作が見られます。一部のTLSスタックは、共有プロトコルのバージョンまたは暗号を見つけることができないときに、（TLSアラートを返す代わりに）そのような動作を示します。このエラーメッセージから、ファイアウォールが接続をブロックしていると判断することも、サーバーがエラーを引き起こしていると判断することもできません。