パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

OpenSSLに新たな脆弱性が発見される」記事へのコメント

  • by Anonymous Coward

    この機能をコーディングし実装した人は。
    さらにいうなら、レビューして許可した人は。

    • Re:誰? (スコア:2, 興味深い)

      by Anonymous Coward on 2014年06月07日 2時25分 (#2616795)

      今回の件、実装がと言うよりRFCそのものに問題があったのではと、
      本件を発見した技術者が報告しているのでは?

      http://lepidum.co.jp/blog/2014-06-05/CCS-Injection/ [lepidum.co.jp]
      >正しい実装の容易さ・困難さ
      >
      >ChangeCipherSpecを正しく実装するのは実は容易なことです。上に挙げたフローの順番通りのメッセージだけを送信し受信すればよいだけです。ただし、少しだけ>落とし穴があって、ChangeCipherSpecは他のハンドシェークのメッセージとは異なるレコードを使います。RFCにはその理由が以下のように書いてあります。
      >
      > Note: To help avoid pipeline stalls, ChangeCipherSpec is
      > an independent SSL Protocol content type, and is not
      > actually an SSL handshake message.
      >
      > draft-ietf-tls-ssl-version3-00 §5.5より引用
      >
      >個人的にはこの一文が今回の脆弱性の最大の原因ではないかと思っているのですが、これによると、ChangeCipherSpecが独立したレコードになっているのはパイプラインストールを防ぐためだそうです。

      本件、HeartBleedの件の後ということで、敏感になっているので、
      大げさに取り上げられたり、取り上げた記事が煽り気味だったりと、ちょっとした騒ぎになってますけど
      そもそも、発生する条件が限定的で、そこまで騒ぐような問題でも無いように感じるのは
      セキュリティ意識が低いでしょうか?

      親コメント
      • by fcp (32783) on 2014年06月08日 13時36分 (#2617344) ホームページ 日記

        あなた自身はわかって書いているのかもしれませんが、誤解を招く書き方だと思ったので念のため。

        今回の件、実装がと言うよりRFCそのものに問題があったのではと、
        本件を発見した技術者が報告しているのでは?

        菊池氏のブログ記事に対する僕の理解が正しければ、あくまでも OpenSSL の実装に脆弱性があるのであって、 RFC に定められた仕様に脆弱性があるわけではありません。菊池氏は、今回の OpenSSL の脆弱性が生じた最大の原因は RFC に書かれた注釈 (note) の中の一文だろうと分析していますが、 RFC に定められた仕様自体に脆弱性があるとは書いていません。それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。

        「実装というより RFC そのものに問題があった」という言葉の解釈によっては、間違ったことは何も言っていないとも受け取れますが、今回の状況は「仕様そのものに脆弱性があった」という (これまた割とよくある) 状況とは違うので、誤解を招く書き方だと感じました。

        親コメント
        • by Anonymous Coward

          >>それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。

          「OpenSSLもChangeCipherSpecをこのタイミングで送信します」

          • by fcp (32783) on 2014年06月08日 19時53分 (#2617497) ホームページ 日記

            だから何?

            OpenSSL は送信時には仕様を守っているけれど、受信時には仕様と異なるタイミングでも ChangeCipherSpec を受け付けるから問題になったわけ。わかる?

            親コメント
            • by Anonymous Coward

              >>受信時には仕様と異なるタイミング

              そんなこと、仕様書のどこに書いてありますか?

              • by fcp (32783) on 2014年06月09日 12時18分 (#2617761) ホームページ 日記

                ChangeCipherSpec メッセージの正しいタイミングは RFC 5246 の 7.1 節 [ietf.org]に書いてある。また、不適切なメッセージは致命的エラーとして扱えと 7.2.2 節 [ietf.org]の unexpected_message の項目に書いてある。

                相手に手間を掛けさせてイライラさせるだけのために自分でも意味のわかっていない質問をするのは、あなたは楽しいかもしれないけれど迷惑だからやめてほしい。

                親コメント
              • by Anonymous Coward

                いや、だからね、RFC見て言ってるんだけどさ、
                7.1節だというなら7.1節でいいんだけど、どの文章を読んで「受信のタイミングが規定されてる」と主張してるわけなのさ?
                そのタイミング以外は不適切なメッセージとして扱えという主張だとお見受けする以上、MUSTで規定されてるってことだよね?

      • by fukapon (4131) on 2014年06月07日 4時52分 (#2616816)

        条件は限定的でも、MITM attackを許すってのがまずいなと思っています。ご存じの通り、MITM attackを許すことは、SSL/TLSの信頼性をまるっと否定されるってことです。
        これがDoSとかだったら、たとえ多少攻略しやすいものでも問題の度合いは低くなるかなと。

        親コメント
      • by Anonymous Coward

        致命的な物も含めてバグが短期間に複数見つかれば「他にもまだ残っているんじゃないのか?これは使って大丈夫なのか?」と疑うのは不思議ではありません。

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...