SSL サーバー認証

SSL サーバー認証では、通信相手のサイトが表明する識別情報が適正であることを検査します。 認証では、公開鍵暗号方式の標準的な手法を使用して、サーバーの識別情報を確認します。これにより、サーバーの証明書とパブリック ID が有効であること、およびクライアント側にあるトラステッド CA のリストに記載されている認証局によってその証明書と ID が発行されたことが保証されます。

セキュアな環境を確立するには、認証局によって発行された認証証明書を所有する「信頼できる」サーバーと通信することが重要です。 認証証明書は、公開鍵を秘密鍵所有者の識別情報にバインドする、デジタル署名された文書です。 認証は、接続時に実行され、アプリケーションまたはアプリケーション・プロトコルに依存しません。 SSL では、認証は証明書の交換によって実行されます。これらの証明書は、X.509 ITU-T 標準 に記述されているフォーマットを持つデータのブロックです。 X.509 証明書は、認証局によって発行およびデジタル署名されます。

ただし、SSL を使用しても、クライアントが適切なサーバーと通信するという保証はありません。 以下のシナリオを考えます。ここでは、「Server1」と「Server2」は両方とも、クライアント (「Client」) が信頼する CA によって発行された有効な証明書を持っています。 Client は Server1 とのセキュア・セッションを確立しようとしますが、Server2 はその通信を傍受しようとしていて、物理的にそれが可能な場所に位置しています。
  1. Client が SSL セッションの要求を Server1 に送信します。 しかし、その要求 (および後続のすべてのトラフィック) は、実際には Server2 を経由します。 Client の要求を Server1 に転送する代わりに、Server2 は、所有している証明書を Client に送信することにより、要求に直接応答します。
  2. Client は、Server2 の証明書を受信し、トラステッド CA のリストと証明書を照合して検査します。 Server2 の証明書は、Server1 の証明書と同じ CA によって署名されているため、Client は証明書を受け入れ、Server2 とのセキュア・セッションを作成します。
  3. Client とのセキュア・セッションが作成された後で、Server2 は、Server1 との別個の SSL セッションを要求および作成します。 この時点から、Client は、暗号化された情報を Server2 に送信します。 Server2 は、その情報を暗号化解除し、再度暗号化し、Server1 に送信します。 Server2 は、反対方向の情報フローも同様に処理します。 その結果、インターネット経由のフローですべてのデータが暗号化されているにもかかわらず、Server2 は情報を読み取ることができ、それを変更することもできます。

SSL サーバー認証は、このような結果を防止できるように設計されています。 サーバー認証が使用可能である場合、クライアントは、サーバーの証明書が信頼できることを確認した後で、証明書内のインターネット名がサーバーのインターネット名と一致するかどうかを検査します。 一致する場合は、SSL ネゴシエーションが続行されます。 一致しない場合は、接続が終了します。

サーバー認証が使用可能である場合、上記のセキュリティー・シナリオの手順は、以下のようになります。
  1. Client が SSL セッションの要求を Server1 に送信します。 その要求 (および後続のすべてのトラフィック) は、実際には Server2 を経由します。 Client の要求を Server1 に転送する代わりに、Server2 は、所有している証明書を Client に送信することにより、Client の要求に直接応答します。
  2. Client は、Server2 の証明書を受信し、トラステッド CA のリストと証明書を照合して検査します。 Server2 の証明書は、Server1 の証明書と同じ CA によって署名されているため、Client は証明書を受け入れ、Server2 とのセキュア・セッションを作成します。
  3. セキュア・セッションが作成された後で、実際のデータが送受信される前に、Client は、受信した証明書内のインターネット名を、通信したいサーバーの名前と比較します。 名前が一致しないため、Client は、接続を続行するべきではないと判断し、接続を切断します。