157

SSL はどのように機能しますか?

証明書はクライアント (またはブラウザー?) とサーバー (または Web サーバー?) のどこにインストールされていますか?

ブラウザーに URL を入力してサーバーからページを取得すると、信頼/暗号化/認証プロセスはどのように開始されますか?

HTTPS プロトコルはどのように証明書を認識しますか? すべての信頼/暗号化/認証作業を行うのは証明書であるのに、HTTP が証明書を処理できないのはなぜですか?

4

4 に答える 4

160

注: 元の回答は非常に急いで書きましたが、それ以来、これはかなり人気のある質問/回答になったため、少し拡張してより正確にしました。

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 証明書のコピーがあれば、それを使用して、アクセスしたい Web サイトのサーバー証明書の署名を検証できます。簡単ですよね？

まあ、それほど速くはありません。Verisign 証明書をどこかから取得する必要がありました。誰かが Verisign 証明書を偽装し、そこに自分の公開鍵を入れたらどうなるでしょうか? その後、彼らはサーバーの証明書の署名を偽造することができ、私たちは開始したところに戻ってきます: 中間者攻撃.

証明書チェーン

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

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

爆発している頭から脳の破片を拾っている間、少し休憩します。自己署名？！

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

この問題に対する [やや刺激的でない] 解決策は、明示的に信頼する自己署名証明書のセットを選択することです。たとえば、「この Verisign 自己署名証明書を信頼します」と言うかもしれません。

明示的な信頼が確立されたので、証明書チェーン全体を検証できるようになりました。チェーンに証明書がいくつあっても、各署名をルートに至るまで検証できます。ルートに到達すると、そのルート証明書が明示的に信頼されているかどうかを確認できます。もしそうなら、チェーン全体を信頼できます。

授与される信託

TLS での認証は、付与された信頼のシステムを使用します。自動車整備士を雇いたい場合、ランダムに見つけた整備士は信用できないかもしれません。しかし、私の友人が特定のメカニックを保証するかもしれません. 私は友人を信頼しているので、そのメカニックを信頼できます。

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

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

CA 全体が危険にさらされることもあります。たとえば、Verisign に侵入してルート署名キーを盗んだ場合、世界中のあらゆる証明書を偽装できます。これは Verisign の顧客だけに影響するわけではないことに注意してください。たとえ私の証明書が Thawte (Verisign の競合相手) によって署名されていたとしても、それは問題ではありません。Verisign の侵害された署名キーを使用して、証明書を偽造することができます。

これは単なる理論上の話ではありません。それは野生で起こりました。DigiNotar がハッキングされ、その後倒産したことは有名です。Comodo もハッキングされましたが、不可解なことに、今日まで営業を続けています。

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

Convergence、TACK、DANEなど、いくつかの代替案が提案されています。

文末脚注

[1] TLS 証明書データは、 X.509 標準に従ってフォーマットされます。X.509 はASN.1 (「Abstract Syntax Notation #1」) に基づいているため、バイナリ データ形式ではありません。したがって、X.509 はバイナリ形式にエンコードする必要があります。DER と PEMは、私が知っている最も一般的な 2 つのエンコーディングです。

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

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

[4] Mozilla の信頼できる CA のリストを参照してください。

于 2011-09-11T22:26:58.123 に答える
4

プロセスについて簡単に説明する小さなブログ投稿を書きました。お気軽にご覧ください。

SSL ハンドシェイク

同じものからの小さなスニペットは次のとおりです。

「クライアントはHTTPS経由でサーバーにリクエストを送信します。サーバーはSSL証明書と公開鍵のコピーを送信します。ローカルの信頼できるCAストアでサーバーの身元を確認した後、クライアントは秘密のセッション鍵を生成し、サーバーの公開鍵を使用して暗号化します。サーバーは秘密鍵を使用して秘密のセッション鍵を復号化し、確認をクライアントに送信します。安全なチャネルが確立されました。」

于 2016-01-11T10:28:38.497 に答える