通過するトラフィックを分析し、不要なトラフィックをブロックするファイアウォールがあります。これらのファイアウォールは、HTTPS や IMAP over SSL などの暗号化されたトラフィックに対してどの程度機能しますか?
例: ファイアウォールは、ポート 443 上の HTTPS トラフィックと、たとえば 443 経由のセキュリティ保護されたリモート デスクトップ トラフィックを区別できますか?
答え1
あなたの特定の例では、はい、可能です。
HTTPS はリモートとの TLS セッションを開始します。
TLSv1 Client Hello
セキュア RDP は、セッションの両端間で TLS で保護された接続をネゴシエートする RDP セッションを開始します。
X.224 Connection Request (0xe0)
セッション開始プロトコルが異なるため、ステートフル ファイアウォールは、HTTPS 接続の開始とその他の接続を区別できる必要があります。
一般的なケースでは、SSH トラフィックは HTTPS トラフィック内に隠されているため、ファイアウォールは SSH-over-HTTPS のようなものを検出できません。これを検出できる唯一の方法は、トラフィック パターンのヒューリスティック分析を行うことですが、それを実行するものを私は知りません。
IMAP には、セキュリティ保護の方法が 2 つあります。1 つは SSL 経由、もう 1 つは TLS 経由です。SSL 方式は、ポートが異なるだけで HTTPS 接続とまったく同じように見えますが、リモート ポートが同じであれば、できることはあまりありません。一方、TLS は会話の両端でネゴシエートされるため、セッションの開始が著しく異なり、簡単に検出されます。
覚えておくべき重要な点は、SSL はトラフィックが通過する TCP ラッパーを作成するということです。多くのプロトコルには、プロトコル自体の内部にネゴシエートされたセキュリティのメソッドが含まれており、ラッパーが使用するのとほぼ同じテクノロジを活用していますが、異なるセッション起動メソッドを使用しているため、区別が可能です。
答え2
一部のファイアウォール/プロキシ製品は、TLS接続で「承認された中間者攻撃」を実行できます。たとえば、Squidではこの機能を「SSL バンプ」。これを行うプロキシ サーバーは、TLS セッション内で送信されるプレーンテキスト データに完全にアクセスできます。ただし、このようなプロキシの背後にあるクライアントは、別のサーバー証明書 (実際のサーバーではなくプロキシ自体によって提供される) を取得するため、クライアントがそのような証明書を期待するように構成されていない限り (プロキシ CA 証明書を信頼できるルート証明書のリストに追加することによって)、TLS エラーまたは警告が発生します。