web-dev-qa-db-ja.com

TLSCiphertextの長さは、wiresharkで2 ^ 14 + 2048を超えてはいけません

小規模なネットワークで、最大20のクライアント（WifiおよびLan）があります。私はwiresharkで数秒のネットワークトラフィックをキャプチャし、さまざまなIPのエキスパート分析で多くのTLSCiphertext length MUST NOT exceed 2^14 + 2048エラーに遭遇しました。フィルターssl.record.length.invalidのスクリーンショットの下。宛先は常にローカルネットワークのクライアントIPです。ソースはさまざまな外部IPです。

enter image description here

RFC5246仕様 を読み、Heartbleedバグについて少し説明します。私たちのネットワーク内のすべてのルーター/ファイアウォールは、OpenSSLのバグに対してパッチが適用されています。さらに、時々、Wiresharkにinvalid heartbeat payload length errorが表示されることもあります。少しグーグル検索しましたが、このエラーの深刻度がわかりませんか？

以下に、Encrypted Alert, Ignored Unknown Recordメッセージの1つのより詳細な出力を示します。

Secure Sockets Layer
    TLSv1.2 Record Layer: Encrypted Alert
        Content Type: Alert (21)
        Version: Unknown (0x9620)
        Length: 59447
            [Expert Info (Error/Protocol): TLSCiphertext length MUST NOT exceed 2^14 + 2048]
                [TLSCiphertext length MUST NOT exceed 2^14 + 2048]
                [Severity level: Error]
                [Group: Protocol]
        Alert Message: Encrypted Alert
tlswiresharkheartbleed
1
DAG

これは、データの誤った解釈のように見えます。最も可能性が高かったのは、一部のTCPセグメントが順不同または失われ、WiresharkのTLSディセクタを混乱させることです。これは、再送信されたパケットの観察によってサポートされているようです。

また、一部のアプリケーションは、TLSレコードの開始をTCPセグメントの開始に合わせません。大量のデータがプッシュされている場合、完全なTLSレコードがいっぱいになります。

WiresharkがTLSレコードの開始を追跡できない場合、TCPセグメントの開始はTLSレコードの開始と一致します。前のケースが当てはまる場合、明らかにそれは機能しません。 。パケットを右クリックして、フォローストリーム-> TCPストリームを使用すると、おそらく「無視された不明なレコード」が表示されます。

すべてのパケットをキャプチャしたと仮定すると、TCP設定を有効にすることで、順序の乱れたTCPセグメント処理を修正できます。詳細は https： //wiki.wireshark.org/TLS#Preference_Settings

レコードサイズの超過に関するエキスパート情報については、送信されたレコードが大きすぎる場合の実装のバグをキャッチするために追加されました。あなたの場合それは偽物です。これらのコミットを参照してください：

3
Lekensteyn