アカウント名:
パスワード:
多分問題になるとしたら, ネットワークにおける延停が無視できる状況, 例えば同一LAN上で通信をモニタリングできるような組織内部からのクラックに対してでしょうね. 多分に理論的な弱点と考えて良いでしょう.
実務的には数10ms以上のレスポンス分散が有るWAN経由の接続ではまず問題になることは無いでしょうから, 至急対応が必要というよりも他に何かupdateの要件が有った場合についでに対応するという程度で大丈夫だと思います.
ntpだと基本的に全て「当たり」なのでネットワークの延停を統計的に評価できますが, 今回の脆弱性だと「当たり」と「はずれ」が混在しているので統計的な評価が難しいと思います. つまりレスポンスが早かったのは「はずれ」だから早いのか, たまたまネットワークあるいはホストの負荷が低いから早いのかの区別がつかないってことです.
辞書攻撃みたいな場合に統計的なスクリーニング技法として補助的に使うことは出来るかもしれませんが, それとてレスポンスの分散が数10m秒以内に入っていないときついと思います.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
使える…の？ (スコア:2, 参考になる)
なるほど、今までフラグを見て gotoで処理をすっとばしてたところを、
フラグが真でも偽でも同じようなステップ数の処理を
行うようになった、と。
けど、実行するCPUが十分早ければ、
あるいは他の要素(ネットワークとか)が遅ければ、
この処理量の違いなんて簡単に埋もれてしまいそうなんですが、
どうなんでしょう？
Advisoryからリンクの張られているPassword Interception in a SSL/TLS Channel [lasecwww.epfl.ch]での実測では、
両者の時間の差は1000分の2秒程度しかないようなんですが...
Re:使える…の？ (スコア:2, 参考になる)
多分問題になるとしたら, ネットワークにおける延停が無視できる状況, 例えば同一LAN上で通信をモニタリングできるような組織内部からのクラックに対してでしょうね. 多分に理論的な弱点と考えて良いでしょう.
実務的には数10ms以上のレスポンス分散が有るWAN経由の接続ではまず問題になることは無いでしょうから, 至急対応が必要というよりも他に何かupdateの要件が有った場合についでに対応するという程度で大丈夫だと思います.
Re:使える…の？ (スコア:1)
あら／／／／／
対照性を仮定するだけのntpがミリ秒の精度で
同期できるのだから、レスポンス分散が100msec
程度であっても方法がないわけではないはずです。
オープンソースであるからこそ発見される脆弱性
ですよね？？ソース無しでこんな深い解析ができる
ものなのかなぁ／／／／
Re:使える…の？ (スコア:1)
ntpだと基本的に全て「当たり」なのでネットワークの延停を統計的に評価できますが, 今回の脆弱性だと「当たり」と「はずれ」が混在しているので統計的な評価が難しいと思います. つまりレスポンスが早かったのは「はずれ」だから早いのか, たまたまネットワークあるいはホストの負荷が低いから早いのかの区別がつかないってことです.
辞書攻撃みたいな場合に統計的なスクリーニング技法として補助的に使うことは出来るかもしれませんが, それとてレスポンスの分散が数10m秒以内に入っていないときついと思います.