ログを使用したJavaアプリケーションのTLSトラフィックの復号化

JavaアプリケーションのSSL / TLSで保護された統合のデバッグは、非常に重要なタスクになることがあります。接続が確立されない/切断され、アプリケーションログが不足している場合があります。たとえそうであっても）チャネルがPFSで暗号を使用すると失敗する場合があります。 FiddlerやBurpなどのプロキシサーバーは機能しない可能性があります。これは、アプリケーションがプロキシを通過する方法を知らないか、証明書が侵入したと信じることを拒否するためです...



最近、 ValdikSSの 出版物がHabrに 掲載されました。 これ は 、Wiresharkを使用して、FirefoxおよびChromeブラウザーからのトラフィックを、秘密サーバーキー、証明書のなりすまし、プロキシなしで復号化する方法に関するものです。 彼女はこの記事の著者に考えさせるように促しました-セッションキーファイルの代わりにJVMデバッグエントリを使用して、このアプローチをJavaアプリケーションに適用することは可能ですか？ それは判明しました-それは可能であり、そして今日、親愛なる一方、私はそれを行う方法を教えます。

レシピのアイデア

FirefoxおよびChromeブラウザーは、最近のバージョン以降、送信するトラフィック（および対称暗号化がSSL / TLS内で使用されるため受信したトラフィック）を暗号化するセッションキーの派生（受信）に十分な特別に定義されたファイルにデータを出力することを学びました。 厳密に言えば、これはブラウザー自体ではなく、構成内のNSSライブラリによって行われます。 記録されたファイルの形式を設定するのは彼女です。 Wiresharkはこの形式を読み取って使用し、対応するキーで暗号化されたSSLレコードを解読できます。 「ディッシュ」の考え方は、同じ目的でJavaアプリケーション用にそのようなファイルを個別に作成し、 javax.net.debug JVMオプションで標準出力に書き込まれるデバッグログをソースとして使用する方法を学ぶことです。

成分

必要なもの：

• 起動パラメーター（JVMオプション）を設定できるJavaアプリケーション 。
  
  明確にするために、接続を確立するときにアプリケーションがクライアントとして機能すると考えています。
  
  JDK（JRE）バージョン1.6または1.7が必要であり、他の（これまでのところ）テストされていません。
• Wiresharkバージョン1.6.0以降。
  
  
• テキストエディター （メモ帳++など）。
• 辛抱強さ、マインドフルネス、時間。

練り

起動オプション

ログは情報の主要なソースの1つであるため、最初に行うことは、受信確認を正しく構成することです。 完全に機能するオプションは、JVMオプションjavax.net.debug = ssl：handshake：dataです。 そのような値を持つ必要はないので、すぐに予約します。（おそらく）ユニバーサルjavax.net.debug = allなしで行うことができますが、そのような選択の結果を操作するのは難しい場合があります（ログの量が膨大になる可能性があります）。 私たちの選択は以下によって説明されます：

1. ssl -SSLのみに関するメッセージがログに書き込まれるようにします。
2. ハンドシェイク -メインステージ内の各メッセージを表示するには- ハンドシェイク 。
3. データ -一部の値を10進数システムから16進数（16進数）に手動で変換しないように、怠laな人向け。

このようなオプションがあると、デバッグ情報のログ（または標準出力）への出力が提供されますが、これについては後で説明します。

スニファー設定

上記のオプションを設定した後は、Wiresharkによるターゲットアプリケーションのトラフィックのみをスニッフィングできます。それ以外の場合、セッションキーがないためです。 さらに、キーは「一時的」であることに注意する必要があります。1つのSSLセッションにのみ適しています。つまり、1つの通信セッションのログは別のセッションのトラフィックの復号には適しません。 さて、非常に簡単に呼吸できるように、スニファーの開始時にデータを交換する予定のホストをすぐに指定することをお勧めします。 これにより、リスニングネットワークインターフェイスを通過する不要なパケットを「陸上」でも破棄できます。

録音と録音

必要なアプリケーション起動パラメータとスニファー設定を設定したら、アプリケーション自体を起動して、Wiresharkでパケットキャプチャを有効にできます。 次に、アプリケーションがサーバーとの（安全な）接続に到達しようとすると、「ポット」がいっぱいになり始めます。 Wiresharkの観点からは、次のようになります。









^{ご覧のように、Wiresharkは一部のSSLレコードを暗号化済みとして明示的に定義しています。 アプリケーションデータタイプのエントリは同じです。}



そして、アプリケーションの標準出力（ログ）の観点から-このようなもの：

... *** ClientHello, TLSv1 RandomCookie: GMT: 1427238714 bytes = { 246, 5, 6, 214, 168, 159, ... , 140, 141, 50, 196 } Session ID: {} Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, ..., SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA] Compression Methods: { 0 } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、はるかに多くのログが記録されます（デバッグ出力の形式はどこにも指定されておらず、Javaバージョンからバージョンに変更されます）が、現時点では少なくともそれだけを見る必要があります。

「校正」

SSL / TLS通信セッションからのデバッグレコードがあるため、NSS形式のセッションキーファイルを作成できます。 これを行うには、まず通信セッションで使用されたセッションキーの配布方法を決定する必要があります。 交換方法 （別名RSA）または生成方法 （別名DHまたはPFS、これらは異なるものです）。 彼らの本質と違いは、サリー・ヴァンデヴェンの素晴らしい作品にあります。 私たちにとっては、メソッド自体を知るだけで十分であり、少なくとも2つの方法で決定できます。

1. ログに表示されるか、スニファーによって定義された暗号の名前。 たとえば、この結論によると
   
   

    *** ServerHello, TLSv1 RandomCookie: GMT: 1037995915 bytes = { 168, 183, ... 204, 178 } Session ID: {141, 155, ... 214, 36} Cipher Suite: SSL_RSA_WITH_RC4_128_SHA ...
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   暗号の名前にDHが記載されていないことがわかりますが、明らかにRSAと呼ばれています。 ただし、このような明確さが常に存在するとは限らないため、プランBを使用できます。
   
   
2. WiresharkのトラフィックのインターセプトにServerKeyExchange SSLメッセージが存在することにより（サブセクション「削除と記録」のスクリーンショットを参照）-RSAではなくDHメソッドに存在します（この記事の範囲外である理由の説明）。 もちろん、このメッセージの存在は同じログで判断できます。

セッションキーの配布方法を定義したら、 NSSファイル形式の説明に移りましょう。これは、これら2つの方法だけで各ファイルの行を区別するように指示します。 それぞれについて詳しく見ていきましょう。

まず、コミュニケーションセッションで、ある種のRSAベースの暗号が使用されたとしましょう。 形式の説明によると、ファイルの対応する行はRSAテキストで始まり、16バイトのHEXエンコード暗号化PreMasterSecretキー、スペース、96バイトのHEXエンコード非暗号化PreMasterSecretキー（つまり、独自の）が続く必要があります。 このキーは、マスターキーMasterSecretを生成するための基盤であり、 ClientKeyExchangeメッセージでクライアントからサーバーに送信され、サーバーの暗号化された公開キーです。 これは、行の最初の部分（このキーの暗号化された表現）がWiresharkに表示されることを意味します。 目的のメッセージを見つけて確認します-はい、そうです：











ところで、アプリケーションログから同じ値を取得することもできます。ここでは、JVMオプション「 ：data 」が便利です。







見つかった値（16バイト）は、生成されたNSSファイルに挿入できます。 次に、行の2番目の要素（ PreMasterSecretキーの固有値）に対して同様の操作を行います。 明らかに、オープンな形でネットワークを介して送信されることはないため（実際、それが... Secretと呼ばれる理由です ）、ログからフィッシングアウトするだけで済みます。 幸いなことに、JVMからの明白な手がかりにより、これを行うことは特に難しくありません。







ここで、この値を作成するNSSファイルの行に追加し、このような結果になるように行を「櫛でくくる」必要があります（標準表記のコメントはまったく受け入れられます） 。

 # SSL/TLS secrets log file, generated by Toparvion RSA 75ff866e23beca1c 03012aede74befa88233253e3207bb1320935ab206696512674df5c6dee7dfaa2156932bc559631c8f3bb46ae38a71ff
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RSAが「まさにそのケース」である人（原則として、これらはJava 7より前のアプリケーションです）は、「試飲」セクションに進んでください。 PFS（多くの場合Java 7以降）に遭遇した人は、もっと読む必要があります...



RSA方式と同様に、PSFベースのレコードを復号化するための行は、スペースで区切られた3つの要素で構成される必要があります。

1. レコードのタイプ。 この場合、 CLIENT_RANDOMと等しくなければなりません。
2. 64バイトのHEXエンコードされたクライアント乱数Random ;
3. HEXエンコードされたMasterSecretマスターキーの96バイト。

2番目と3番目の要素のデータソースも前の方法と似ていますが、いくつかの微妙な点があります。 クライアントの乱数は、GMTミリ秒単位の現在時刻と実際の乱数値を連結したものです。 Wiresharkの場合、これははっきりと見えます。











ただし、ログにアクセスする場合、間違いを犯しやすいですが、次のヒントを使用できます。







JVMオプションjavax.net.debugの値には「：data」というエントリもあります。これにより、数値システムの手動変換が不要になります。 合計で、64バイトの乱数が必要です。その場合、すべてが完全になります（RSAの場合のように、先頭だけではありません）。 WiresharkがNSSファイル内の適切なエントリを検索するときに、インデックスの役割も果たします。

行の3番目の要素であるMasterSecretマスターシークレットキーも、アプリケーションログから抽出できます。







ログからメインキーを抽出した後、生成された行に「comb」を追加して、次のようなものを取得します。

 # SSL/TLS secrets log file, generated by Toparvion CLIENT_RANDOM 551435582740bdc1386b20b7fcb51428fe3042e06c8e6e94c910786f577a2ada 976dc1d54dd74d3c2e715109c8a4fb8e743efc084614abc0e12fdb78e472c30e3590ac5eb383424b2d8fa3de84c8b0f5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

WiresharkがNSSファイルの形式に非常に敏感であることに気付かないことは不可能です。したがって、文字列の各要素のバイト数が収束するかどうか、またどこかに余分なスペースがあるかどうかを慎重に確認することをお勧めします。 将来的に時間を節約できるかもしれません。

試飲

すべての「手動」ステップが完了したので、次はWiresharkにフロアを提供します。冒頭で述べた記事で説明したとおりに、作成したファイルを提示します。

1. SSL / TLSパケットでWiresharkのコンテキストメニューを開きます。
2. [プロトコル設定]-> [Secure Socket Layer設定]を選択します 。
3. 開いたウィンドウの（事前）マスターシークレットログfilnename列で、作成したNSSファイルへのパスを指定します。

[OK]をクリックして、傍受したトラフィックの変化を確認します。











復号化が成功した場合、以前に名前にEncryptedという単語が含まれていたパケットは、特定の名前を取得します。 これは、上の図に示されているFinishedコマンドで起こったこととまったく同じです。

さらに（これがおそらく最も楽しい瞬間です）、SSLまたはTLSプロトコルを使用して任意のパケットを選択し、コンテキストメニューで[ SSLストリームに従う ]をクリックすることができます。結果にはコメントは不要です。











ご覧のとおり、HTTP S呼び出しにもかかわらず、送信されたトラフィックを確認し、さらに分析するためにエクスポートできます。

それでもうまくいかない場合は...

この滑りやすい斜面では、多くの間違いを犯す可能性があります。 最も重要な情報ソースの1つはwiresharkのログです。ログファイルへのパスがすべて同じSSL設定ウィンドウのデバッグファイルのSSL列で指定されている場合、維持されます。

ログにフィルタリングが提供されておらず、Wiresharkが非常に詳細であることに注意することが重要です。したがって、ログを絶えずオンに保つと、まず、非常に急速に成長し、次に、Wireshark自体の抑制につながる可能性があります明らかに同期的に書き込まれます）。 この点で、NSSファイルを使用する直前にログファイルを指定し、分析の最後にそれを削除することをお勧めします（ただし、削除はしないでください）。

おわりに

この記事では、JavaアプリケーションのSSL / TLSトラフィックを解読してデバッグするための別のアプローチを検討しました。

この形式では、時間のかなりの投資とパフォーマーの特定の知識とスキルの存在を必要とするため、このアプローチは実際にはほとんど適用できません。 ただし、提示された説明により、このアプローチを形式化することができ、したがって、このアプローチを自動化（プログラム）して、人々のサービスに置くことができます。 このような作業は、著者によってすでに開始されています。 このアイデアがあなたにとっても面白いなら、私たちはあなたに慈悲を求めます！ Habréでそれについて話すことを忘れないでください。



読んでくれてありがとう！

更新する

親愛なる兄弟、記事で説明されているアプローチに興味があるが、手動で使用するには本当に遅すぎる人のために、 NSS Java MakerユーティリティがGitHubに投稿されました 。

実行の構文は簡単です。ソースJVMログファイルを指定するだけです。

 java -jar nssjavamaker.jar some/directory/java-ssl-debug.log
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在のディレクトリの出力により、NSSファイルsession-keys.nssが作成され、Wiresharkへのインポートの準備が整います。 このパスおよびその他のパラメーターを変更するには、 Readmeファイルを参照するか、パラメーターをまったく指定せずにユーティリティを実行します。

JARを実行する準備は、最新バージョンのページでダウンロードできます。

ユーティリティに関する提案/提案/コメント/コメントは、プロジェクトページのアプリケーションセクションおよびtoparvion@gmx.comで歓迎されています 。 頑張ってください！