OpenBSDがOpenSSLの大掃除に着手、「OpenOpenSSL」サイトも立ち上がる 96
OpenBSDが動く 部門より
OpenBSDがOpenSSLの大掃除に着手しています（slashdot）。
たとえばlibssl/src/sslを見ると、CVSに罵倒と修正がひっきりなしに記録されています。
Heatbleed対策のパッチだけで満足しなかった理由は、彼らから見てHeartbleedが単なるバグや仕様の問題ではなく、セキュリティ意識の問題から産まれたものだからです。
何年も前から 「OpenSSL はサルが書いてるんだろう」と揶揄していたとおり、OpenSSL コードの品質が低いことをOpenBSD開発者たちは知っていましたが、それが意識や責任感の問題だという確信はまだなかったのかもしれません。
OpenBSD にはメモリ防護機構がありますので、Heartbleed脆弱性があっても当初、malloc.confにJオプションを付ければfree済みメモリはシュレッダーにかけられ秘密は漏れないだろうと思ったそうです。しかし実際には効きませんでした。OpenSSLは独自のfreelistを管理することで、脆弱性緩和策を回避し、確実に脆弱になるように書かれていたのです（拙訳）。しかも、オプションで普通のmalloc/freeを使うようにすると動作しません。それはfreelistに捨てたメモリを拾い直しても内容が同じであるという前提のコードだったからです。
つまりOpenSSLは、速度のためにセキュリティを犠牲にするオプションを追加し、それをデフォルトにし、それを無効にした場合のテストをしていなかったということになります。こうした事情を考えた結果、OpenBSDでは上流とマージしやすい状態を保っていたOpenSSLを今後独自にメンテナンスすることに決めたということのようです。
ちなみにOpenBSDは、「俺たちがいないと困るだろう。だったら続けられるように金をくれ」と言っています。今のままのOpenSSLで満足なら無視すればいいのですが、OpenBSDがこれまでどおりOpenSSHなどを開発しつつ、それに加えてOpenSSLにも注力することを望む場合には、OpenBSDのCD 購入や寄付といった援助を増やすことができます。彼らは「脆弱性をスポンサーに売って暮らしているような開発チームはバグを減らしたくないはずだ」と言って FreeBSDに敵意を向けています。そういった形態をとらずに開発を続けているOpenBSDが資金に苦労する日々はまだ続きそうですから、今回の件は、資金集めのための話題づくりという意図もあるのかもしれません。
OpenBSDが立ち上げたサイトopnopenssl.orgでは、「インターネットのセキュリティをアマチュアの手に置いておく訳にはいかないからプロジェクトを立ち上げた」と説明されている。
遅いと使われない (スコア:2, 参考になる)
いかに強い暗号であろうとも、遅いと使われません。
ということで、脆弱性を起こさないようにしながらも速度を優先するのは必要悪かと。
OpenSSLのコードが読みにくいという部分は同意。
でもこれは、今では廃れたコーディングスタイルという所から来ているような…。
Re: (スコア:0)
SSLの目的はセキュリティなんだから遅さなんてどうでもいい話です。速さよりも安全性を追求するべきです。
Re:遅いと使われない (スコア:2)
「速さより安全性の方が重要だ」ならそうだと思うけれど、「目的はセキュリティなんだから遅さなんてどうでもいい」というのは現実と合っていないよ。当然、程度問題。
Re: (スコア:0)
速度を求めるなら最新のプロセッサとそれに付随するハードウェアアクセラレータを使いなよ
Re:遅いと使われない (スコア:3)
たぶんあなたは暗号理論における遅いアルゴリズムがどのくらい遅いかわかっていないと思う。
Re:遅いと使われない (スコア:1)
先祖コメが問題にしてるのは、暗号アルゴリズムじゃなくて、(たぶん)メモリ保護の話ですよね。
オプションで設定できるとしても、そこに行くまでに回り道が多くて、どことトレードオフしているのかはっきりしなくなる、ってのはバグを追っかけてるとよく発生する話で、分野的な門外漢だとわかりにくい、ってことは往々にあるわけですから。ましてや、今回のはオプション設定を切ると動作しなくなるのですから、標準的なmalloc/freeを使っていたユーザーが1人もいなかった、典型的なキッチンシンク事案ですね。「こうすると動く(しかも速い)からさわるなよ」、ってことでしょう。
プロセッサ云々は噴飯物ですが。
Re: (スコア:0)
スタンドアロンでいくら早くなってもネットワークが遅いままでは話にならない
Re: (スコア:0)
で、どれだけ速くなるの
UI再設計 (スコア:1)
UIというか何と言うか、opensslコマンド（相当）のオプションとか引数とか、その辺りもごっそりの見直してくれないかな。
Re:UI再設計 (スコア:1)
それをするぐらいならopensslじゃなくて他のを使ったりfrom scratchで書くと思う。
portsその他への影響を最小限にするためopensslのforkを選んだのでは。
Re:UI再設計 (スコア:1)
オフトピですが、セキュリティ関連ツールのUIがひどいのは確かですからね。
GitHubに秘密鍵をアップしちゃうバカが後を絶たないのも、そこら変に問題があるんじゃないでしょうか。Combat Proofはあっても、Fool Proofになってない、というか。
Re:UI再設計 (スコア:1)
Re:UI再設計 (スコア:1)
コマンドのopensslって、あくまでもライブラリのお試し用か試験用って感じだよね。
例えば、opensslのcaコマンドのマニュアルにも、排他制御しないので並列処理は無理(意訳)、って書いてある。
その程度のものだと思って使うのが正しいんじゃないかな。
まともに使えるUIは、別のプロジェクトでどうぞ、ってことなんでしょう。
実際、OpenSSLのライブラリをリンクする認証局ソフトウェアもいくつか出てるね。
Open Open (スコア:1)
やられた、Openを重ねる発想はなかった。
Re:Open Open (スコア:1)
libre office が仲間になりたそうにこっちを見ている…
発想は古くからあるよね (スコア:1)
_ ∩
( ﾟ∀ﾟ)彡 おっぱい！おっぱい！
⊂彡
やっぱりオープンソースは信用できない (スコア:1, すばらしい洞察)
一番信頼性が重視させるOpenSSLの実装がこれじゃあね。
みんなが自由にソースを見ているから信頼性が高くなるなんていうことが
幻想に過ぎなかったってことを実証しちゃったって感じだなあ。
Re:やっぱりオープンソースは信用できない (スコア:5, 興味深い)
安心しろ、クローズドソースのRSA社から買える実装のソースも絶望的に汚い。
Re:やっぱりオープンソースは信用できない (スコア:2)
煽りなのかも知れないけど、その通りだよ。
テストやコードのチェックもせずに「～だから信用できる/できない」ってのは全て誤り。「わからない」が唯一絶対の正解。
「～だから信用できる/できない」と仮定することで得られるものもあるので、機会費用として適当に見積もっておいしいところを得るのが本来ですかね。
Re:やっぱりオープンソースは信用できない (スコア:1)
その観点だとクローズドの方がより怖いと思うけど。
Re:やっぱりオープンソースは信用できない (スコア:1)
>> みんなが自由にソースを見ているから信頼性が高くなるなんていうことが
>> 幻想に過ぎなかったってことを実証しちゃったって感じだなあ。
> その観点だとクローズドの方がより怖いと思うけど。
もはや、オプソ信望者たちのプロプラ（クローズド）ディス理論も力なしか。
まともに反論もできなくなってしまった。
「その観点」で「クローズドの方が～」って全然繋がってないが。
オプソの利点は、何か自社ソフトウェアを開発する際に流用できるという程度じゃないだろうか。
Re:やっぱりオープンソースは信用できない (スコア:1)
こうやって晒されて、これから鍛えられて、信頼性が上がっていくんだから合ってるんじゃね。どうでもいいけど。
まあテキトーな根拠で安全安全しつこい奴が鬱陶しいのはわかる。
さすがに (スコア:1)
UnclosedSSLとかOpenSSL(revised)とか、そういう微妙な名前にはできなかったか。
# しっかし改善項目の中に"KNF of most C files"があるあたり、根が深そうだなぁ。
## コーディングルールすら守れてないのだろう、という意味であって、スタイル種別はまあいいんだけどね。
M-FalconSky (暑いか寒い)
openopenssl.org (スコア:1)
と書かれているけど、OpenBSDプロジェクトが立ち上げたというアナウンスはどこかにあった？みつけられず・・・
Re:openopenssl.org (スコア:1, 興味深い)
whois openopenssl.org してみると GoDaddy で取得されて、かつ、Whois情報匿名サービスが利用されていることがわかる。
openopenssl.org の ns は dns.linbsd.org で、 linbsd.org の Whois情報もおんなじ感じ。
ちなみに http://linbsd.org/ [linbsd.org] はよくわからないサイト。
http://www.openopenssl.org/ [openopenssl.org] はさっぱりつながらないけど、怪しさ満載ですね。
Re:openopenssl.org (スコア:1)
Re:openopenssl.org (スコア:1)
自己レス。（まだまだ）名前は必要としてないよ。という中の人のコメントありました。
One week of OpenSSL cleanup [undeadly.org]
なんというウルテクw (スコア:1)
でもこの挙動を暗黙の前提として動作する関数って、並列スレッドから同時利用した場合に破綻しないのだろうか
インターネットの土台を固めよう (スコア:0)
ヒルベルト・プログラムのように土台を固めるプロジェクトが必要です。
Re: (スコア:0)
とういうより階型理論じゃね
opnopenssl.org (スコア:0)
opnopenssl.org
hylom
Re: (スコア:0)
???
Re:opnopenssl.org (スコア:1)
正しくは openopenssl.org ですね。
さすがOpenBSD (スコア:0)
BSDってだけですでにあれなのに、
> 「OpenSSL はサルが書いてるんだろう」
>「俺たちがいないと困るだろう。だったら続けられるように金をくれ」
>「脆弱性をスポンサーに売って暮らしているような開発チームはバグを減らしたくないはずだ」
FreeBSDをばっさり軟弱モノ扱い。
まさにKing of BSDですわ。実にしびれるあこがれる。
Re:嫌です。 (スコア:1)
こいつらに金払うくらいならMSに払ったほうがマシだよね
Re: (スコア:0)
サポート終了でーす
ネットから切り離してくださーい
Re:嫌です。 (スコア:1)
久しぶりにOpenSSH Tシャツ買おうかな、って気になったよ。
Re: (スコア:0)
>> OpenBSDがこれまでどおりOpenSSHなどを開発しつつ、それに加えてOpenSSLにも
>> 注力することを望む場合には、OpenBSDのCD 購入や寄付といった援助を増やすこ
>> とができます。
> 嫌です。
OpenBSDのCD購入や寄付といった援助を増やすことが嫌だというのは分かりましたが、
OpenBSDがこれまでどおりOpenSSHなどを開発しつつ、それに加えてOpenSSLにも注力することを望まないから、なのか、
OpenBSDがこれまでどおりOpenSSHなどを開発しつつ、それに加えてOpenSSLにも注力することを望むにもかかわらず、なのか、
どちらなのでしょうか？
嫌だという結論に文句を言うつもりはまったくありません。個人の自由ですから。
というか、世の中の大多数は寄付なんてしないですから、わざわざ「嫌です」なんて表明する必要すらないと思うのですが、
なぜ表明したくなったのでしょうか。
Re: (スコア:0)
傲慢な記事にイラッとしたのでは？
少なくとも私はそう思いました。
まぁ、私の場合はコードすらかけない部外者ですが。
Re: (スコア:0)
傲慢な部分は記事じゃなくてOpenBSDの主張じゃないかと思うんだが、それはそれとして。
「仕事をするから金をくれ」という主張が傲慢だと言われると、なんだかなぁ、という気はする。
無償でやれ！という主張なんだろうか。
それとも、お前らにそんな技術があると思ってるのか！という主張なんだろうか。
Re: (スコア:0)
引っかかるのは「お前らに頼んだ覚えはない」って感情だろうね。ただ、OpenBSD以上に実績があるグループがないので、次を待っていても誰も何もしないと思う。
Re: (スコア:0)
自分達の使うものが不満ならメンテナンスする、オープンソース的には至極当然の行為なのに
めずらしく掃除当番を張り切って大騒ぎして金銭の話まで持ち出す連中がいたらちょっと引きますね…。
撮り鉄が私有地を勝手に草刈りして入場料まで取ってた話、あれに近い感覚をおぼえました。
Re:嫌です。 (スコア:4, すばらしい洞察)
OpenBSD プロジェクトは長年にわたってセキュアなソフトウェアのために貢献しています。「めずらしく」どころではありません。
OpenBSD はセキュリティを主な目的としており、そこにおいて OpenSSL は根幹的な位置を占めています。その OpenSSL に壊滅的な脆弱性がみつかったわけですから、「大騒ぎ」してバギーなコードを叩き潰しに掛かるのは、合目的的な行動です。
OpenBSD プロジェクトは今年初めに資金難でサーバが維持できなる瀬戸際に追い込まれていました [marc.info]。現在は当面の危機を脱したとはいえ、継続的な支援は依然として必要とされています [openbsdfoundation.org]。開発リソースを OpenSSL にも振り向けるとすれば、より多くのコストが掛かるわけですから、さらなる支援を要請することは筋が通っています。
私はその「撮り鉄」の話を知りませんが、あなたの文面から判断する限り、本件とはまったく違う話ではないでしょうか。理由は以下のとおり。
Re:嫌です。 (スコア:1)
OpenBSD プロジェクトは今年初めに資金難でサーバが維持できなる瀬戸際に追い込まれていました [marc.info]。現在は当面の危機を脱したとはいえ、継続的な支援は依然として必要とされています [openbsdfoundation.org]。
しかも OpenSSL と資金を比較してみてください。
OpenSSL は「年100万ドルもないんだから仕方ないでしょう。もっとください」 [digitaltrends.com]
OpenBSD は「年6万3000(カナダ?)ドルでは苦しいから15万ぐらい欲しいな」 [openbsdfoundation.org](1米ドル≒1.1カナダドル)
OpenSSL と OpenSSH、どちらも世間で不可欠なインフラになっているのにこの違い。
OpenSSL はどこにこの金を使っていたんでしょうかねぇ……。
Re: (スコア:0)
「無償でやれ」とは言わないですが、他の人や企業が寄付をしたりして支えてくれるのに期待して、自分は無償で使わせてもらっています。
無償で使わせてもらっているソフトウェアはあまりにも多すぎて、それぞれから「金をくれ」なんて言われたら、いやになっちゃうと思う。
ただし、オープンソースコミュニティはゆるい組織だから、OpenBSDの中の人のひとりが「寄付をよこせ」みたいなことを言い出したとしても、
そうでない人もいるだろうし、それがOpenBSDの公式見解ではないということは理解しているつもり。
なお、いまのところ寄付をする予定はないですが、金輪際寄付なんてするものか、なんて思ってはいないので、
将来、気が変わって寄付をする可能性は全くゼロとは言えないです。
Re:嫌です。 (スコア:1)
A) OpenOpenSSLは要らない。OpenBSDに寄付しない。
B) OpenOpenSSLは要らない。OpenBSDに寄付する。
C) OpenOpenSSLを使いたい。OpenBSDに寄付しない。
D) OpenOpenSSLを使いたい。OpenBSDに寄付する。
このうちCは勘弁してくれ、ってだけでしょ。
寄付するのがいやなら A)を選べばいいだけです。
OpenSSLを使い続けるなり、GnuTLSなどに乗り換えるなり、自分で代替品を開発するなり、お好きにどうぞ。
他にいくらでも選択肢があるんですから、脅迫にはなりません。
Re: (スコア:0)
> OpenBSDがこれまでどおりOpenSSHなどを開発しつつ、それに加えてOpenSSLにも注力することを望まないから、
ですね。
困るなら金払えっていうなら、困る点をクリアしたいですね。代替えがあればいい。
Re: (スコア:0)
代替えがあればいい。
「え」はどこから来て、どこへ行くのか。
Re: (スコア:0)
Re:GnuTLSは？ (スコア:1)
GnuTLSはGPLだからOpenBSDとしてはだめだ。
yaSSL/CyaSSLもGPLだからだめだ。
PolarSSLもGPLだからだめだ。XySSLはメンテナンスされていない。
TropicSSLはPolarSSLがBSD互換ライセンスだったときからのforkだからこれはどうだ、
という提案はundeadly.orgの当該スレッドで出てるが、APIがOpenSSLとぜんぜん違うので難しいだろうとも書いてある。