TCPセグメント内のデータを保護するためにSSL / TLSが使用されている場合、TCP接続は攻撃者によって終了されますか？

Question

SSL/TLSがTCPの上に構築されていることを理解しています。つまり、TCP接続が確立された後、SSLハンドシェイクを開始できます。これが完了すると、すべての通信が暗号化および認証されます。接続を閉じるには、特定のアラートが使用されます。

SSL/TLSがTCP Segmentで使用されているデータを保護するために使用されている場合、攻撃者がTCP接続を終了できるかどうかを知りたい

私はこれを見つけました...

攻撃者がTCP接続（FINパケットの注入）を終了することによって接続を終了しようとした場合、通信相手は接続が不適切に終了したことを認識します。ただし、接続を終了することはできず、中断されるだけです。

しかし、知りたい方法通信相手は、接続が不適切に終了していることを知り、理由中断されるだけです。

さらに、TCP FINメッセージの挿入は、TCP RSTメッセージを挿入して接続を切断することと同じですか？

何かご意見は？

Nathan · Answer

これは完全に実行可能ですが、ターゲットtcpスタックに必要な正しいシーケンス番号を知る必要があることに注意してください。（サーバーへのすべての接続に対してそれを実行できるようにするには、サーバー自体またはそのサーバーへのゲートウェイ上にいる必要があります）。

注：ターゲットスタックから遠いほど、インジェクションでタイミングの問題が発生する可能性が高くなります。（これはパケットインジェクションであり、完全なミットではないと想定）

私はまた、そのようなインターセプトがターゲットスタックへの小さなセキュリティアップデートですぐに壊れることを経験から知っています:(

Rstとfinは比較的厳重に保護されますが、代わりにtcpウィンドウサイズをゼロに設定するだけでも一見の価値がありますか？（ただ考えて、私はこのもので遊んでからずっと[10年後！]になりました）

..しかし、通信相手が接続が不適切に終了したことを知る方法と、接続が中断されるだけの理由を知りたいのですが。

信頼できる接続を提供するためのtcpの重要なポイント。接続を強制終了すると、両側のスタックが認識します。接続が停止すると、ほとんどのシステムは通常はユーザーに通知することなく接続を再試行するため、中断されるだけです。

Mavaddat Javid · Answer

私の最初の応答はブロッククォートで（ "No…"）以下ですが、私の応答が間違っていると思うので、これを修正する必要があります。 TCP自体は、 replay および/または man-in-the-からの耐性を保証しませんミドルアタック。実際、この種の中断は一般的に TCPリセット攻撃として知られています。問題は、TCPにはメッセージの組み込み認証がなく、ベアTCPはパケットの真正性または真正性を保証できないことです。これを実現するには、信頼する必要があります HTTPSのトランスポート層セキュリティ（TLS）。アプリケーションが順不同パケットまたは不正なFINを検出できる場合、これは補助サービスであり、TCP標準では指定されていません。以下は私の最初の間違った評価です：

いいえ、TCPは両方の当事者が同意する必要がある相互に偶発的なプロトコルであるため、攻撃者はTCP接続を「FIN」パケットの挿入で正常に終了できません（つまり、片側が開始します）インテントの宣言を送信することで状態が変化すると、そのインテントの確認応答を受信するまで待機します。次に、トランザクションが実行されるように、トランザクションに状態変化を処理します。これは、Brent Baccalaの（編集者）* Connected：An Internet Encyclopedia、* Third Editionに記載されている回答に対応しています。
ケース2：TCPがネットワークからFINを受信する未承諾のFINがネットワークから到着した場合、受信側のTCPはACKを送信して、接続が閉じていることをユーザーに通知できます。ユーザーはCLOSEで応答し、残りのデータを送信した後、TCPは他のTCPにFINを送信できます。次に、TCPは、自身のFINが確認されるまで待機して、接続を削除します。 ACKが近づいていない場合は、ユーザーのタイムアウト後に接続が中止され、ユーザーに通知されます。
[Connected：Internet Encyclopedia TCP Connection Close] [5]したがって、パケットのシーケンス番号が正しい場合でも、予期しない「FIN」は、2つのコンピューター間の通信をTCPプロトコルの説明。忘れないでください：受信者は送信者に「FIN」を確認する応答を発行するだけでなく、実際には同じシーケンス番号を持つ2つの競合するパケットを受信します。受信者が「FIN」を予期していない限り、ドロップされ、両方の端末が合意した最後の状態で通信が続行または再開されます。