_ BIND で使うゾーンファイルの書式は BIND が勝手に決めたわけではなく、実は RFCで規格化されている(なので、BIND だけじゃなくて NSD でも同じ書式。djbdns は独自形式だけど)。
_ とはいえ、BIND はそれを生のまま使ってるわけではなく、勝手な拡張もしている。 $GENERATEとか。これが何モノかというと、連番を自動生成するためのもの。
↑と↓は同義。$GENERATE 1-10 host-$ IN A 192.0.2.$とっても楽ちん。ただし、$GENERATE はあくまでゾーンファイルの記述を簡略化するだけで、DNS のプロトコルを拡張するわけではないので、master -> slave へのゾーン転送ではマクロ展開後のゾーンがやりとりされるし、ファイルのサイズは小さくなるけどメモリの節約にはまったくならないことに注意。動的な自動生成ではなく、静的なもの。host-1 IN A 192.0.2.1 host-2 IN A 192.0.2.2 host-3 IN A 192.0.2.3 ... host-10 IN A 192.0.2.10_ さて、ここにとあるプライベートアドレス空間があります(いや、グローバルでもいいけど)。このうちの65536個のアドレスに同様に自動生成な名前をつけたいんですがどうしたらいいんでしょうか。よーするに、172.16.0.0 - 172.16.255.255 にユニークな名前を割り振ってあげたいんですが。
_ 172.16.0.0 - 172.16.0.255 ならば $GENERATE 0-255 で済むので簡単。でも、今回の場合は 0-255 の組がふたつ必要になるわけで。さてどうすればいいんでしょ。BIND のドキュメントを何度読み返してみても、$GENERATE の多重展開ができるような仕様にはなってなさげ。やっぱりできないってことですかね。せっかくお便利機能があっても、こういう場合には $GENERATE 自体を256行並べるか、そうでなきゃプリプロセッサを自作しなけりゃいかんのですかね。めんどくせーなー。
_ どなたかうまい方法とか裏技とか知ってる人がいたら教えてください。ってゆーか、世間の ISP の皆様はどうやってああいうゾーンを書いてるんですかね。わしの知ってるところは $GENERATE に頼らず頑張ってるけど、どこもそうなんですかね。
_ まあ、むしろ $GENERATE の多重展開なんてできない方がいいのかもしれないけどね。そういうことができてしまうと、ipv6 の広大な空間を $GENERATE で自動生成しようとするアホがきっと出てくるだろうから。たとえば /64 に漏れなく名前を割り当てるとすると 2^(128-64) 個、仮に名前1個につき1バイトという驚愕の圧縮率を実現したとしても、合計では16エクサバイトという素敵なサイズになってしまう。v6 には慣れてない人が多いだろうから念のため書いておくと、/64 ってネットワークセグメントたったの1個分だからね。
_ つーか、こんなことやってるから IP アドレス1個につきそれぞれユニークな正引き逆引きな名前がついてるのが常識だと考える人が後を絶たないんだろうなー。どっちかというと、そう考える人からのクレームを未然に防ぐためにやってるわけで、こっちはそれが必須だとはまったく考えてないんだけど。ニワトリと卵な関係になってしまっている。
_ きっかけは、先週に某所でやった SSL 証明書の更新だった。作業の最後、更新後のサーバに正しくアクセスできるか確認。
↑CentOS の場合(それ以外は別の場所にあるか、そもそも標準には存在せず自力で調達してくる必要がある環境も多い)。で、若人から質問「この -CAfile ってなんですかー？」 そんなの、オプションなしで試してどう変わるか見ればいいでしょ、と返したら、「変わりませんよ？」$ openssl s_client -connect hostname:port -CAfile /etc/pki/tls/certs/ca-bundle.crt_ はぁ？ なにそれ、と思って彼の端末を覗きこんでみたらたしかにそのとおり。いや、おかしいだろ。証明書の正しさをチェックするための起点になるルート証明書を指定してないのに、なんで veirfy ok な結果になるのさ。ちゃんとした証明局から買った証明書であっても、ルート証明書がなければ「誰が発行した証明書かわからんから信用ならん」という結果が返ってくるはずなんだが。というか、centos じゃない環境で叩くとたしかにそういう結果になるんだが。
_ 結果自体に問題はないので、こんな感じでその場はおしまい。が、これがどうにも解せないので後で詳しく調べてみたら、ひじょーに気持ち悪いことになっていた。ぶっちゃけ、こんなの平気で使ってる人の気が知れないぐらい。長くなるので続く。
_ RedHat の〜と書いてあるけど、ホンモノの RHEL は高いのでパチモノの CentOS で。
_ ということで調査開始。また妙なパッチを適用してるんだろうから、ということで手始めにインストールされている openssl のバージョンを調べて、そいつのソースパッケージを拾ってきて中身をバラす。
rpm2cpio は freebsd なら ports の archiver/rpm2cpio にあるです。RPM な linux ならたいてい標準装備のはず。で、中身はというと、案の定、大量のパッチが含まれている。% rpm2cpio.pl openssl-0.9.8e-12.el5.src.rpm | cpio -idmvMakefile へのパッチなんてのもあるので実質的なソース修正はもう少し減るけど、多いことには変わらない。で、目をひいたのは、こんなファイル名のパッチたち。% ls *.patch | wc -l 32んー、fips って何ぞ、と思ったらソースの tar 玉自体もそうだった。openssl-fips-0.9.8e-abi.patch openssl-fips-0.9.8e-aescfb.patch openssl-fips-0.9.8e-algo-doc.patch openssl-fips-0.9.8e-bad-mime.patch openssl-fips-0.9.8e-bn-fixes.patch openssl-fips-0.9.8e-cve-2008-5077.patch openssl-fips-0.9.8e-cve-2009-0590.patch openssl-fips-0.9.8e-default-paths.patch openssl-fips-0.9.8e-dtls-dos.patch openssl-fips-0.9.8e-dtls-fixes.patch openssl-fips-0.9.8e-env-nozlib.patch openssl-fips-0.9.8e-evp-nonfips.patch openssl-fips-0.9.8e-fipsmode.patch openssl-fips-0.9.8e-multi-crl.patch openssl-fips-0.9.8e-no-pairwise.patch openssl-fips-0.9.8e-redhat.patch openssl-fips-0.9.8e-rng-seed.patch openssl-fips-0.9.8e-use-fipscheck.patchなにそれキモい。-rw-rw-r-- 1 yamaya user 2991178 Jul 22 2008 openssl-fips-0.9.8e-usa.tar.bz2_ そんなものがリリースされたなんてアナウンスを聞いた記憶がない。実際、openssl のサイトでは、セキュリティホールが存在していたものも含め、かなり昔にリリースされたバージョンのものが今でもダウンロードできるが、その中にこんなものは見当たらない。てゆーか、今まで .bz2 で配布されたことあったっけ？ この tar 玉の出所はどこ？ ぐぐってもロクにひっかかんないよ。出自があやしいものを使ってはいけない、というのはセキュリティにおける鉄則だと思うが、その中でもとくに安全に気を配らなければならない openssl で出所不明なソースを使うってどういうこと？ もしかしたら、わしが知らないだけで公式サイトとは別の準公式的なものがあるのかもしれないが、だとしても、なぜわざわざそんなものを使うのかさっぱりわけがわからない。
_ OS の一部として RPM がインストールされるときは、GPG の署名をチェックしているはずなので、RedHat が出自を保証しているといえるかもしれない。が、それでいいの？ 中の人がおイタしないという保証にはならないよね。openssl.org から公式にリリースされたものがすでにおかしい、という可能性もないではないから、どっちでもたいして変わらん、という考えかたもできなくはないが、誰も使っているツールの公式リリースと、一部の人しか使わない非公式なパッケージのさらに一部の人しか中身を見ないソースアーカイブでは目を光らせている第三者の数がぜんぜん違う。相当多数の「第三者の目」がある場合でも何年も見逃され続けているバグもあったりするのに、有名なツールだけど実は出所不明なソースを使っていることがほとんど知られていないものでは、そういうチェックはまったく機能しないと言い切っていいレベルだよね。
_ ところで、fips とは何か。Wikipedia(ja) の記述: FIPS、 FIPS 140。よーするに、暗号まわりのアメリカの国内規格らしい。なんでも、FIPS 140-2 の認定を得たのはオープンソースでは openssl が最初なんだそうで。で、バージョン違いまで含めた FIPS 140 認定済み全リスト(そこから openssl だけ抜き出したもの)を眺めてみても、0.9.8e は含まれていない。というか、そもそも 本家サイトを見ればわかるとおり、バージョン番号のつけかたが FIPS 版と通常版で明らかに違うよね。
_ 認定リストには含まれてないけど、/usr/share/doc/openssl-0.9.8e/README.FIPS を見ると
という一文がある。うーん、どういうことだろうねぇ。This package contains libraries which comprise the FIPS 140-2 Red Hat Enterprise Linux - OPENSSL Module._ 例の出所不明の tar 玉の中に、上のと同じファイル名で中身が異なる README.FIPS が含まれている。その冒頭。
あのー、test って書いてあるんですが。Brief instructions on using OpenSSL 0.9.8 FIPS test branch_ 見なかったふりして、このファイルの手順にしたがってビルドしてみる。
どう考えても FIPS の認定を通ったものじゃないよね、これ。$ ./config fipscanisterbuild ... WARNING: OpenSSL has been configured using unsupported option(s) to internally generate a fipscanister.o object module for TESTING PURPOSES ONLY; that compiled module is NOT FIPS 140-2 validated and CANNOT be used to replace the OpenSSL FIPS Object Module as identified by the CMVP (http://csrc.nist.gov/cryptval/) in any application requiring the use of FIPS 140-2 validated software. This is an OpenSSL 0.9.8-fips test version. See the file README.FIPS for details of how to build a test library_ で、このソース、コンパイルが通らない:-)。CentOS だけでなく、FreeBSD や Debian でも試してみたが、同じところでエラーになる。あの大量にあるパッチを当てることでちゃんと最後までビルドできるようになるんだろう、きっと。ところで、HP-UX には FIPS な openssl が含まれているらしい。 それに関するドキュメントより。
重要: FIPS コードは、OpenSSL の Web サイト上で Open Source Software Institute (OSSI) がリリースしたソースコードと同じ場合だけ認定されます。セキュリティ上の脆弱性があった場合でも、そのソースコードを修正すると認定が無効になるため、当社ではソースコードを修正することはできません。この記述からは、FIPS なソースコードにパッチを当てるのはご法度、と読めるんだが。じゃあ、あの大量のパッチは何なんだろうか。
FIPS コードに脆弱性が見つかった場合、当社は OSSI が FIPS 140-2 認定済みの新しい FIPS モジュールをリリースするのを待ち、それから HP OpenSSL 製品を新しい FIPS コードでアップデートします。_ そんなこんなでできあがる openssl のバージョンはというと。
これ詐欺じゃないの？$ openssl version OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008_ FIPS な openssl についてはよく知らないけど、通常版と FIPS 版で機能的な違いはそれほど大きくはないんじゃないかと思う。だとしたら FIPS 版をわざわざ使うことにどんな意義があるかというと、公的機関の認定を受けている、ということに尽きるだろう。FIPS 自体について知ってることはほとんどないので認識にどこか間違いがあるかもしれないけど、ちゃんと公的認定を受けたソースはかんたんに入手できるのに、それを使わずに test brunch で TESTING PURPOSES ONLY と書いてあるようなソースを使うことがおかしいと判断することは間違いでないはずだ。
_ FIPS は北米の規格であって、日本ではまったく価値がないといっていいだろうし、ぶっちゃけわしもまったく興味ない。だが、最低限 FIPS 版のソースを元にしているから関連コードが含まれているけど、正式に認定を受けたものではないからそういうものが必要な場合には使えないよ、という記述がドキュメントのどこかに存在していないといかんのではないか。ところが実際にドキュメントに書いてあるのは "libraries which comprise the FIPS 140-2" という正反対の文言。アメリカってこういう詐称で問題にならないの？
_ この openssl の RPM は世界中で広く使われていて、それが大きな問題を起こしたという話は聞いてない。過程がおかしくても、結果として正しく使えていればそれでいいという考えかたもあるかもしれない。でもそれでいいの？ 出自のあやしいソースを使って規格の意義をないがしろにするような精神の持ち主が作るようなものは、ほかのところでも何かおかしなことをやらかしていないか不安になるのがふつうだと思う。てゆーか、なんでこんな気持ち悪いことをやってるのか、経緯がさっぱりわかんないんだよね。どっかの ML アーカイブとかにそのへんの流れがあるかもしれないけど今のところ見つかってない。
_ なお、前述のとおり、調べたのは CentOS の上なので、もしかしたらほんものの RHEL では事情が異なって、このタイトルは大嘘かもしれない。ただ、パチモノの CentOS がここだけホンモノの RHEL とは異なる独自性をアピールするとは思えないし(しかもネガティブな方向に)、RHEL の errata を調べると CentOS にも符合する点ばかりなので、RHEL も同じと見て間違いないと思う。
_ もうひとつの RedHat ファミリー、Fedora も調べてみた。openssl-1.0.0-0.10.beta3.fc12.src.rpm をバラして中を眺めただけ。
ちうことで、異なる部分も多いけど、キモいという点ではたいして変わらん。
- 同梱のソースはやっぱり openssl-1.0.0-beta3-usa.tar.bz2 という出所不明のもの
- FIPS まわりは上記ソースには含まれず、パッチになってるっぽい
- そのパッチには CentOS 版で test だの not FIPS validated だのとかの記述があった部分が抜けてるので、はじめから疑いの目を持って見ないと FIPS 詐称には気付かないかも
_ それ以外の RPM 系派生ディストリは調べてないのでわからん。非 RPM 系も調べてない。非 linux もわからん。違うかもしれんが同じかもしれない。なんともいえない。
_ というわけで、ルート証明書なしで verify ok になってしまうという気持ち悪さから調べはじめたわけだが、そもそもの発端の調査はどっかいってしまった。結局なんか変なパッチが当たってるんだろ、という推測のまま止まってる。これも十分以上に気持ち悪いんだけど、別のところがあまりに衝撃的すぎて霞んでしまった。
_ もともとの疑問だった、 s_client が -CAfile なしで verify ok になってしまう件。 これ。「openssl のバグだから直したよ」だそうな。
_ んー、もしほんとにこれがバグなのであれば、なんで openssl の本家に報告して、オリジナルの方を修正してもらわないんだろうか。そうすれば redhat のユーザ以外も幸せになれるし、redhat の中の人もメンテしなきゃいけないパッチが少なくなって幸せになれるのに。
_ てゆーか、これほんとにバグなの？ 「指定がなければどこそこにあるファイルを使うよ」といった記述はドキュメントのどこにもないわけで、とくに指定がないかぎり空っぽで実行するというのが仕様なんじゃないの？ コマンドラインから証明書の内容をチェックする手段としてもっとも基本的なツールで正しく検証できないなんていう原始的な「バグ」が長年に渡って放置されるとは到底思えないんだけど。少なくともわしはそういう認識で何年も使っていて、だからこそこの挙動がキモいと感じてるわけで。「バグだから直した」じゃなくて、「仕様かもしれないけど、そっちの方が便利だからそう変えちゃう」というコメントなのであればまだ理解できなくもないんだが(理解しても同意はしない)。
_ えーと、 Fedora での状況に関して、
と書いたけど、抜けてるかわりにぜんぜん別のところでこういうパッチを当てていた。
- そのパッチには CentOS 版で test だの not FIPS validated だのとかの記述があった部分が抜けてるので、はじめから疑いの目を持って見ないと FIPS 詐称には気付かないかも
ということで、CentOS よりもはっきりと「テストにしか使えないよ」と書いてあった。 最低限のことはやってました。ごめんなさい。--- openssl-0.9.8j/README.warning 2009-01-07 11:50:53.000000000 +0100 +++ openssl-0.9.8j/README 2009-01-14 17:43:02.000000000 +0100 @@ -5,6 +5,31 @@ Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson All rights reserved. + WARNING + ------- + + This version of OpenSSL is built in a way that supports operation in + the so called FIPS mode. Note though that the library as we build it + is not FIPS validated and the FIPS mode is present for testing purposes + only. + + This version also contains a few differences from the upstream code + some of which are: (以下略)