アカウント名:
パスワード:
ただし、MD5 Signatureはend-to-endで鍵が共有できていることを仮定しています。もしアプリケーションに依存せず、すべてのTCP接続でこれをやろうとしたら、IKEか何かを動かさないと使いものにならないでしょうね。
3-way handshakeの間にend-to-endで鍵を共有することができれば、TCPだけでheaderの認証がで
各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。
ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけよう
たて続けですみませんが、私が考えてた通り、一般に攻撃計算機は(portだけでなく)source addressをspoofしないとダメなようですよ。NISCC advisoryのsummaryには以下のように書かれています(もしかして、satsukiさんもspoofをsnoopと読み間違えてました?)。
The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all becaus
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
SYN flood (スコア:1)
Re:SYN flood (スコア:3, 参考になる)
最も影響をうけるBGPについてはTCP MD5 Signature Option(RFC2385)などの回避作も推奨されているようです.
3-way handshakeで鍵を共有しては? (スコア:2, 興味深い)
ただし、MD5 Signatureはend-to-endで鍵が共有できていることを仮定しています。もしアプリケーションに依存せず、すべてのTCP接続でこれをやろうとしたら、IKEか何かを動かさないと使いものにならないでしょうね。
3-way handshakeの間にend-to-endで鍵を共有することができれば、TCPだけでheaderの認証がで
Re:3-way handshakeで鍵を共有しては? (スコア:1)
Re:3-way handshakeで鍵を共有しては? (スコア:1)
各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。
ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけよう
Re:3-way handshakeで鍵を共有しては? (スコア:1)
知識共有はあまりにもコストが高く付き過ぎるので,中間者攻撃が可能なら可能でかまわないから,軽くて安いちょっとした防御ができたらいいなぁと.それだけです
そこまで心配する危険性でもないのかもしれませんが
ところで,この件ではsnoopはないという前提だと思います.アドレスも推
Re:3-way handshakeで鍵を共有しては? (スコア:1)
たて続けですみませんが、私が考えてた通り、一般に攻撃計算機は(portだけでなく)source addressをspoofしないとダメなようですよ。NISCC advisoryのsummaryには以下のように書かれています(もしかして、satsukiさんもspoofをsnoopと読み間違えてました?)。
Re:3-way handshakeで鍵を共有しては? (スコア:1)
ごめんなさい