アカウント名:
パスワード:
それこそ公開鍵暗号とか使ってIPアドレスとドメイン名から作るハッシュで認証すればなりすまし防止できるのでは?もしくは通信まるごと全部暗号化しちゃうとか(ICMPsになるのかな?)
プロトコル拡張が許されるならDNSSECというプロトコルがすでにありましてね
ハイパーリンクについては、公開鍵をアドレスにする仕組みにしとけば良かったのでは?と思う。これだと認証局なしでもある程度信用できるし。今時URL手入力なんざまずないでしょ。鍵が失効したら?知らん。
詐欺メールの書いてるリンク先が知らないドメインならクリックしないが、公開鍵ならクリックしてしまう。
.onionアドレスに対応する秘密鍵が失効した時ってどうするんでしたっけ
いちばんリーズナブルな対策はDNSクエリにTCPを使う方法だとおもいますこれだけでもほとんどの攻撃を無効化できるんじゃないでしょうか
UDPは発信ホストの情報が偽装し放題というところが大昔からずっと問題になっておるのでございます
RFC 1123にはゾーン転送を除いてまずUDPクエリーから投げなければならないと書かれていましたが、RFC 7766で緩和されて、理論上はいきなりTCPクエリーを投げてもいいことになりましたね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
プロトコル拡張して (スコア:0)
それこそ公開鍵暗号とか使ってIPアドレスとドメイン名から作るハッシュで認証すればなりすまし防止できるのでは?
もしくは通信まるごと全部暗号化しちゃうとか(ICMPsになるのかな?)
Re: (スコア:0)
プロトコル拡張が許されるならDNSSECというプロトコルがすでにありましてね
Re: (スコア:0)
ハイパーリンクについては、公開鍵をアドレスにする仕組みにしとけば良かったのでは?と思う。
これだと認証局なしでもある程度信用できるし。今時URL手入力なんざまずないでしょ。
鍵が失効したら?知らん。
Re: (スコア:0)
詐欺メールの書いてるリンク先が知らないドメインならクリックしないが、公開鍵ならクリックしてしまう。
Re: (スコア:0)
.onionアドレスに対応する秘密鍵が失効した時ってどうするんでしたっけ
Re: (スコア:0)
いちばんリーズナブルな対策はDNSクエリにTCPを使う方法だとおもいます
これだけでもほとんどの攻撃を無効化できるんじゃないでしょうか
UDPは発信ホストの情報が偽装し放題というところが
大昔からずっと問題になっておるのでございます
Re:プロトコル拡張して (スコア:2, 参考になる)
RFC 1123にはゾーン転送を除いてまずUDPクエリーから投げなければならないと書かれていましたが、RFC 7766で緩和されて、理論上はいきなりTCPクエリーを投げてもいいことになりましたね。