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が独立したレコードになっているのはパイプラインストールを防ぐためだそうです。
意外に実害は少ない? (スコア:5, 参考になる)
まずは、piyokango さんのまとめ。
OpenSSLの脆弱性CCS Injection(CVE-2014-0224)の攻撃が行われる恐れがあるパターンをマトリックス化してみた。 [hatena.ne.jp]
これを読むと、通信の盗聴・改ざんが可能な MITM 攻撃が成立するのは、サーバ側は 1.0.1 で、かつ、クライアント側が脆弱性を持つ OpenSSL を利用している場合。
で、クライアント側で、OpenSSL を利用しているブラウザ、となると、一般的に利用されているものとしては、Android 用の Chrome ぐらいで、主だったブラウザでは、そもそも、OpenSSL を利用していない。
OpenSSL、新たなパッチが公開--重大な脆弱性がまたも発見される - ZDNet [zdnet.com]
クライアント認証の問題とか、HTTPS 以外にも SSL/TLS は使われている、とか、影響を受けるものは確かにあるんだけど、こと、一般的な Web アクセスにおいては、仮に、サーバ側が脆弱な状態であっても、「盗聴」「改ざん」といった、センセーショナルな問題はほとんど起きない気がするなぁ。
Re:意外に実害は少ない? (スコア:2, 参考になる)
Androidアプリ(Webiew以外)がヤバいらしい
http://qiita.com/emittam/items/521aad997522a5f49eeb [qiita.com]
Re:意外に実害は少ない? (スコア:1)
うん、でもこのバグで結構連絡が来るんだ
下手したら前よりも・・・・
IEの時も昔から何度かあったバグなのにやたら騒いでたし、日本人は危ないぞ!って言われると弱いんでしょうか
バスに乗り遅れるぞ!と似た感じなのかな
Re:意外に実害は少ない? (スコア:1)
個人的に心配しているのはgitとか、VPN製品かなー。
Re:意外に実害は少ない? (スコア:1)
Sylpheedがさっそくパッチ出してました。 http://sylpheed.sraoss.jp/ja/news.html [sraoss.jp]
Re:意外に実害は少ない? (スコア:1)
そもそもAccess Vectorが限定的なので、この脆弱性だけで実害に繋げるのは厳しいかと思います。
合わせ技一本となると、日頃からセキュリティに気を配っているサーバなら害を受けないだろうし、逆ならばやられ放題みたいな感じですかね。
Re: (スコア:0)
しかしパッケージ管理ツールとかhttpsでバイナリ落としてるツールがOpenSSLだったりしないかな。
ま、MITMで狙われるような情報ってそうないと思うけども。
Re:意外に実害は少ない? (スコア:1)
パッケージ管理では、中間者攻撃されても電子署名のチェックで弾かれるはず。
Re: (スコア:0)
SSH界隈ではその条件にあうことがものすごく多いような気がするよ。
誰? (スコア:0)
この機能をコーディングし実装した人は。
さらにいうなら、レビューして許可した人は。
Re:誰? (スコア:4, すばらしい洞察)
問題を矮小化し悪い者探しをしてその人たちを槍玉に挙げて満足していたんじゃ
何の問題解決にもならず同じ失敗が繰り返されるだけです。
問題が起きた根本の原因を突き止めてそれを改善するのが
プログラム開発のみならずビジネスの基本かと思います。
Re:誰? (スコア:1)
そうだね。何より重要なのは、オープンソースを使うなら自己責任で使えって事だね。
Re: (スコア:0)
ここはソフト屋さんが多いからマイナスモデされてるけど、本質は突いている。
オープンソースに限らずすべてにおいて自己責任ってね。
Re:誰? (スコア:1)
能力の高い人だけで構成された夢のようなプロジェクト・現場などありえません。
人の問題に終始して能力の低い人を切ることで解決した気になっていると
別の能力の低い人がまた同じ間違いをするだけという極々当たり前のお話です。
Re: (スコア:0)
一人ひとりが完璧であることはありえないからこそプロジェクトとしてのレビュー等が必要になるんですよ?
Re: (スコア:0, すばらしい洞察)
おしい、最後の三行が余計だよ。
Re: (スコア:0)
あの一級建築士って能力が不足してたから基準に満たない設計をしたんでしたっけ?
Re:誰? (スコア:1)
・能力がある者が強度不足になると知りつつ行った設計
・能力不足(しかし本人は能力があると思っている)による設計
どちらが悪いのでしょう?
Re:誰? (スコア:2, おもしろおかしい)
この後Theoが
料理セキュリティの基本を教えて美食倶楽部オープンソース界に帰らせる流れですね。Re:誰? (スコア:3, 興味深い)
もう教えるとかゆーレベルじゃない。あいつらはダメだ。 [libressl.org]
なんで外人はWebページのフォントにComic Sans MSを指定するのか (スコア:0)
日本人が創英角ポップ体を指定したがるようなもの?
Re:なんで外人はWebページのフォントにComic Sans MSを指定するのか (スコア:1)
一番下をよく読めばいいと思うな
Re:なんで外人はWebページのフォントにComic Sans MSを指定するのか (スコア:1)
http://security.srad.jp/story/14/04/24/1756212/OpenBSD%E3%81%8COpenSSL... [srad.jp]
Re: (スコア:0)
<blink>タグをまだサポートしているような古いブラウザを未だに使ってるセキュリティ意識ゼロのやつを煽って何がしたいの?
(Geckoはこの案が通って [srad.jp]廃止、Prestoはエンジン自体が開発終了、そもそもNetscape独自タグだったのでWebKit/Blink/IEは最初から非サポート)。
# 前のストーリーで誰も言及していないことに驚愕
Re:なんで外人はWebページのフォントにComic Sans MSを指定するのか (スコア:2, すばらしい洞察)
少しでもセキュリティ意識のある人なら,blink が CSS アニメーションで実装されていることに気づくからじゃなかな。
Re:誰? (スコア:2, 興味深い)
今回の件、実装がと言うより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の件の後ということで、敏感になっているので、
大げさに取り上げられたり、取り上げた記事が煽り気味だったりと、ちょっとした騒ぎになってますけど
そもそも、発生する条件が限定的で、そこまで騒ぐような問題でも無いように感じるのは
セキュリティ意識が低いでしょうか?
Re:誰? (スコア:3)
あなた自身はわかって書いているのかもしれませんが、誤解を招く書き方だと思ったので念のため。
菊池氏のブログ記事に対する僕の理解が正しければ、あくまでも OpenSSL の実装に脆弱性があるのであって、 RFC に定められた仕様に脆弱性があるわけではありません。菊池氏は、今回の OpenSSL の脆弱性が生じた最大の原因は RFC に書かれた注釈 (note) の中の一文だろうと分析していますが、 RFC に定められた仕様自体に脆弱性があるとは書いていません。それどころか、「ChangeCipherSpec は必ずこの位置で行うことになっています」と、仕様通りに実装されていれば防げた脆弱性であると書いています。
「実装というより RFC そのものに問題があった」という言葉の解釈によっては、間違ったことは何も言っていないとも受け取れますが、今回の状況は「仕様そのものに脆弱性があった」という (これまた割とよくある) 状況とは違うので、誤解を招く書き方だと感じました。
Re:誰? (スコア:1)
だから何?
OpenSSL は送信時には仕様を守っているけれど、受信時には仕様と異なるタイミングでも ChangeCipherSpec を受け付けるから問題になったわけ。わかる?
Re:誰? (スコア:2)
ChangeCipherSpec メッセージの正しいタイミングは RFC 5246 の 7.1 節 [ietf.org]に書いてある。また、不適切なメッセージは致命的エラーとして扱えと 7.2.2 節 [ietf.org]の unexpected_message の項目に書いてある。
相手に手間を掛けさせてイライラさせるだけのために自分でも意味のわかっていない質問をするのは、あなたは楽しいかもしれないけれど迷惑だからやめてほしい。
Re:誰? (スコア:2)
条件は限定的でも、MITM attackを許すってのがまずいなと思っています。ご存じの通り、MITM attackを許すことは、SSL/TLSの信頼性をまるっと否定されるってことです。
これがDoSとかだったら、たとえ多少攻略しやすいものでも問題の度合いは低くなるかなと。
Re: (スコア:0)
致命的な物も含めてバグが短期間に複数見つかれば「他にもまだ残っているんじゃないのか?これは使って大丈夫なのか?」と疑うのは不思議ではありません。
Re: (スコア:0)
NSAの可能性を考慮するよりも、検証方法を改善した方が有益。
Re:誰? (スコア:1)
検証方法はCoq [inria.fr]
Re: (スコア:0)
無能で十分説明されることに悪意を見出すな
Re: (スコア:0)
いや、だから
「この機能をコーディングし実装した人」と「レビューして許可した人」
が無能だなぁと言っているんだと思うよ。
Re: (スコア:0)
他人の成果を無料で使って文句だけは言うような連中の
1%でもいいから、コードレビューに貢献してれば
15年は前に見つかったかもしれないな。
Re: (スコア:0)
最終的にレビューして許可した人はユーザ自身でしょ。
Re: (スコア:0)
じゃあセキュリティ専門家とやらは単なる給料泥棒だからみんなクビにしよう。
Re: (スコア:0)
> この機能をコーディングし実装した人は。
コミットログを調べれば分かるのではないでしょうか。
> さらにいうなら、レビューして許可した人は。
個々のプロジェクトでOpenSSLを使うということを決めた人ですね。
まだ終わらんよ! (スコア:0)
このバグ、LibreSSL界隈ではもう見つかっていたり、削除済みだったりするのかな?オーバーホールには時間がかかりそう?
yの次がzaとかバージョン番号の付け方からして破綻ぎみなので、もし1.0.2がでるなら、もう1.0.2aとかアルファベットをつけるのはやめた方がよいと思います。1回2回の修正じゃ終わらないでしょう?きっと。
Re: (スコア:0)
LibreSSLではどうなのかまったく報告のないところが確かに気になる。
Re: (スコア:0)
これでしょ。
http://freshbsd.org/commit/openbsd/d0c8802058444e603a0afd1f71bebd26c34... [freshbsd.org]
OpenSSLから、って書いてある。
Re: (スコア:0)
LibreSSLプロジェクト側で見つかってるなら、とっくに報告されてると思うぞ。
今回の脆弱性はOpenSSLの過去バージョンすべてに影響するから、OpenSSL 1.0.1gからフォークしたLibreSSLにも当然存在するはず。
Re: (スコア:0)
Unfortunately the recent OpenSSL commit was the first we were made aware of the issue. [opensslrampage.org] (jsing)
it is more likely that ... the vendor (OpenSSL) directly handed advance information to each redistributor they selected [undeadly.org] (deraadt)
There are plans to strengthen state machines (a la privsep openssh), which may help. [twitter.com] (miod)
Re: (スコア:0)
相手がなりすましかも知れない状況で暗号化する意味とは?
そもそも、認証局無しでどうやって暗号鍵を安全に交換するの?
手渡しですか?
銀行なら郵送でも良いかもしれませんがw
Re:SSLなんて捨てちまえ (スコア:1)
>認証局を信用するバカはいつも騙されるだけなんじゃないの
ルート認証局とか中間認証局になるときのレギュレーション、監査の厳しさを知らないんですね。
普通のセキュリティ監査は、字面は厳しくても実態にあわせた対応を可能にする「遊び」(外部監査の一部を、
記録付きの社内チェックで代替できるとか)があるもんだけど、あれは文字通りのガチ。
Re: (スコア:0)
「利権」しかボキャブラリのない痴呆はとりあえずこれを読め。
http://qiita.com/kawaz/items/f90810b9ea823b6556a8 [qiita.com]
Re:SSLなんて捨てちまえ (スコア:1)
>すり替えがないことの証明にならないのでしょうか。
通信する相手が既知ならばね。
SSHの場合は、公開鍵は既知だと仮定して、公開鍵だけで暗号データのやり取りをしています。
SSLの場合、既知だと仮定するのはあまりに無理があります。
公開鍵の数が違いすぎるからです。
現状のSSLの使用方法の場合
CA証明書 -> SSLサーバ証明書
という形態になっています。SSLサーバ証明書は、CA証明書の秘密鍵で署名してあるわけですな。
で、CA証明書だけ(通常は自己署名証明書)SSLクライアント(ブラウザ)に登録する方式にしています。
SSLサーバ証明書を使用せず、公開鍵だけで行こうとした場合、一応正しい、と仮定するためには、
いままでSSLサーバ証明書に含まれていた公開鍵をすべてブラウザに登録する必要が生じます。
そうでないとSSLサーバの公開鍵すべてを無条件に信頼することになってしまうからです。
その場合のブラウザで登録する公開鍵数、100億では済まないでしょうな、、
数は見当もつかない。。
Re: (スコア:0)
ま自分がバカな事ぐらいは自覚した方がいいよ。
Re: (スコア:0)
こんな利権 [securebrain.co.jp]が幅をきかせるだけじゃない?