2008年03月28日(Fri) 久しぶりに朝から雨 [長年日記]
● SSL/TLSのクライアント証明書の役割はsshの鍵対とは違いそう
おうちhttpsサーバのはなし。SSLの上にBasic認証を乗せるだけではなくて、せっかくだからクライアント証明書で内容を見せるかどうか決めようと思ってみたものの、どうもうまくいかない。
結城さんの「暗号技術入門 ― 秘密の国のアリス」を読んで、何を勘違いしていたのかわかりました。たぶん。僕はクライアント証明書というのは公開鍵暗号の鍵対のようなもので、sshでやるように、私有鍵をwwwブラウザに、公開鍵をhttpsサーバ(sshの場合は.ssh/authorized_keys)に入れておいて、接続時に、えーと、クライアントが公開鍵に対応する私有鍵を持ってることを確認するのかな、と思ってました。
ところが、「暗号技術入門」の356ページ「TLSのハンドシェイクプロトコル」に依れば、クライアント証明書のやりとりをする時は、(5)サーバからクライアントに理解できる証明書と認証局の一覧を渡す、(7)クライアントからサーバに(たぶんCAの署名付きの)クライアント証明書(って公開鍵ですよね)を渡す、(9)クライアントからサーバに、クライアントの私有鍵での署名を渡して私有鍵があることを証明する、という手順になるようです。サーバにはクライアントの公開鍵は置いておかず、CAの署名でクライアントの公開鍵を受け入れるかどうか決める、ってことだよね。
おうちhttpsの場合は、クライアント証明書でクライアントが僕であることを確認しようと思っていました。この場合は、クライアント証明書はCAcert.orgに署名してもらうのではなくて、おうちhttpsサーバ自身をオレオレCA局にした方がいいんですね。そうしないと、CAcert.orgに署名してもらったクライアント証明書を持ってる人は誰でもおうちhttpsサーバの内容を閲覧できてしまう。あー、いや、クライアント証明書の内容で閲覧の可否を決められるのかも。
というわけでもう少し実験してみます…いつになるかわからないけど。
● ドライブにCDを食われる
中古品を集めて仕事場のサーバをつくろうとしているのだけれど、CD-ROMからのインストールが進まない。メディアのチェックで止まっちまう。昨日はmemtestをして悪いメモリをみつけ、良いものととりかえた。今日はCD-ROMドライブを取り外し、古いPCから取り外したものを取り付けてみたら…起動の途中でドライブが反応しなくなりましたよ。BusyのLEDがずーっと点滅してるの。
しかたがないので(笑)、インストーラの救出のために分解しました。よくできてるなー。故障したけど。
結局、今回はメディアが問題だったみたいで、別に焼いたCD-ROMからはインストールが進みました。せっかく救出したインストーラはごみ箱にぽい。
● [memo] Ubuntuでキーボードの配列を変える
ubuntu-8.04-beta-server.i386。muttを使うマシンなので日本語のサポートが欲しい思い日本語でインストールしたらキーボードが日本語配列になってしまった。mono-hateの日記を参考に、dpkg-reconfigure console-setupしたら直った。
キーボードの選択肢にはHappy Hacking Keyboardもあって喜んだが、コンソールのロケールやフォントまで選ばされて閉口した。Cで普通のVGAのフォントでいいじゃん、と思うのは古いのかな。
駄目なCD-ROMは円盤投げの練習に使うとか窓辺から反射攻撃するのに使うとかした方が有意義だと思います（嘘）。<br><br>というのはおいといて、自己証明は安全でないとかいう単純化しすぎた想念が流布されているせいで、第三者を使わないといけないと思い込まされている人が多いのではと危惧します。結局CAが信用できるかって問題なので、自分自身が使う限りにおいては、自己証明ほど信用できるものは他にないんですよね。CAの管理が適当なので安全に保てないとかなら別ですが。同じ理由で、OpenVPNなんかは自己証明を使わなきゃいけないとマニュアルに記されています。
以前CD-Rを畑の鳥除けにしてたのですが太陽にあたって色素の層がぜんぶはがれちゃいました :)<br><br>さて、あるCAを信用するかどうか決めたとして、接続先から提示された証明書に署名したのが本当に自分が信用しているCAなのかどうか確認する必要があると思います。<br><br>OpenVPNの場合は、http://openvpn.net/index.php/documentation/howto.html#pkiを見ると、Master CAの公開鍵(ca.crt)をクラアント側にコピーしているように見えます。そうすれば、クライアントはサーバから提示された証明書のMaster CAによる署名を検証できそうです。<br><br>httpsの自己署名サーバ証明書の場合は、一般的にはクライアントにCA局の公開鍵が無いので、サーバから提示された証明書のCAによる署名を検証することができません。おうちサーバの場合はおうちCAの公開鍵をブラウザに入れておくという解もある(おっしゃる通りCAcert.orgの証明書を入れておくより安全かもしれない)のですが、、一般的なhttpsサーバの場合はそうはいかなくって、wwwブラウザの配布元が信用すると決めたCA局が署名してるなら安全ということになってるんじゃないでしょうか？<br><br>いずれにせよ、CAcert.orgのおかげでいろいろ考えさせてもらってます。ありがたいことです。
もちろん検証を行う状態にすることがとても大切です。自分のCAなら自分の手元で作っているものですから、これ以上確かなものはないってだけです。しかし一旦誰が検証したものかを確認できたら、その後はそのCAが信用できるのかって問題になっちゃうわけです。<br><br>アクセス制御に用いる場合、そのサービスにアクセスできてはいけない人が証明されたりすると困るので、そのサービスの管理者が誰を証明するのか、決定権を持たないといけません。だから、通常、こういう場合には第三者に頼むわけにはいかないです。<br><br>そうでない場合、不特定多数にサービスする場合、安全性のために署名したいってときですが、個人的にはブラウザに付いているから安全というのは非常に乱暴な議論だと思ってます。そこのところでいきなり理論的安全性が崩れ去っていて、いくら「弊社では厳重な検査の上...」とか謳っていたとしても、その会社を直接知らない大部分の人々にとっては「多分大丈夫なんだろう」という感覚の域をでないからです。Verisignだったら大丈夫とか言っている人の気持ちがさっぱり理解できない今日この頃です。
不特定多数へのサービスのためのPKIでは信頼の根っこをどうやって決めるか、が大問題なのかな、という気がしてきました。<br><br>アクセス制御に用いる場合はサービスの管理者がどのCA(たぶん自分自身)を信用するか決めてその公開鍵をサーバに入れればいいし、不特定多数のサービスについてもPKIやCAについてわかっている人は自分で判断してCAの公開鍵を消したり追加したりできます。<br><br>いっぽう、このような技術について知らない人が不特定多数へのサービス(httpsのサイト)を使う場合には、暗黙の前提として、wwwブラウザのベンダが信用できるとしているCAは「多分大丈夫なんだろう」と思わせざるを得ないのではないでしょうか？自分の身の回りを見渡しても、同僚の全てに独自のCAの公開鍵を安全にインストールしてもらうのはずいぶん大変そうです。で、そういう人たちを相手にビジネスをしてる人たちとしては、やっぱり「Verisignだったら大丈夫」とか言っておきたいんだろうな、と想像します。<br><br>もしPGPやGPGのweb of trustが一般的になってたら、日常的な感覚に近い、口コミで信用度を決めるようなhttpsが設計されたりしたんでしょうか？いあ、「お上の言うことは信じる」PKIも、それはそれで日常的な感覚に近いのかもしれないです。結局大多数の人は「多分大丈夫なんだろう」という感覚の上に生活をしてるような気もしてきました…
zundaさんはとても正しく認識していると思いますよ。つまるところ、世の中は感覚的に「何となく」で動いているという事実を受け入れていればいいんだと思います。
![[FSF Associate Member]](/p/171619.png){kind=small}
最近のツッコまれどころ