アカウント名:
パスワード:
タレコミはITmediaの記事を引用してますが、この記事は変な文章ですね。
もう一つのリンク元TechCrunchの記事は分かりやすいです。こちらによれば、HTTPSの公開鍵暗号をユーザーセッション毎に生成するので、仮にどこかの誰かがTwitterのインターネットトラフィックを丸々保存していて、あるユーザーから現セッションの秘密鍵が漏れたとしても、他のユーザーのセッションは解読できないし、そのユーザーの過去・将来のセッションも解読できないよ。という技術のようです。
ITmediaはおそらく、どこかの「過去分のデータの中身(contents)に触れる(access)ことができない」と
techCrunchの記事も謎が多いですね。HTTPSで配る公開鍵が毎回違うなら、オレオレ証明書みたいなのをセッションの度に受け入れないといけないような気がします。
HTTPSの仕組みは崩さずに、ということになると、通常の公開鍵暗号にもう一枚 公開鍵暗号フェーズを組み込むことになりますが、この場合、プロトコルレベルでやろうとすると、クライアント側の対応が必要なように思えます。
となると、この一枚組み込んだ公開鍵暗号フェーズを、クライアントのjavascriptでこなすことになりますが、まぁ無くはないんでしょうけど、強引ですよね。というか こういう技術なのかな。
そんなに頻繁に行わない Webサービス間通信の場合は、毎回 公開鍵-秘密鍵を作って、ワンタイムパスワードのやりとりを行うってことは普通にやりますのでその部分に驚きはありませんが、HTTPSに一枚膜を張って 150msの遅延ぐらいはいいでしょ、という強引さは なかなかマネができない気がします。
とりあえずPerfect Forward Secrecyのことを調べてからコメントしようぜ
他のコメントにもあるが日進月歩のＩＴ業界では古い技術（Ｇｏｏｇｌｅは２年前導入らしい）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
ITmediaの記事はなんか変だ (スコア:2)
タレコミはITmediaの記事を引用してますが、この記事は変な文章ですね。
もう一つのリンク元TechCrunchの記事は分かりやすいです。こちらによれば、
HTTPSの公開鍵暗号をユーザーセッション毎に生成するので、
仮にどこかの誰かがTwitterのインターネットトラフィックを丸々保存していて、あるユーザーから現セッションの秘密鍵が漏れたとしても、
他のユーザーのセッションは解読できないし、そのユーザーの過去・将来のセッションも解読できないよ。
という技術のようです。
ITmediaはおそらく、どこかの「過去分のデータの中身(contents)に触れる(access)ことができない」と
Re:ITmediaの記事はなんか変だ (スコア:0)
techCrunchの記事も謎が多いですね。
HTTPSで配る公開鍵が毎回違うなら、オレオレ証明書みたいなのを
セッションの度に受け入れないといけないような気がします。
HTTPSの仕組みは崩さずに、ということになると、通常の公開鍵暗号に
もう一枚 公開鍵暗号フェーズを組み込むことになりますが、この場合、
プロトコルレベルでやろうとすると、クライアント側の対応が必要なように思えます。
となると、この一枚組み込んだ公開鍵暗号フェーズを、クライアントのjavascriptで
こなすことになりますが、まぁ無くはないんでしょうけど、強引ですよね。
というか こういう技術なのかな。
そんなに頻繁に行わない Webサービス間通信の場合は、毎回 公開鍵-秘密鍵を作って、
ワンタイムパスワードのやりとりを行うってことは普通にやりますのでその部分に
驚きはありませんが、
HTTPSに一枚膜を張って 150msの遅延ぐらいはいいでしょ、という強引さは なかなか
マネができない気がします。
Re: (スコア:0)
とりあえずPerfect Forward Secrecyのことを調べてからコメントしようぜ
他のコメントにもあるが日進月歩のＩＴ業界では古い技術（Ｇｏｏｇｌｅは２年前導入らしい）