TidBITS#885/25-Jun-07 TidBITS#885/25-Jun-07私たちの大多数は、ウェブブラウザのセキュア接続が実際にセキュア（安全）なものだと信じ切っている。でも、転送中に私たちの大切なデータを保護するために、実際のところ舞台裏では何が起こっているのだろうか？ Chris Pepper が、SSL/TLS 暗号化について検討する。どういう仕組みで動作しているのか、正しく働かせるにはどうすればよいか、将来のコミュニケーションに対しどのような影響を持ち得るのかといった話題だ。今週はまた、6 月 29 日と間近に迫った iPhone のリリース日（写真に注目！）を控え、Apple から更なる詳細が、とりわけ YouTube アプリケーションの追加が発表された。Apple はまた、約束通り YouTube ビデオを Apple TV に供給し始めた。今週のニュースの締めくくりとしては、Mac OS X 10.4.10 と、Safari アップデート、それに長らく待ち望まれた Universal Binary 版の Snapz Pro X 2.1 アップデートのリリースがある。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Jeff Carlson <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
大胆にも２桁のバージョン番号という禁断の領域に踏み込みつつ、Apple は Mac OS X 10.4.10 をリリースした。［訳注：「禁断の領域」と言っているのは“10.4.10”が文字列として“10.4.1”と“10.4.2”の間でなく“10.4.9”の後に来ることをすべてのソフトウェアが認識できる保証がないからです。］これは、RAW 画像サポートの追加、Bluetooth や USB での問題の修正、その他いくつかの問題点に対処を施したメンテナンスアップデートだ。 10.4.9 からの差分 (delta) 版アップデートはソフトウェア・アップデート経由でも、Intel ベース Mac 用（72 MB）と PowerPC ベース Mac 用（25 MB）の個別ダウンロードでも入手できる。コンボアップデート（Intel Mac 用で 293 MB、PowerPC Mac 用で 165 MB という巨大なもの）ならば Mac OS X 10.4 のすべてのバージョンがアップデートできる。
今回の新バージョンの Tiger では、Bluetooth ヘッドセットが Bluetooth 環境設定から正しく削除できないことがあった問題が修正され、スリープから復帰後に Apple Remote を使う時や外付け USB 機器をマウントする時の信頼性が向上、また Intel ベース Mac で GPS ナビゲーション機器 TomTom GO 910 を使う時の問題点を解消している。さらに、DNG 画像における歪みや変色の問題が修正され、また以下のカメラ： Panasonic DMC-LX1、Panasonic DMC-LX2、Leica M8、Leica D-LUX 2、Leica D-LUX 3、Fuji S5 Pro、Nikon D40x、または Canon EOS 1D Mk III で作成された RAW 画像に対するサポートが追加された。以上の他、リリースノートでは 64-bit Mac における Mathematica 6 との互換性の向上や、DV カメラからビデオを読み込む際にフレーム落ちが起こるという特定の問題を修正したこと、その他の変更点についても述べている。
Mac OS X Server 10.4.10 もリリースされ、PowerPC Mac 用 の差分 (delta) アップデート (58 MB ダウンロード)、およびユニバーサル版 (391 MB ダウンロード) ならびに PowerPC 版 (218 MB ダウンロード) のコンボアップデートとして入手できる。
文： Glenn Fleishman <[email protected]>
訳： 笠原正純<panhead@draconia.jp>
私は今週の金曜に iPhone を買うための行列に並ぼうと思う。私にはコンピュータテクノロジーについて物を書くことで稼いでいるという職業上の理由がある。と同時に、Steve Jobs が iBomb を投下した 1 月、ちょうど私は携帯電話を買いたいと思っていたのだ。私が現在使っている携帯電話は、4 年前の物だが、風向きの変化を察知したようで、たちまち動かなくなってしまった。終わりが近いことを悟ったのだ。
私は、Seattle にある University Village モール（商店街）で写真を撮るつもりだ。そこには会社直営の AT&T Store が一店舗と、Apple Store も一店舗ある。もし、あなたが私の撮った写真（フリーの Wi-Fi ネットワークか携帯のデータ通信で直接アップロードしようと思っている）を見たいのなら、フリッカーフォトグループを訪れていただきたい。あなたが iPhone で撮った写真をそこに追加することも可能だ。RSS フィード のオプションもあるので、RSS リーダーで購読することも同様に可能だ。
私は、iPhone を買うために並ぶ人の列が 20 人になるのか 1 ブロックを回り込むほど長くなるのか予測できないでいる。Apple Store に並ぶ人々の多くは、それに触ってみたいだけであるのに対し、AT&T Store に並ぶ人々は実際に購入する顧客のような気がする。おそらく私は手ぶらで帰って、後日出直すことになるだろう。
文： Jeff Carlson <[email protected]>
訳： 笠原正純<panhead@draconia.jp>
iPhone のリリースが近付くにつれて、Apple は以前には触れていなかった点をまたもう一つ明らかにした。YouTube のビデオを iPhone に直接ダウンロードして再生するという YouTube アプリケーションがそれだ。（以前、同社は iPhone が改良された電池寿命とプラスチックではなくガラスのスクリーンを誇ることを明らかにしていた。2007-06-18 "Apple が iPhone の変更点を公開"参照。）更に、Apple は約束どおり YouTube ビデオの再生を可能にする Apple TV 用アップデートもリリースした。（2007-06-04 "Apple TV に 160 GB ドライブと YouTube ダウンロードが加わる" を参照。）
YouTube（Google が所有している）はそのビデオライブラリを H.264 フォーマットでエンコードしてきた。通常、YouTube はそのコンテンツを Flash で配信しているのだが、Apple TV と iPhone は何らかの方法で H.264 フィードを直接取り込んでいるのだと私は推測している。
ある時、Apple はプレスリリースで、iPhone の Wi-Fi 機能について述べたところで、H.264 ビデオについて YouTube のダウンロードが相当に大きくなると語った。Wi-Fi を使うのなら、それは問題ではない。しかし、携帯電話のデータ通信を使ってダウンロードすると高くつくだろう。Apple も AT&T も iPhone の通話とデータ通信サービスの価格についてはアナウンスしていない。
Apple TV 1.1 update は、UPnP IGD (Internet Gateway Device Standardized Device Control Protocol) がネットワーク上の別の場所からの denial-of-service アタックを引き起こすという、潜在的なセキュリティ上の脆弱性についても改修した。アップデートは独立したダウンロードではなく Apple TV からのみ利用可能だ。デバイスのメインスクリーンから、Settings を選び、Update Software を実行する。現時点では他の機能追加がアップデートに含まれているかどうかは明らかにされていない。
文： Adam C. Engst <[email protected]>
訳： 羽鳥公士郎 <hatori@ousaan.com>
先週の終わり、Apple は Security Update 2007-006 をリリースし、Safariをはじめ多くのウェブ対応 Macintosh アプリケーションが依存しているWebCore と WebKit 両コードのバグに対処した。詳細は重要でないが、どちらの脆弱性も、悪意を持って作られたウェブページを訪れるようにユーザが唆されないかぎり問題にはならない。自分が読んでいるウェブサイトがどのようなものであるのか気を付けるようにというアドバイスを繰り返しておこう。Security Update 2007-006 は Software Update 経由で、あるいはスタンドアロンダウンロードとして入手できる。Mac OS X 10.3.9 用が 2.2 MB、Mac OS X 10.4.9 以降用は PowerPC 版が 2.7 MB、ユニバーサル版が 4.5 MB だ。Safari 3 ベータをインストールしている場合は Software Update にSecurity Update 2007-006 が現れないことに注意しよう。
それはなぜかと言うと、Safari 3 Beta Update 3.0.2 には Security Update 2007-006 の修正点が含まれているからだ。さらに２つのセキュリティ上の問題が対処されており、１つは Windows 版の Safari 3 に特有の問題、もう１つは Macintosh と Windows の両方のベータ版ユーザに影響のある問題だ。また、Safari 3.0.2 は安定性が向上し、Mail、iChat、Dashboard の WebKit サポートが改善されると Apple は述べている（TibBITS スタッフの何人かは、Safari 3 の最初のベータ版が iChat とおかしなやりとりをするせいで、このベータ版をアンインストールする必要に迫られた）。9.5 MB の Safari 3 Beta Update 3.0.2 は Software Update 経由からのみ入手できるが、問題点が修正された Safari ベータを新規にダウンロードしてもよい。
文： Adam C. Engst <[email protected]>
訳： 笠原正純<panhead@draconia.jp>
Ambrosia Software は Snapz Pro X 2.1 をリリースした。これは、人気のある静止画とビデオスクリーンのキャプチャーユーティリティを、Intel ベースの Mac で本来の性能を発揮させるユニバーサルバイナリにするものだ。他に、一般的な性能の向上と、QuickTime compression sessions のサポート、WWDC で現れた Mac OS X 10.5 Leopard beta との互換性、動画キャプチャの圧縮中に "Save Later" を使う（以前にはあった）機能、様々なバグフィックスが加えられている。登録ユーザのアップデートは無料で、11.8 MB のダウンロードだ。Snapz Pro X の新規購入は、静止画のみなら $30 で動画キャプチャ機能を追加するなら $70 になる。
文： Adam C. Engst <[email protected]> 訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
毎週 TidBITS 冒頭近くにある広告部分を注意してご覧になってこられなかった方は、私たちのスポンサーである Small Dog Electronics がかなり大幅な値引きを頻繁に TidBITS 読者のために提供していることにお気付きでないかもしれない。今週は、Small Dog Electronics がさらにもう一歩踏み込んで、青色の 4 GB iPod nano（再生品）に Mophie ケースまで付けて、賞品として提供してくれた。合わせて $136.99 相当の製品だ。幸運が足りずに当選から漏れた応募者にも同じ iPod に Mophie ケースを付けたものが割引価格で提供されるので、ぜひ奮ってDealBITS ページで応募して頂きたい。
［訳注： 応募期間は 11:59 PM PDT, 01-Jul-2007 まで、つまり日本時間で 7 月 2 日（月曜日）の午後 4 時頃までとなっています。］
文： Chris Pepper <[email protected]> 訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
SSL (Secure Sockets Layer) と TLS (Transport Layer Security) は、インターネットを介したコミュニケーション、とりわけウェブブラウジングに、セキュリティを提供するためのシステムだ。具体的には、これらは暗号化を用いることによって機密性（プライバシー）と認証（本人確認）を提供する。
SSL には３つのメジャーなバージョンが存在する。４つ目のバージョンは改名されて、TLS のバージョン 1 となった。SSL と TLS は、 公開鍵による暗号化および復号化と、シンプルな身元識別情報、それと信頼による関係に基づいている。これら３つの要素を組み合わせることにより、SSL/TLS は幅広い種類のインターネットコミュニケーションを保護するに適したものとなっている。
ひょっとしてあなたはフィッシング詐欺とかなりすまし詐欺のようなものが気になっているのかもしれない。（もちろんある程度は、誰もがそういうことを気にしているべきなのだが。）でもこの記事は、オンラインの犯罪者たちからあなたを守る保護のうち、更にもっと重要なものの一つについて皆さんに理解して頂くことを目的としている。ウェブサイトを管理している人たちにとっては、SSL/TLS や証明書などの使い方についての説明が、プライバシーとセキュリティの双方について助けになるだろうし、また自分自身でデジタル証明書を購入するべきか、購入するだけの価値があるかということを判断するためにも役立つかもしれない。証明書というのは、その本質において、あなたのサイトが本物であり、本物の組織によって管理されていることを、信用できる機関に保証してもらえるための電子的保証書なのだ。
SSL/TLS 接続を開設するためには、片方または双方の側が証明書を持っていなければならない。そこには有効期間の開始日と終了日、証明される事業体の名称、それからその書類の有効性を裏付けるためのデジタル「署名」が明記される。これらの識別機能に加えて、証明書はまた、暗号化に使われる「秘密鍵」（詳しくは後述）にも結び付いている。HTTPS コミュニケーション（つまり暗号化されたウェブブラウジングで、URL が“https”で始まっていることで分かる）では、常にサーバが証明書を提供する。クライアント側も証明書を提供することがあるが、クライアントの証明書はまだそれほど一般的には使われていない。
公開鍵暗号化、早わかり -- 通常の（対称な）暗号化は、鍵（パスワード）を使ってテキストを数学的に変換して意味の分からない文字列に変える。その暗号を処理して元のテキストを再現させるためには、同じパスワードだけがあればよい。けれども、このような対称な暗号化では、送信側と受信側の双方がそのパスワードならびに暗号化・復号化アルゴリズムを知っている必要があり、かつそのパスワードを他の誰にも知られないようにしておく必要がある。これではあまりうまくないのは明らかだろう。あなたがコミュニケーションする相手の人あるいは組織をすべて個別に訪問して、その度に新たな秘密のパスワードを作り、そのパスワードをその相手とのみ使用するようにするなんて、現実には不可能だ。あなたが銀行ごと、オンラインベンダーごと、コミュニティーサイトごとにそれぞれそんなやり方で別々の秘密のパスワードを作って追跡しなければならないなんて、とてつもなく困難なことだろう。
それとは対照的に、公開鍵による暗号化（別名「秘密鍵暗号法」とも言う）は、２個の鍵（それぞれ「秘密鍵」と「公開鍵」と言う）を使用するが、そのどちらも他方の反転となれる。言い替えれば、公開鍵で暗号化されたデータはそれに対応する秘密鍵によってのみ復号化され、秘密鍵で暗号化されたデータは対応する公開鍵によってのみ復号化されるのだ。対称な暗号化に慣れた人には奇妙な概念に思えるかもしれないが、この方法は実際非常に有用であることが分かっている。２個の鍵を対にして使うことで、プライバシーと本人確認に関わる多くの問題が解消されるからだ。
秘密鍵を持っていることは、ある意味あなたが本人であることの「証明」ともなる。通常、秘密鍵を作った人だけがその秘密鍵による暗号化や復号化を行なう。（秘密鍵が自分以外の人に知らされることはない。）非常に単純化した例を挙げるなら、Citibank の顧客が自分の口座番号を秘密鍵を使って暗号化して、それを www.citibank.com に送ったとする。もしも Citibank がその人の公開鍵をファイルして持っていてそれをその口座にリンクさせていれば、復号化に成功するということが即ちその口座番号を送ってきた人がその人本人であることを強く保証することになる。秘密鍵を盗み出すことは、紙にインクで書かれた署名を盗み出したり偽造したりするよりもずっと難しいからだ。さらに素晴らしいことに、デジタル署名ならばインターネット上で瞬時に動作できる。
デジタル署名にはたった１つだけ非常に特異な性質がある。一般に秘密というものはあまり頻繁に使われ過ぎると漏れてしまう傾向にあるものだが、デジタル署名については（一般に秘密鍵については）使われれば使われるほど信頼性が築き上げられ、その結果として価値が高まる。公開鍵の用語としては、これを「信用 (trust)」という。秘密鍵は、当初は信用ゼロから始まる。なぜなら、その秘密鍵がある特定の人に対応することを、まだ誰も知らないからだ。でも、その秘密鍵はいくつかの方法で信用を獲得することができる：
現実問題として、口座番号を送るというのは暗号化の良い利用法とは言えない。なぜなら、もしもアタッカーがこの暗号化後の「暗号文」と（送信されたものは傍受されるものと思っていなければならない。もしも私たちのコミュニケーションを誰も盗聴していないと分かっているのだとしたら、そもそも暗号化自体が必要ないのだから！）復号化された「平文」との両方を知ってしまったら、両者の関係を分析することで暗号化がすべて破られてしまう可能性があるからだ。真の暗号化は、たくさんのランダム数字や使い捨てキーなどを使うことで「既知平文」攻撃に対する防御を図ろうとする。
残念ながら、秘密鍵と公開鍵を使った暗号化や復号化のプロセスは、遅い。従来型の単一鍵アルゴリズムよりも遥かに複雑な計算を伴うからだ。そこには、公開鍵暗号の非対称アルゴリズムの土台となる特殊な数学が使われているのだ。多くの公開鍵暗号システム（これには SSL/TLS も含まれる）では、実際に送られるデータそのものには（非対称暗号化よりも高速で効率的な）対称的暗号化が施されている。非対称暗号化は、ごく短時間のみ使われる対称鍵の交換のため専用となる。このような方法の組み合わせのお陰で、１つの鍵で同時に大量のデータが暗号化されることがないために、暗号分析が容易くできないよう対策が施されたことにもなる。対称鍵はほんの短時間のみ使用されて即座に廃棄され、一方非対称鍵の方はユーザーのデータそのものにでなく対称鍵の交換のためだけに使われる。
理想化され単純化された例を１つ考えてみよう。
常に念頭に置いておくべき重要な事実は、いくつでも異なったウェブサイトで全く同じ手順を使っても安全だということだ。使用後に毎回セッション鍵を廃棄しさえすれば、同じ秘密鍵を私のすべてのコミュニケーションで再利用しても何も問題が起こらない。
さきほど述べたように、今の例はあくまでも理想的なものとしてオンラインの銀行口座を開く手順の例を書いてみたに過ぎない。銀行とその顧客は実際には口座を新たに開設する際に公開鍵を交換するわけではなく、その代わり未だにパスワードだけに依存して、また時にはスクラッチ式のパスワードシートとか物理的なパスワード生成器（いわゆるハードトークン、例えば SecurID キーホルダーのようなもの）などの方法に頼っているのが現実だ。将来は、口座の開設に際して公開鍵を交換することが定着して、暗号に基づく強力な本人確認とセキュアなコミュニケーションが提供されるようになるかもしれない。現在でも、多くの銀行は既に銀行同士の間ではこれに類することを行なっているが、まだ顧客との間でそうすることは一般的でない。
でも、公開鍵と秘密鍵の対があればどうやって私の本人確認ができるのだろうか？ 一対の鍵を生成して好きな人物だと言い張ることは誰にでもできるのではないか？ その疑問に答える方法の一つが、証明書だ。証明書というのは、３つの要素を組み合わせている。1) 本人確認、2) 公開鍵、3) 外部の者による保証、の３つだ。現実世界においてこれら３つの要素がどのように組み合わされて鍵を有用なものとしているのか、順々に見て行こう。
誰を信用するか？ -- 公開鍵が実際は単なる大きな数に過ぎないことを念頭に置けば、その公開鍵を一人の人間に、あるいは企業体に、どのようにして結び付けるのかというのが当然の問題となる。例えば私が勝手に証明書を作ってそれがローマ法王のものだと主張することだってできるのだから、何らかのクロスチェックは必要だ。SSL/TLS は、信用ある認証機関を使ってこの問題を処理する。誰か信用ある者の手でその証明書に保証を与えるのだ。どんなウェブブラウザも、"root" SSL/TLS 証明書と呼ばれる信用ある一連の証明書を内蔵していて、その root 証明書によって署名を与えられた証明書はすべて、そのブラウザが信用して扱うようになっている。
それに加えて、こうした証明書を所有する事業体（認証機関 (certificate authority, CA) と呼ばれる）がその信用をさらに別の会社に委任するということもあり得る。つまり「中間的」な証明書が介在して、そこへの署名が信用となってまたさらに別の証明書に署名が施されるという風になる。このような階層による信用を「証明パス (certificate chain)」と呼ぶ。もしもあなたがお持ちのブラウザが既に信用している CA によって（直接または間接に）証明を与えられたウェブサイトのみを訪れているのであれば、あなたはこうしたことを心配する必要はない。けれどももしもあなたがその一線を越えたいのなら、状況はもっと複雑なことになる。
もちろん、信用を確立する方法は CA だけではない。例えば、PGP/GPG（Pretty Good Privacy/GNU Privacy Guard、公開鍵暗号化のための人気あるツール）では「信用の輪 (web of trust)」という概念が使われ、商業的な権威者に頼らずに人々がお互いの公開鍵に署名することを重んじている。
サーファー用の SSL -- 現実世界の用語で言えば、人々が SSL/TLS を使うことには２つの理由がある。プライバシーと、本人確認の保証だ。まず第一に、犯罪者たちが電子的コミュニケーションを覗き見ることを防止するために暗号化が役立つ。ことに、電子メールや PayPal、銀行口座のようなところにアクセスを提供するパスワードが盗まれるのを防止することは重要だ。第二に、SSL/TLS 証明書が、ブラウザのロックアイコンで示されたウェブサイトが正当で信用できるためのかなり良い保証を与えてくれる。
ウェブサイトに機密の必要な情報を入力する人は誰でも、それがクレジットカード番号であろうと、電話番号や自宅の住所、はたまた匿名で不満を言い散らすような場合であってさえ、必ず URL に“https”とあることをチェックすべきだし、さらに証明書が期限切れだとか名前が違っているとか、その他証明書の信用度に疑いを持たせるような警告が出た場合にはそれを本気に受け止めるべきだ。もしもあなたのブラウザがどこかのサイトについてそういう警告を出したならば、どうか その警告の文章を注意深く読んで、どこか別のサイトに行くべきか、またはしっかりと目を開いて注意して進むべきか、慎重に判断していただきたい。
残念ながら、SSL/TLS で保護されたウェブサイトを攻撃するには、実際に暗号を破らずとももっと簡単にできる方法が存在する。例えば、人気のある正当なサイトの名前と混乱するほどよく似た名前のサイト（例えば外国語のアルファベット文字を使えば、見た目には正当な名前とほとんど見分けがつかないようにできるかもしれない）を新たに作ったり、あるいはウェブページにロックアイコンを入れたり、といった方法だ。ブラウザは本来 HTML 表示領域の外側にロックを表示するようになっているので、HTML 領域の _内部_ にあるロックは、おそらく誰かがあなたにそのサイトを信用させようとして組み込んだデザイン要素に過ぎず、あなたのブラウザがこのサイトを信用できると保証しているのではない。ただ、往々にして人々はロックアイコンが間違った場所にあることに気付かず、盲目的にそのサイトを信用してしまうこともあり得る。そういう人たちは、すぐ後になって悲しい目に会うことも多いのだ。
ウェブサイトの SSL/TLS 証明書の詳細が見たければ、そのサイトをウェブブラウザで訪れて（SSL/TLS ウェブサイトの URL は必ず“https://”で始まる）ロックアイコンをクリックすればよい。（ロックアイコンは、Safari では右上隅に表示され、Firefox と Internet Explorer では右下隅に表示される。） 例えば、Apple の https://store.apple.com/ での証明書は“VeriSign Trust Network”が発行して“VeriSign, Inc.”が署名している。一方その VeriSign の証明書は“Class 3 Public Primary Certification Authority”が署名している。いわゆる“Class 3”の root 証明書は今日のブラウザの大多数で信用されている。Mac OS X ではこの証明書をキーチェーンアクセスで見ることができ、これはキーチェーン“X509Anchors”の中にある。（SSL/TLS 証明書は、X.509 デジタル証明書規格に基づいている。） Firefox では、アプリケーションパッケージの内部に一連の X.509 root 証明書が保管されている。Firefox は Apple のキーチェーンを使用しないからだ。Safari や Firefox においては Class 3 証明書が内蔵されているので、例えば https://store.apple.com/ のように Class 3 証明書で保証された SSL/TLS サイトを使う時にユーザーたちはロックアイコンを見るだけで済み、恐ろしげな警告メッセージを見せられることはない。
SSL/TLS はウェブサイトをセキュアにするためだけに使われるのではない。電子メールのコミュニケーションをセキュアにするために暗号化を使うこともでき、SSL/TLS はそれを達成するための手軽な方法の一つでもある。残念ながら、SSL/TLS のサポートは状況によってさまざまで、サーバからサーバへの SMTP 接続が暗号化されることはほとんどない。その一方で、Apple Mail や、Apple の .Mac メールサービス、それに Mac OS X Server はすべて セキュア IMAP のための SSL/TLS をサポートしている。ただし、残念ながら .Mac はウェブメール用には SSL/TLS をサポートしていない。Mail のアカウントで電子メールのチェックに SSL/TLS を使うように設定するには、Preferences を開き、Accounts をクリック、必要なアカウントを選んで、Advanced をクリックし、それから Use SSL をチェックすればよい。あなたのメールサーバがもしも専用の IMAP/SSL または POP/SSL ポートで走っているならば（Mac.com はその例だが）適切なポート番号（IMAP/SSL ならば 993、POP/SSL ならば 995）を入力しておく。送信するメールを暗号化するには、Account Information タブをクリックし、それから下の方の Outgoing Mail Server (SMTP) の下にある Server Settings ボタンをクリックして Use Secure Sockets Layer (SSL) をチェックしておく。SMTP 用に特別のポートが必要な場合は、たぶん 587 でよいだろう。（Mac.com の場合はこれでうまく行く。）
[画像を見る mail-advanced] [画像を見る mail-smtp]
あなたのサイトに証明書を獲得 -- セキュアなウェブサイトを設定するには、まず公開鍵・秘密鍵の対を作らなければならない。あなたの秘密鍵はきちんと秘密に保っておき、決して誰にも見せないようにしておかなければならない。次に、公開鍵の方をあなたの人物確認情報（サイトのドメイン名とオーナーも含む）と組み合わせて、証明書署名要求 (certificate signing request, CSR) というものを作る。この CSR はそれ自体では暗号化に使うことはできないが、CSR に署名するプロセスにおいて X.509 証明書が作り出され、それがサイトを同定するとともにその信用度の主張（すなわち署名）を確認する。それとともに、そのサイトの公開鍵とその秘密鍵（通常こちらは別ファイルに保管される）を結び付けることになる。
ある CA（通常は商業的なセキュリティ会社）が CSR を受け取れば、CA はその CSR を調べて、要求を受理してよいかどうか判断する。正しくフォーマットされているかどうか、そのドメイン名に関する要求をする資格があって財政的にも破綻していない顧客からの要求であるかどうか、そういったことがチェックされる。チェック内容はいろいろな CA によってさまざまだが、その要求がすべてのチェックをパスすれば、CA はそこに追加の情報、例えば発行日と有効期間の終了日（これは古い証明書がいつまでも残ることを防ぐ意味もあるし、また CA が引き続き収入を得られるようにという意味もある）などを織り込んだ上で証明書を作成して、要求者が使っている特定のソフトウェア用にフォーマットしてからその顧客に返すことになる。Mac OS X Server のいろいろなコンポーネント（具体的には内蔵の Apache ウェブサーバ、Cyrus および Postfix メールサーバ、それに Jabber チャットサーバ）はすべて同じフォーマットの証明書を使っており、互いに証明書を共有することができる。当然ながら、証明書はそれに対応する秘密鍵（その CSR と共に作られたもの）がなければ意味がない。その証明書は、その特定の公開鍵のみに基づいたものだからだ。
CA はその証明書の所有者の人物確認を保証する立場にあるのだから、往々にしてその証明書要求の細かな点についてうるさく言ってくる。名前の綴りを間違えただけで証明書の発効は遅れることがあるし、ビジネス上の違った名前で証明書を要求した場合にはさらに厄介なことになりがちだ。
人々は署名付きの証明書を信用することによってウェブサイトを同定して自分たちの機密性を確保しようとするのだから、SSL/TLS キー（つまり秘密の部分）は必ず秘密で安全なところに保っておかなければならない。最も運の良いケースでも、もしもあなたの鍵が壊れてしまったら、あなたは数百ドルを失った上で、新たな CSR と秘密鍵、それから新しい証明書を手にするまでオフラインで我慢しなければならないだろう。でも最悪のケースでは、もしも誰か敵意ある者（例えばクラッカーとか、あるいは FBI のエージェントかもしれないし、ひょっとしたらあなたの離婚した相手かもしれない）があなたの SSL/TLS 証明書の写しと秘密鍵を入手してしまったら、本物のサイトを真似たサイトを作られたり、あるいはセキュアと思っていた自分のサイトへの通信をすべて解読されてしまったりするかもしれない。これこそ、フィッシング詐欺師の夢だ。このような機密のデータをセキュアに保つ方法を定めた U.S. 連邦規格 (FIPS 140) というものがあって、改ざん防止用のハードウェアや複数人物への権限付与などについて定めているが、たいていの人々は自分の秘密鍵をセキュアに保つため再起動後に SSL/TLS サービスを開始する際にパスワードを入力することだけで済ませたり、あるいは単に暗号化もされていない鍵をコンピュータに入れてそのコンピュータを保護することだけで済ませたりしているのが現実だ。後者の場合にはコンピュータを再起動させた後ですらも人間の介入なしにそのまま SSL/TLS サービス（HTTPS ウェブサイトも含む）が再開できてしまう。そもそもあなたが SSL/TLS にあえて踏み込もうとするなら、このことをよく考えておくことが重要だ。そして、これは認証機関にとってもさらにもっと重要なことだと思う。
秘密鍵が盗まれた場合は非常に複雑なことになる。もしもあなたが車の鍵や家の鍵を盗まれたら、それは厄介なことには違いないだろうが、錠前を交換するのは大したことではないだろう。SSL/TLS で錠前を交換に相当するのは、証明書の取り消しをするとともに、鍵の対が使えなくなったと宣言し、他の人たちにそれを使わないようにと通知するまでの作業だ。残念なことに、証明書の取り消しというのはいくつかの理由で極めて難しい問題だ。一つには、証明書の取り消しは証明書の署名と同等に注意深く処理する必要がある。どこかのコンピュータが勝手に Amazon の SSL/TLS 証明書を取り消してしまったら大変なことになるだろう。また、秘密鍵というものは非常に機密のものとして扱われるので、例えばその鍵の唯一の保管場所であるコンピュータが盗まれてしまったらどうするのだろうか？ それから、SSL/TLS はそのデザイン上、時宜を得たかどうかということを考慮せずに、その必要もないという前提で作られているのだが、もしもある証明書が使えなくなったのなら、盗まれた証明書と鍵を使って誰かが詐欺をはたらくことができるようになる前にその取り消しを実行しなければならないことになる。こういった諸々の事情の結果として、確かに取り消しのためのシステムは多数存在しているものの、一般的にあまり使われていないのが現実だ。
認証機関のすべて -- 認証機関の責任は、個々の要求がその証明書に記載されている者から来ていること、その団体がそのドメインの正当な所有権を持っていること、それからその要求者に要求をする権限があること、以上の事実を検証するということだ。その際に何が必要か、またその検証がどのようにしてなされるのかは、いろいろな CA によって大きく異なっている。
CA の数はたくさんあるが、新しい CA を相手にするのは、より定評のあるところを相手にする時に比べて問題が多い。この場合「より定評のある」とは、より多くのブラウザに組み込まれていることを意味している。なぜなら、未知の証明書を持つサイトにブラウザが接続しようとする際、ブラウザはセキュリティが保証できないという恐ろしい警告文を意図的に表示するわけで、自分のウェブサイトを利用してもらう際にそれが最初のユーザー体験になるような事態は誰もが避けたいからだ。ことに、オンラインで商品を販売しようという場合にはなおさらだ。このことは自己署名 (self-signed) の証明書、つまり私的な CA に署名されたもの（例えば大学や会社で内部的に使う場合など）にも、またユーザーの持つ特定のブラウザにまだ組み込まれていない新興の商業的 CA などにも同じように当てはまる。
Internet Explorer 7 で、Microsoft は Extended Validation (EV) つまり高度保証 (High Assurance) の SSL/TLS 証明書という概念を導入した。EV の CSR とウェブサイトにはすべて追加のチェックを加えるという要請を課すことによって、何となく混乱状態に陥ってしまっている CA と CA ポリシーの現状にいくらかの整合性を持ち込もうという試みだ。Mozilla によれば Firefox も EV 証明書をサポートする予定だということで、Safari も今後これに同調する見込みだ。当然ながら、このような証明書は従来のものよりも高価となる。特に CA 各社は EV 証明書を歓迎しているが、これは競争の激化によって下降しつつあった証明書の価格を再び上昇させる機会を提供するからだ。
価格は、いろいろな認証機関によって幅広く異なっている。VeriSign は最大大手の一つで価格も最も高い。一年間有効の 128-bit 証明書が $1,000、EV 付きならば $1,500 だ。Thawte が VeriSign よりも安い価格を提示して同社の市場シェアを脅かした時、VeriSign は Thawte を買収し、より安価な証明書のために Thawte のブランド名だけは残した。Thawte の価格は一年間の 128-bit 証明書が $700 と $900（それぞれ EV 無しと EV 付き）となっているが、Thawte 証明書の方がインストールの手順が難しい。なぜなら、中間的な証明書も合わせてインストールしなければならないからだ。どうやらこれは、より安価な Thawte 証明書が VeriSign ブランドの証明書より機能的になることを防ぎたいという VeriSign による工作のようだ。最近になって、GeoTrust がやはり VeriSign の人気を脅かして一年間の 128-bit 証明書に $180 という値札を付けてきた時、VeriSign はまた同じ大技を繰り出して GeoTrust を買収し、VeriSign の EV 証明書が価格の面で大きく足をすくわれるのを防いだ。ただし、もっと安価な選択肢も存在している。例えばRapidSSL の価格はたった $62 だ。
証明書の価格は非常に高価なので、長期間継続の証明書や多数個の同時購入などを対象にいろいろな CA がさまざまな割引価格を提示している。また、継続更新の価格は一般的に新規の証明書よりも安い。ほとんどの CA では良心的に有効期限が切れる前に証明書の更新するよう（また特別価格で事前に支払うよう）ユーザーに知らせてくれるが、一般的に気前良く未使用の期間を更新後の証明書に加算してくれるので、早めに更新しても一切損にはならない。ただし更新が遅れると酷いことになるかもしれない。ウェブサイトを訪れた人すべてに、期限切れとなった証明書を信用するかどうかという警告が出るからだ。そうした問題を避けるためにも、証明書の有効期間の終了日は忘れずにカレンダーに記入しておこう。
どんな CA も、CSR に署名を加えて信用ある証明書を作るという基本的サービスについては同じことを提供しているが、それ以外にいろいろと CA によって差のある点がある。例えば CA の評判、証明手続きの複雑さ、証明書のインストールや使用における手軽さ、証明されたサイトにユーザーがアクセスする際の便利さ、それから CA のポリシーにも違いがあるだろう。価格の違いを正当化するために、多くの CA では自分が証明を与えた証明書（従ってそれに対応するウェブサイト）の整合性を保証するサービスを提供している。例えば VeriSign の Secured Seal プログラムもその一つだ。
では、あなたはどんな証明書を使うべきか？ 公開の電子商取引 (e-commerce) サイトや、その他非常に慎重を要する情報を扱うサイトならば、128-bit の商用証明書を使うべきだ。その中でどの証明書を選ぶかはそのサイト自体の内容によるが、その際、主な違いは訪問者たちの信頼度（EV 証明書かどうか、定評ある root キーかどうかといった点）と管理者にとっての扱いやすさに関したことのみであって、実際の署名の処理に関しては暗号学的にどの CA でも同等だということは念頭に置いておかなければならない。忘れてはならないのは、公開鍵と秘密鍵を提供するのがあなた自身だということだ。認証機関は証明書の所有者の検証はするが、暗号レベルのことには一切介入しない。どんな種類の 128-bit SSL/TLS 証明書も暗号学的には同等だ。ただし、ブラウザによって EV サイトの扱い方は異なる。
商業的認証機関に代わるもの -- あなたの証明書に署名してもらうだけのために CA に毎年 $1,500 も払う代わりに、別の方法もある。まず第一に、あなたが新しい CSR を作って、それを使ってあなた自身が自分でそれに署名するという方法がある。このような自己署名 (self-signed) 証明書には第三者による信憑性の保証が欠落しているが、暗号化自体は適切に署名を受けた「本物の」証明書と全く同じものが提供される。１つか２つのホスト名であって（証明書はホスト名に対応している）しかも顧客の信頼度がそれほど重要でないサイトならば、自己署名の証明書も良い選択肢となる。個人的なサイトで、何百ドルも払うのはお金の浪費だと思えるところならば、これこそが完璧な方法だ。たとえ訪問者たちに SSL/TLS アクセスを提供しないサイトであっても、管理者アクセス（ブログのアップロードや統計情報のオンラインチェックなど）をセキュアにするために自己署名の証明書を使うのは完璧に適した方法と言える。
あなたが多数のサイトを持っている場合、例えば大学や会社のようなところでは、自分自身の CA を作って、それを使って個々の証明書に署名を与え、一切の CA 料金を払わずに済ませるのも良い方法となる。この方法の欠点は、当然ながらあなたのサイトを訪問した人のブラウザにはセキュリティの警告が出るわけで、訪問者たちがその警告に対処してあなたの私的な CA の証明書に手動で信用を与える必要が生じる点だ。私的な CA に対処する実際の手順はブラウザによってさまざまだが、犯罪者が CA となることも等しく簡単にできるのだから、いくつかのブラウザでは新たな私的 CA を信用する手順が意図的に難しいものとなっている。しかしながら、ユーザーがあなたの CA に信用を与えるのはたった一回でよく、一度信用を与えた後は信用できない証明書という警告はもう現われない。（ただしもちろんコンピュータやブラウザを別のものに切り替えれば話は別で、その場合はもう一度その手順を繰り返すことになる。）
もしもあなたがこの方法を選ぶならば、何よりもまずあなたの root 証明書の鍵について電子的・物理的の両面でセキュリティが万全かどうかを真剣に考えておくべきだ。バックアップについて、スタッフの異動についても考慮すべきだ。幸い、CA となる手順は証明書に自己署名する手順に比べてそれほど技術的に複雑なものでもない。ただし、自己署名証明書に信用を与える手順がブラウザによっては非常にシンプルであるのに比べて、ユーザーたちを手伝って root 証明書をインストールさせる手順は意図的にずっと複雑になっている。
あなた自身の私的な CA を構築するのに費用は一切かからない。無料の OpenSSL がすべてをやってくれる。ただ、その手順を学ぶための時間を投資して、root キーを保護するためのセキュリティを図る必要が生じるだけだ。そのセキュリティこそが、子供となるすべての証明書のセキュリティのための要となるからだ。この記事でその手順の詳細を説明することはできないが、手始めに読むべきオンラインのリソースはいくつかある。また、その手順はかなり効果的に自動化できて効率化も可能な性質のものだ。
OpenSSL には、これらの作業を自動化するための Perl スクリプト、CA.pl が付属している。これは効果的に働くが、それでも完璧ではない。私の場合はこの CA.pl にも、手動の作業にも満足できなかったので、自分でシンプルなスクリプトを２つ、作ってみた。新しい証明書を作って署名を与えるための cert.command スクリプトと、既存の証明書に署名を与える sign.command スクリプトだ。どちらのスクリプトも、使う際にはホスト名を２回入力し、root キー用のパス文字列を入力し、Return キーを何回も何回も押す、それだけであとはすべて自動的に完了するようになっている。
私の判断の限りでは安全 -- SSL/TLS は、決してインターネット上でウェブや電子メールにセキュリティを与えるための唯一の方法ではない。けれども、これは現実に毎日毎日何百万人という人々のために忠実な従僕の働きを続けていて、クレジットカード番号や、オンラインの銀行セッション、電子メール、その他を保護している。普通のユーザーにとっては、ロックアイコンが見えていて URL の先頭に“https”とあるならば、それは SSL/TLS が自分たちを守ってくれているという安心感の印だ。そして管理者たちにとっては、SSL/TLS の背後にあるテクノロジーが暗号学という神秘の領域（ソフトウェアの世界でロケット科学に相当するもの）に属することは疑いないものの、実際にこれを実装するコストと労力について言えば、ウェブサーバを運営する誰もが十分に手の届く範囲にあると言える。
[Chris Pepper はニューヨーク市内で Unix システム管理者をしている。彼の仕事で使うさまざまの Unix システムのため、Mac OS X がかくも素晴らしい管理用ワークステーションとなってくれていることに、彼は今でも愉快な驚きの気持ちを持ち続けている。Chris には不可視の署名があって、そこに曰く「ウェブの編集は、一度に１ページずつ」とある。今回の記事で扱ったいろいろの問題点についてさんざん頭を壁に打ちつけたあげく、Chris は OpenSSL の CA.pl スクリプト（Mac OS X に付属のもの）を SSL/TLS 証明書の管理のために使う方法について もう一つ記事を書き上げた。また、彼は私的な CA を運営するために便利に使える、ダブルクリックで動くスクリプトも２つ開発してくれた。]
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
iPhone への需要 -- 2008 年の末までに一千万台の iPhone を売ろうという Apple の目標は、はたして現実的な数字なのか？ それとも、これは Apple が目標を達成できるようにと意図的に低く設定された数字だろうか？ それと、他の諸国でも iPhone が出回るようになるのはいつか？(13 メッセージ)
1Passwd がパスワードの苦痛を緩和 -- Joe Kissell が 1Passwd について書いた記事への反応として、読者たちが Palm 同期について議論する。(8 メッセージ)
Loki、Google Street Views 等を巡る考察 -- こうした場所認識アプリケーションたちは、あなたの個人的プライバシーの一線を越えていないか？(2 メッセージ)
Eudora に代わるもの -- Mail がよいか、Thunderbird か？ そもそも、受信した時に特定のメッセージが新しいウィンドウで開けるという Eudora の機能は、他のアプリケーションで簡単に再現できるのか？(7 メッセージ)
YouTube が iPhone と Apple TV にやってきた ルータで UPnP をオンにしていない場合、Apple TV に問題が起こったことのある人はいませんか？ (1 メッセージ)
iPhone を想像しよう ある読者が、未来の買い物の様子を想像してみる。ショッピングの最中に、カスタムデータが iPhone にどんどん流し込まれるというのはどうだろうか。 (2_メッセージ)
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2007 TidBITS: 再使用は Creative Commons ライセンスによります。
, 
日本語版最終更新：2007年 7月 2日 月曜日, S. HOSOKAWA
Take Control 電子ブック日本語版好評発売中 
