NGファイアウォールは、TLSインターセプトなしでTLSトラフィックのアプリケーションの可視性と分類をどのように行い、これはどの程度信頼できるか
アプリケーションの可視性と制御はどのように機能しますか？アプリケーション識別（App ID）分類エンジンとアプリケーションシグネチャパターンマッチングエンジンは、レイヤー7で動作し、アプリケーションを識別するためにペイロードの実際のコンテンツを検査します。アプリIDは、ネットワーク上、およびアプリケーションが識別されるまでアプリケーション識別エンジンを通過するフロー内のすべてのパケットで、トラフィックのディープパケットインスペクション（DPI）を実行します。 IPアドレス、ホスト名、ポート範囲などのアプリケーションの結果は、将来の識別を促進するためにアプリケーションシステムキャッシュ（ASC）に保存されます。 - ジュニパー
AVCはステートフルディープパケットインスペクション（DPI）を使用して、1400を超えるアプリケーションを分類します。また、DPIを統計的分類、ソケットキャッシング、サービスディスカバリ、自動学習、DNS-ASなどの手法と組み合わせることができます。カスタムアプリケーションはネイティブアプリを検出できます。 - Cisco AVC
Merakiは、数年にわたる数千ものトラフィックパターンを調査して、アプリケーションレベルでネットワークトラフィックを認識するために使用できるトラフィック署名のデータベースを作成しました。 - メラキ （シスコ）
AppRFはローカルトラフィックのディープパケットインスペクション（DPI）を実行し、ネットワーク上の1500を超えるアプリケーションを検出します。 AppRFでは、特定のユーザーロール内でアプリケーションポリシーとアプリケーションカテゴリポリシーの両方を構成できます。 WebCCはクラウドベースのサービスを使用して、アクセスされるWebサイトのタイプとその安全性を動的に決定します Aruba （HP）
さまざまなベンダーのNGファイアウォールはアプリケーション制御を実行しますが、使用される手法は文書化されていません。すべてのベンダーがその仕組みについて簡単に説明しますが、詳細は記載していません。
ファイアウォールでSSLインターセプトが使用されておらず、すべてのトラフィックがHTTPS（TLS 1.2）[URLも非表示になっている]経由で転送されている場合、バックグラウンドで何が起こるか誰かが知っているかどうか尋ねています。
NGFWは、Google、Facebookなどのトラフィックの分離（ビデオ、ゲーム、チャットなど）をどのように識別して確認しますか？ 1つの方法は、特定のサービス専用の異なる範囲を使用する場合にIPを識別することですが、この手法では細分性が提供されません。最も興味深い部分は「トラフィックパターン」です。それらはどのように構築され、有名なアプリと「類似した」パターンを持つ有効なアプリケーションをブロックするためのフォールトポジティブリスクは何ですか？
彼らは証明書に基づいてそれを行います。サーバーとクライアントの間の証明書交換に関するデータをチェックし、それに基づいて、Dropbox、Outlook、またはその他のページにアクセスしようとしている場合にデータをチェックします。 CNまたはDropboxのSANはwww.dropbox.comであるため、アクセスしようとしています。
その他の場合、ワイルドカード* .google.comで署名されているため、YouTubeやブラウジングなどでのアプリケーション制御は問題があります。これにより、FwsはブラウジングとYouTubeを区別できなくなります。 gmailの場合は、gmail.google.comとして独自のCN/SANを持っています。 FWがYouTubeを検出するための並列メカニズムを実装していたかどうかは今のところわかりませんが、それほど前までは不可能でした。よろしく。
SRC、DST、SPRT、DPRTの暗号化は暗号化されていないためです。
OSIモデル（BGP、TCP、UDP、ARPプロトコルなど）で発生するカプセル化プロセスでは、キー交換メカニズムがデータグラムヘッダーを暗号化/復号化できず、DNS、WHOIS、またはその両方を介してサービスに簡単に解決できます。 IPスペースのプロバイダーまたは所有者。
DPI分類に使用される手法については、上記のベンダーに対する2つのオープンソースソリューションを検討するとよいでしょう。 snortとsurricatta