アカウント名:
パスワード:
この機能をコーディングし実装した人は。さらにいうなら、レビューして許可した人は。
今回の件、実装がと言うよりRFCそのものに問題があったのではと、本件を発見した技術者が報告しているのでは?
http://lepidum.co.jp/blog/2014-06-05/CCS-Injection/ [lepidum.co.jp] >正しい実装の容易さ・困難さ>>ChangeCipherSpecを正しく実装するのは実は容易なことです。上に挙げたフローの順番通りのメッセージだけを送信し受信すればよいだけです。ただし、少しだけ>落とし穴があって、ChangeCipherSpecは他のハンドシェークのメッセージとは異なるレコードを使います。RFCにはその理由が以下のように書いてあります。>> Note: To help avoi
あなた自身はわかって書いているのかもしれませんが、誤解を招く書き方だと思ったので念のため。
今回の件、実装がと言うよりRFCそのものに問題があったのではと、 本件を発見した技術者が報告しているのでは?
菊池氏のブログ記事に対する僕の理解が正しければ、あくまでも OpenSSL の実装に脆弱性があるのであって、 RFC に定められた仕様に脆弱性があるわけではありません。菊池氏は、今回の OpenSSL の脆弱性が生じた最大の原因は RFC に書かれた注釈 (note) の中の一文だろうと分析していますが、 RFC に定められた仕様自体に脆弱性があるとは書いていません。それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。
「実装というより RFC そのものに問題があった」という言葉の解釈によっては、間違ったことは何も言っていないとも受け取れますが、今回の状況は「仕様そのものに脆弱性があった」という (これまた割とよくある) 状況とは違うので、誤解を招く書き方だと感じました。
>>それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。
「OpenSSLもChangeCipherSpecをこのタイミングで送信します」
だから何?
OpenSSL は送信時には仕様を守っているけれど、受信時には仕様と異なるタイミングでも ChangeCipherSpec を受け付けるから問題になったわけ。わかる?
>>受信時には仕様と異なるタイミング
そんなこと、仕様書のどこに書いてありますか?
ChangeCipherSpec メッセージの正しいタイミングは RFC 5246 の 7.1 節 [ietf.org]に書いてある。また、不適切なメッセージは致命的エラーとして扱えと 7.2.2 節 [ietf.org]の unexpected_message の項目に書いてある。
相手に手間を掛けさせてイライラさせるだけのために自分でも意味のわかっていない質問をするのは、あなたは楽しいかもしれないけれど迷惑だからやめてほしい。
いや、だからね、RFC見て言ってるんだけどさ、7.1節だというなら7.1節でいいんだけど、どの文章を読んで「受信のタイミングが規定されてる」と主張してるわけなのさ?そのタイミング以外は不適切なメッセージとして扱えという主張だとお見受けする以上、MUSTで規定されてるってことだよね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
誰? (スコア:0)
この機能をコーディングし実装した人は。
さらにいうなら、レビューして許可した人は。
Re: (スコア:2, 興味深い)
今回の件、実装がと言うよりRFCそのものに問題があったのではと、
本件を発見した技術者が報告しているのでは?
http://lepidum.co.jp/blog/2014-06-05/CCS-Injection/ [lepidum.co.jp]
>正しい実装の容易さ・困難さ
>
>ChangeCipherSpecを正しく実装するのは実は容易なことです。上に挙げたフローの順番通りのメッセージだけを送信し受信すればよいだけです。ただし、少しだけ>落とし穴があって、ChangeCipherSpecは他のハンドシェークのメッセージとは異なるレコードを使います。RFCにはその理由が以下のように書いてあります。
>
> Note: To help avoi
Re:誰? (スコア:3)
あなた自身はわかって書いているのかもしれませんが、誤解を招く書き方だと思ったので念のため。
菊池氏のブログ記事に対する僕の理解が正しければ、あくまでも OpenSSL の実装に脆弱性があるのであって、 RFC に定められた仕様に脆弱性があるわけではありません。菊池氏は、今回の OpenSSL の脆弱性が生じた最大の原因は RFC に書かれた注釈 (note) の中の一文だろうと分析していますが、 RFC に定められた仕様自体に脆弱性があるとは書いていません。それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。
「実装というより RFC そのものに問題があった」という言葉の解釈によっては、間違ったことは何も言っていないとも受け取れますが、今回の状況は「仕様そのものに脆弱性があった」という (これまた割とよくある) 状況とは違うので、誤解を招く書き方だと感じました。
Re: (スコア:0)
>>それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。
「OpenSSLもChangeCipherSpecをこのタイミングで送信します」
Re:誰? (スコア:1)
だから何?
OpenSSL は送信時には仕様を守っているけれど、受信時には仕様と異なるタイミングでも ChangeCipherSpec を受け付けるから問題になったわけ。わかる?
Re: (スコア:0)
>>受信時には仕様と異なるタイミング
そんなこと、仕様書のどこに書いてありますか?
Re:誰? (スコア:2)
ChangeCipherSpec メッセージの正しいタイミングは RFC 5246 の 7.1 節 [ietf.org]に書いてある。また、不適切なメッセージは致命的エラーとして扱えと 7.2.2 節 [ietf.org]の unexpected_message の項目に書いてある。
相手に手間を掛けさせてイライラさせるだけのために自分でも意味のわかっていない質問をするのは、あなたは楽しいかもしれないけれど迷惑だからやめてほしい。
Re: (スコア:0)
いや、だからね、RFC見て言ってるんだけどさ、
7.1節だというなら7.1節でいいんだけど、どの文章を読んで「受信のタイミングが規定されてる」と主張してるわけなのさ?
そのタイミング以外は不適切なメッセージとして扱えという主張だとお見受けする以上、MUSTで規定されてるってことだよね?