@kenn 理屈としては過去にキャプチャされたSSLセッションも含めてdecryptできる可能性があるから、かな
2014-04-11 12:10:46@d6rkaiz それはたまたまスキャンした64kbにたまたま通信中の電文が見えたってだけだよね。辞書攻撃よりだいぶ効率悪いと思う。
2014-04-11 12:16:25@miyagawa なるほど、いままでで一番説得力ある。でも実際にあてはまるのはこのときを待っていたストーカーに狙われてるごく一部のひとだけだよね。。
2014-04-11 12:23:33@d6rkaiz 64kb中に存在する確率と、怪しまれない程度の負荷で実行し続けるスループットを掛け算してみて。それの2年分のコストはどうか。
2014-04-11 12:26:58@kenn 1度に読み込めるのが64kbなだけなので、64kb中にのみという事はないかと。怪しまれない程度も何も攻撃とは認知されないのが今回の件だったように思うのですけど・・・ コストは分かりませんがw
2014-04-11 12:29:48@kenn @miyagawa app server (例えば mod_perl + Apache) が libssl をロードしているような運用の場合とか?大規模ではあまりなさそうですが。
2014-04-11 12:33:17@higepon たしかにSSL Terminationをアプリサーバがやってるような構成だとありえますね。でも、今後は逆にアプリサーバはプロセス空間もでかいので相対的に64kbブロックあたり認証情報が存在する確率はさらに下がりますよね。
2014-04-11 12:43:47.@kenn 関係あります。なぜなら、漏洩するメモリ空間は複数のユーザの接続を処理しており、そのメモリ空間にはログインフォームのPOSTリクエストが平文で含まれている可能性があるから
2014-04-11 12:45:18@kazuho それはわかりますが、メモリ空間のsniffで取得できるのはランダムなユーザで、64kb/5-10MBをスキャンして取り出すコストを考えると、辞書攻撃のほうが安価だと思います。つまり動機があまりないのでは?
2014-04-11 12:46:59@kenn 漏れたかどうかはサーバ側からは推測困難なので、可能性がゼロでない以上、変えてねと言ったほうがコストが低いという判断かね
2014-04-11 12:47:27#heartbleed 他のユーザの通信が平文で漏洩するってリスクが一番問題で、それに比べたら、詐称や過去の通信の解読とか経路上の要件が必要な他の問題は大したことない。特にネットワークの安全性が比較的高い日本では。
2014-04-11 12:48:41@kenn 逃げというか、漏れていないという証明をするのはほぼ不可能な以上、そうしたほうがhonestなのでは
2014-04-11 12:52:36@miyagawa いやー、パスワード変えてくれって言ってかえてくれる人はほとんどいないから、実効面はほとんど期待できないよね。だからどちらかというと逃げというか、「ほら言ったでしょ」ってdefensiveなアクションなんだと思う。それが悪いってわけではないけど。
2014-04-11 12:54:09@kenn 痕跡が残らないという要素が異なりますし、少なくとも僕が経済上の利益を目的とするなら、パスワードとセッションキーを第一のターゲットにします
2014-04-11 12:54:12@kenn @kazuho 辞書攻撃は、ちゃんとログを見てるサービス提供者にはバレバレですが、Heartbleedの方はログに残りませんから、Heartbleedを使うメリットはあると思います。あとターゲットOSのバージョンまで分かってれば、取り出すコストも低いのでは?
2014-04-11 12:55:37@kazuho 実際、一般的なサイトで64kbのページ内に認証情報が含まれる確率pはどのぐらいで、それを抽出する計算量Oはどのぐらいなのか興味ありますね。でもWANでメモリ転送だからコストはやっぱり高い。
2014-04-11 12:55:39