注: 当初の回答は非常に急いで書いたものですが、その後、この質問/回答がかなり人気になったため、少し拡張してより正確なものにしました。

TLS 機能

「SSL」は、このプロトコルを指すのに最もよく使われる名前ですが、SSL は具体的には、90 年代半ばに Netscape が設計した独自のプロトコルを指します。「TLS」は SSL に基づく IETF 標準なので、回答では TLS を使用します。今日では、Web 上のほぼすべての安全な接続は、SSL ではなく TLS を使用している可能性が高いです。

TLS にはいくつかの機能があります。

1. アプリケーション層のデータを暗号化します。(この場合、アプリケーション層プロトコルは HTTP です。)
2. サーバーをクライアントに対して認証します。
3. クライアントをサーバーに認証します。

1 と 2 は非常に一般的です。3 はあまり一般的ではありません。2 に焦点を当てているようなので、その部分について説明します。

認証

サーバーは証明書を使用してクライアントに対して認証を行います。証明書とは、Webサイトに関する情報を含むデータの塊[1]です。

• ドメイン名
• 公開鍵
• それを所有する会社
• 発行された時期
• 有効期限が切れると
• 誰が発行したのか
• 等。

証明書に含まれる公開鍵を使用してメッセージを暗号化することで機密性（上記 1）を実現できます。このメッセージは対応する秘密鍵でのみ復号化でき、その秘密鍵はサーバー上に安全に保管されます。[2] 後で混乱しないように、この鍵ペアを KP1 と呼びましょう。証明書のドメイン名がアクセスしているサイトと一致していることを確認することもできます（上記 2）。

しかし、もし攻撃者がサーバーとの間で送受信されるパケットを変更できたとしたら、そしてその攻撃者が提示された証明書を変更し、独自の公開鍵を挿入したり、その他の重要な詳細を変更したりしたらどうなるでしょうか? そうなると、攻撃者は安全に暗号化されていると思っていたメッセージを傍受して変更することができます。

この攻撃を防ぐために、証明書は、対応する公開鍵を持つ人なら誰でも署名を検証できるような方法で、他人の秘密鍵によって暗号的に署名されます。これらがサーバーが使用している鍵と同じではないことを明確にするために、この鍵ペアを KP2 と呼びます。

認証局

では、KP2 を作成したのは誰ですか? 証明書に署名したのは誰ですか?

少し単純化すると、証明する機関KP2を作成し、他の組織の証明書に署名するために秘密鍵を使用するサービスを販売しています。たとえば、証明書を作成し、Verisignなどの会社に支払いをして、秘密鍵で署名してもらいます。[3] Verisign以外の誰もこの秘密鍵にアクセスできないため、誰もこの署名を偽造することはできません。

そして、その署名を検証するために、KP2 の公開鍵を個人的に入手するにはどうすればよいでしょうか?

証明書に公開鍵を入れることができることはすでに説明しました。コンピューター科学者は再帰が大好きです。では、KP2 公開鍵を証明書に入れて配布するのはどうでしょうか。最初は少し奇妙に思えますが、実際にはまさにそのように機能します。Verisign の例を続けると、Verisign は、Verisign が誰であるか、どのような種類のものに署名できるか (他の証明書)、および公開鍵に関する情報を含む証明書を作成します。

Verisign 証明書のコピーがあれば、それを使用して、アクセスしたい Web サイトのサーバー証明書の署名を検証できます。簡単ですよね?!

まあ、そんなに早くはいかない。Verisignの証明書を取得する必要があった。どこか誰かが Verisign 証明書を偽装し、そこに自分の公開鍵を入れたらどうなるでしょうか。そうすると、サーバーの証明書の署名を偽造することができ、最初の状態、つまり中間者攻撃に戻ってしまいます。

証明書チェーン

再帰的に考え続けると、もちろん 3 番目の証明書と 3 番目のキー ペア (KP3) を導入し、それを使用して Verisign 証明書に署名することができます。これを証明書チェーンと呼びます。チェーン内の各証明書は、次の証明書を検証するために使用されます。この再帰的なアプローチは、最後までタートル/証明書だけであることがすでにおわかりいただけたと思います。どこで止まるのでしょうか。

無限の数の証明書を作成することはできないので、証明書チェーンは当然停止する必要がある。どこかこれは、チェーンに証明書を含めることによって行われます。自己署名。

頭が爆発して脳の破片が落ちてくるので、それを拾い集めている間にちょっと休憩します。自筆サイン？！

はい、証明書チェーンの最後 (つまり「ルート」) には、独自のキーペアを使用して署名する証明書があります。これにより、無限再帰の問題は解消されますが、認証の問題は解決されません。誰でも、何でも記載した自己署名証明書を作成できます。これは、私が、政治学、理論物理学、応用物理学の 3 つの専攻を修めたと書かれた偽のプリンストン大学の卒業証書を作成し、最後に自分の名前を署名できるのと同じです。

この問題の[あまり面白くない]解決策は、明示的に信頼する自己署名証明書のセットを選択することです。たとえば、「私は信頼この Verisign 自己署名証明書。"

明示的な信頼を確立することで、証明書チェーン全体を検証できます。チェーン内の証明書の数に関係なく、ルートに至るまで各署名を検証できます。ルートに到達したら、そのルート証明書が明示的に信頼する証明書かどうかを確認できます。そうであれば、チェーン全体を信頼できます。

与えられた信頼

TLSの認証では、与えられた信頼自動車整備士を雇いたい場合、適当に見つけた整備士を信用するとは限りません。しかし、友人が特定の整備士を保証してくれるかもしれません。友人を信用しているのだから、その整備士を信用できるのです。

コンピュータを購入したりブラウザをダウンロードしたりすると、明示的に信頼されている数百のルート証明書が付属しています。[4] これらの証明書を所有および運用する企業は、証明書に署名することで、その信頼を他の組織に付与することができます。

これは完璧なシステムからは程遠いものです。CA が誤って証明書を発行する場合もあります。その場合、証明書を取り消す必要があります。発行された証明書は常に暗号的に正しいため、取り消しは難しい作業です。以前有効だった証明書のうち、取り消された証明書を見つけるには、帯域外プロトコルが必要です。実際には、これらのプロトコルの一部はあまり安全ではなく、多くのブラウザはいずれにしてもそれらをチェックしません。

時にはCA全体が侵害されることもあります。例えば、Verisignに侵入してルート署名キーを盗んだ場合、どれでも世界で唯一の証明書です。これは Verisign の顧客だけに影響するのではないことに注意してください。私の証明書が Thawte (Verisign の競合企業) によって署名されていたとしても、それは問題ではありません。私の証明書は、Verisign の侵害された署名キーを使用して偽造される可能性があります。

これは単なる理論上の話ではありません。実際に起こったことです。DigiNotarはハッキングされたことで有名だそしてその後倒産した。コモドもハッキングされたしかし、不可解なことに、彼らは今日まで営業を続けています。

CA が直接侵害されない場合でも、このシステムには他の脅威が存在します。たとえば、政府が法的強制力を使って CA に偽造証明書への署名を強要することがあります。雇用主が従業員のコンピュータに独自の CA 証明書をインストールすることもあります。こうしたさまざまなケースでは、「安全」であると期待されるトラフィックが、実際にはその証明書を管理する組織に完全に表示/変更可能になっています。

いくつかの代替案が提案されており、その中には収束、タック、 そしてデーン。

脚注

[1] TLS証明書データは、X.509 標準X.509は以下に基づいています1.1 言語（「抽象構文記法＃1」）つまり、ないバイナリデータ形式です。したがって、X.509はエンコードされたバイナリ形式に変換します。DER と PEMこれらは私が知る限り最も一般的な 2 つのエンコーディングです。

[2] 実際には、プロトコルは対称暗号に切り替わりますが、これはあなたの質問とは関係のない詳細です。

[3] おそらく、CA は証明書に署名する前に、実際にあなたが誰であるかを検証します。もし検証しなかったら、google.com の証明書を作成して CA に署名を依頼するだけです。その証明書があれば、google.com への「安全な」接続を中間者攻撃で阻止できます。したがって、検証手順は CA の運用において非常に重要な要素です。残念ながら、世界中の何百もの CA でこの検証プロセスがどの程度厳格であるかは明らかではありません。

[4] Mozillaの信頼できる CA のリスト。