2016-09-12 17 views
0

私はSMTPと共に使用される小さなTLSクライアントを開発しています。クライアントが暗号化された終了メッセージを送信するまで、ハンドシェイクはうまくいきます。したがって、クライアントHello、サーバーHello、証明書、サーバーのHello Done、クライアント鍵交換、およびChange Cipher Specが機能しています。私はTLS_RSA_WITH_AES_256_CBC_SHA256を使っています。TLS実装のエラーを確認してください

私の問題は、完成したメッセージを送信した後、サーバーから「Bad Record MAC」アラートが届くことです。しかし、私はどこでエラーを探し始めることができないのか分かりません。私は自分のすべての機能をダブルチェックし、RFCを2回読んだ。

  • マスターシークレット間違っている:私のopionionで

    次の点の一つは、「不正なレコードMAC」警告が発生する可能性があります。

  • client_write_MAC_keyが間違っています。
  • client_write_encryption_keyが間違っています。
  • P_hash関数が間違っています。
  • PRF関数が間違っています。
  • MAC機能が間違っています。
  • AES暗号化が正しく機能しません。
  • 終了メッセージのハッシュが間違っています。

私はこの問題を見つけるために何ができるか考えています。マスター・シークレット、MACと鍵の計算が正しいかどうかをチェックするツールはありますか?それとも、Wiresharkでコンテンツを復号化することは可能ですか?私はサーバーの秘密鍵を持っていないことに注意してください。

+0

私が知る限り、TLSセッションごとにサーバーとクライアントにカウンタがあります。それらはすべてのメッセージに追加され、メッセージが別の側で受信されると検証されます。リプレイ攻撃を防ぐために使用されます。これらのカウンタが適切に暗号化され、MACされていることを確認してください。 –

+0

"...私はサーバーの秘密鍵を持っていないので注意してください..." - 証明書、暗号、プロトコルなどを完全に制御できる独自のサーバーを設定するだけです。あなたがコントロールを持たないライブシステム。デバッグはずっと難しく、最悪の場合は酷使とみなされるかもしれません。 –

+0

@Steffen Ullrich私は、opensslを使ってテストサーバを設定することを考えます。しかし、誰もそのようなツールは、マスターの秘密と主要な計算を確認してください知っている? –

答えて

0

Steffen Ullrichが提案したOpenSSLを使ってローカルテストサーバーをセットアップしました。私はWiresharkによって提供された "デバッグ出力"の詳細な分析を行った。

パディングの問題を解決できました。しかし、私はまだBad Record MACアラートを取得しています。デバッグ出力と同様に、MACは間違っています(メッセージssl_decrypt_record: mac failed)。

接続およびデバッグ出力に関するいくつかの詳細情報:

  1. プレマスター秘密、秘密のマスターとすべてのキー(クライアントがMACキーを書き込み、サーバは、MACキー、クライアントの書き込みキーを書きますサーバー書き込みキー、クライアント書き込みIV、サーバー書き込みIV)が正しいかどうかを確認します。私はこれらのソフトウェアとデバッグ出力を比較しました。したがって、Encrypted Finished Messageまでのすべては正しいです。
  2. サーバ/ Wiresharkは、成功してEncrypted Finished Messageを復号化できます。
  3. server/Wiresharkがパディングを正しく検出しました。
  4. サーバー/ Wiresharkのは、このエラーが発生する可能性がありますIV「をスキップ」とだけ私の意見ではラインでFinished MessageとMAC Plaintext[64]:

に2つだけを示しています

  1. MACです計算された間違い。
  2. ハンドシェイクメッセージからのハッシュ(verify_data)が間違っています。

マイEncrypted Finished Message有する80バイトの全長と、以下の構造:

struct 
{ 
    // TLS record 
    ContentType type; 
    ProtocolVersion version; 
    uint16 length; 
    // TLS handshake and content (encrypted) 
    uint8 IV[16]; 
    struct 
    { 
     HandshakeType msg_type; 
     uint24 length; 
     uint8 verify_data[12]; 
    } content; 
    uint8 MAC[32]; 
    uint8 padding[15]; 
    uint8 paddingLength; 
} FinishedMessage; 

内容は、以下のような例を探し:

XXはランダムに生成されたIVを表し
 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
0000 16 03 03 00 50 XX XX XX XX XX XX XX XX XX XX XX 
0010 XX XX XX XX XX 14 00 00 0C YY YY YY YY YY YY YY 
0020 YY YY YY YY YY ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ 
0030 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ 
0040 ZZ ZZ ZZ ZZ ZZ 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 
0050 0F 0F 0F 0F 0F 

YYはverify_dataとZZはRFCで説明されているようなメッセージのMACです。

verify_dataには、SHA-256ハッシュの最初の12バイトが含まれています。ハッシュは、Client Hello,Server Hello,Certificate(サーバーから)、Server Hello DoneおよびClient Key Exchangeというメッセージによって計算されます。ハッシュの場合、レコードヘッダーなしの完全なメッセージ(最初の5バイト)が使用されます。

MACは、クライアントの書き込みMACキーとメッセージによって計算されます。シーケンス番号として、番号0が使用されます。 MACを計算するために使用されるfragmentには、msg_type,lengthおよびverify_data(上記の構造contentを参照)が含まれています。

私のMACに何が間違っているのか誰にもわかっていますか?

+0

私はこのエラーを解決しました。私の問題は、MACを計算するために完了メッセージ(IVを含む)を使用したことでした。だから完全なMACは間違っていた。私は上記の記事をもう一度読んで問題を発見し、私のソフトウェアと比較しました。私の混乱をおかけして申し訳ありません。 –

関連する問題