NGFW復号化作業に飽きた

最初の日付を完全に台無しにしたい場合は、復号化について女の子に相談してください。 はい、そしてその後の場合-それも価値がありません。



あなたとの出会いは初めてではないので、このテキストでは再び復号化について説明します。

はい、SSLについて再度説明します。 これがこのトピックの2番目で最後の資料であるという事実を、私自身とあなたに喜ばせることができます。 おそらく。



前回、長い間苦労してきたSSLを解読する必要がある理由を見つけました。

この記事では、証明書の置換で復号化がどのように機能するかを分析します。



これには何が必要ですか？



まず、SSLの仕組みを覚えておいてください。 要点を簡単に説明します。



TCPセッションを確立した後、クライアントとサーバーの間でSSLハンドシェイクが発生します。 その中で、両当事者はClient HelloメッセージとServer Helloメッセージを交換します。





vk.comとのSSL接続を確立するダンプ



クライアントHelloはサポートされている暗号化パラメーターを記述し、サーバーHelloは提案されたクライアントから選択されたパラメーターを含みます。 クライアントHelloとサーバーHelloの交換は、SSLセッションを確立するインジケーターとして使用できます。 これらのメッセージが表示されると、デバイス（この例ではvFTD）は構成済みの復号化ポリシーをスキャンして、将来セッションを復号化するかどうかを決定します。



設定されたポリシーがトラフィックを復号化するように指示している場合、デバイスは中間者（MITM）になり、送信されたデータを復号化します。 MITMが正常に起動すると、2つのSSLセッションが確立されます。



1つ目は、クライアントと復号化デバイス（vFTD）の間です。 2つ目は、復号化デバイスとサーバーの間です。 暗号化されたデータは、クライアントからvFTDに送信されます。

解読されました。 それらは、さまざまなポリシー（アクセス、IPS、ファイル、AMPなど）によってスキャンされます。 クライアントからの復号化されたデータが検証されると、再度暗号化されてサーバーに送信されます。 検証に合格しなかった場合、データは単にブロックされる（サーバー側に送信されない）か、セッションがリセットされます。 サーバーからの応答も同様に処理されます。



デバイスがSSLセッションでMITMになるには、ほとんど必要ありません。 SSLハンドシェイクの段階では、認証およびその他のアクションに加えて、共通のセッションキーが生成されます。 送信データが暗号化されるのは、その助けを借りてです。 これには対称アルゴリズムが使用されます。



インターネットでは、オープンな通信チャネルを介して共通のセッションキーを生成するための2つの最も一般的な方法があります：RSAとECDH（Diffie-Hellman）。 セッションキーを生成するプロセスを下の図に示します（資料「 WiresharkでのSSL / TLSトラフィック分析 」から引用 ）：





RSAを使用したセッションキーの生成



RSAの場合、クライアントはプリマスターシークレットを生成します。 サーバー証明書の公開鍵で暗号化して送信します。 予備の秘密は、サーバーにのみ知られている秘密鍵の助けを借りてのみ解読できます。



現在、双方には予備的な秘密があります。 これらはメインシークレットを形成し、次に共有セッションキーを形成します。





ECDHを使用したセッションキーの生成



ECDHの場合、SSL証明書のキーペアは暗号化にまったく使用されません。 クライアントとサーバーは、パブリックキーとプライベートキーのランダムキーのペアDiffie-Hellmanを形成します。 各側は、公開鍵を暗号化されていない形式で相手側に転送します。



さらに、Diffie-Hellmanアルゴリズムを使用して、クライアントとサーバーは自分の秘密鍵と他の人の公開から共通の予備秘密を計算します。 その後、各サイドは共通のマスターシークレットとセッションキーを形成します。



ECDHを使用する場合、送信されるDiffie-Hellman公開キーの整合性を維持する必要があります。 サーバーは、秘密証明書キーを使用して、自身のDiffie-Hellman公開キーに署名します。 クライアントは、サーバー証明書の公開キーを使用して、受信したDiffie-Hellman公開キーの信頼性を検証できます。



したがって、SSLセッション用にMITMを編成するには 、ほとんどの場合、サーバー証明書を独自のものに置き換えるだけで十分です。 置換が成功すると、クライアントと共有されているセッションキーを取得し、データを復号化できるようになります。



RSAの場合、MITMデバイスは、独自の秘密証明書キーを使用して予備シークレットを解読できます。 ECDHを使用する場合、デバイスはDiffie-Hellman公開キーに署名できるため、クライアント側で署名が有効と見なされます。



サーバー証明書を独自の証明書（秘密鍵がわかるもの）に置き換えるには、クライアント側で正しいサーバー認証を提供する独自の証明書が必要です。 簡単に言えば、証明書を置き換えるときに、クライアントのブラウザーが警告やロックを与えないことが必要です。 このため、ほとんどの場合、次のことが必要です。

1. 証明書のサブジェクトフィールドには、ブラウザのアドレスバーに入力された値と等しい値を持つ共通名パラメーターが含まれていました。
2. 証明書は、信頼できる証明機関によって署名されました。

もちろん、証明書がクライアント側で有効と見なされるためには、他の条件も満たす必要があります。それは、失効したり、失効したりしてはいけません。 ただし、これらのすべての条件は、独自の証明機関によって証明書に署名する段階で考慮されます。





証明書のピン留めを使用する場合、サービス証明書は厳密に定義された証明機関によって署名される必要があります。 そうでない場合、証明書が信頼できるセンターによって署名されていても、リソースへのアクセスはブロックされます。



したがって、証明書のピン留めがあるリソースの場合、証明書の置換を伴う復号化は機能しません。



したがって、MITMをSSLセッションで編成するには、デバイスはリモートサーバーの証明書と同じフィールドを持つ新しい証明書を生成する必要があります。 この場合、よく知られた秘密鍵があります。 新しい証明書は、信頼できる認証局を使用して署名する必要があります。



実際には、これは次のように実装されます。



会社には独自の証明機関が必要です。その証明機関のルート証明書は、会社のすべてのデバイスで信頼された状態に置かれます。 これは前提条件です。



テンプレート「下位認証局」（下位認証局、以下SubCA）に従って、認証局で新しい証明書が要求されます。 この証明書の特徴は、秘密鍵を使用して他の証明書に署名するために使用できることです（CAフラグは、拡張機能「基本証明書制限」で設定されます）。



SubCAは信頼されたルート証明書によって署名されているため、クライアントマシンはそれと署名されたすべての証明書を信頼します。 SubCAとそれに対応する秘密鍵がデバイスにインストールされ、SSLセッションでMITMになります。 これにより、クライアントがHTTPSサーバーとのSSLセッションを確立しようとするたびに、デバイスは次のことができるようになります。

1. サーバー証明書を傍受します。
2. 秘密鍵を作成します。
3. 置き換えられるものと同じフィールドを持つ新しい証明書を生成します。
4. SubCAを使用して、生成された証明書に署名します。

すべてが正しくセットアップされている場合、ユーザーのブラウザーはhttpsページを開くときに警告を表示しません。 ユーザーは、設定にアクセスした場合にのみ、証明書の置換の事実を判断できます。





Mozillaの証明書チェーン



最終証明書のフィールドを見ると、サブジェクトフィールドに正しい共通名の値が含まれていることがわかります。





共通名フィールド



実際の証明書と置き換えられた証明書を比較すると、実際には公開鍵とデジタル署名の値が異なることがわかります（この場合、シリアル番号などは無視します）。







最後に注意したいのは、 vFTDが同じキーペアを使用してスプーフィングされた証明書を生成することです。 これは実際には論理的です。すでに暗号化/復号化されたデバイスにリソースを費やして新しいキーペアを生成する理由です。 ya.ruページを開いて受信した証明書を表示すると、公開キーはvk.comの置き換えられた証明書と同じであることがわかります。





置き換えられた実際の証明書



これで、NGFWのSSL復号化メカニズムの説明を終わります。 すべての覚醒への挨拶、私たちはついにやった！ 痛かったですが、今ではSSLについてもう少し知っています。 価値があるかどうか-それはあなたの裁量です。



PS：そして、はい、同僚からお祝いの言葉を伝えます（そして参加します）。 新年には、バグ、松葉杖、タンバリンとのダンスが減ります！







PPS：このキッチンがFirePOWER-Welkamタックル用にどのように構成されているかに興味がある人向け。