インフォメーション・センター

サーバー認証

セキュア接続を定義すると、Z and I Emulator for Web の「セキュリティー」タブで次の 3 つのオプションが使用できます。「セキュリティーを有効にする」、「セキュリティー・プロトコル」、および「証明書の送信」(クライアント認証)。 

セキュリティーを有効にする

サーバーおよびクライアント認証を使用可能にするには、 「セキュリティーを使用可能にする」をクリックします。

セキュリティー・プロトコル

「セキュリティー・プロトコル」は、クライアント認証およびサーバー認証に使用される方式を指定します。以下のいずれかのオプションを選択します。

TLS
トランスポート層セキュリティー (TLS) プロトコル。TLS オプションでは、クライアントとサーバー間の標準 TLS 接続が作成されます。クライアントは、ハンドシェイクと呼ばれる通信を行ってサーバーにアクセスします。ハンドシェイクを使用すると、クライアントとサーバーは相互に認証し、セッション中に使用される暗号化の種類を指定できます。クライアントとサーバー間でセッション中に交換されるデータはすべて暗号化されるので、第三者からは判読できません。また、プロトコルにはメッセージ整合性チェックが含まれており、送信データの整合性と信頼性が確保されます。
SSL
Secure Sockets Layer (SSL) プロトコル。SSL オプションでは、クライアントとサーバー間の標準 SSL 接続が作成されます。クライアントはサーバーにアクセスし、そのサーバーに有効な証明書があることを確認します。このタイプの接続では、クライアントとサーバー間で交換されるすべてのデータが暗号化されるようになり、インターネット上の第三者が読み取ることができなくなります。

サーバー認証 (SSL)

SSL が有効になっているということだけでは、クライアントが正しいサーバーと通信していることが保証されません。このプロトコルに内包されるリスクを説明するために、次のシナリオを考えます。2 台のサーバー、Server1 (zie.S1.com) と Server2 (zie.S2.com) と、1 台のクライアント Client があるとします。両方のサーバーとも、クライアントが信任する CA から有効な証明書を得ています。クライアントは Server1 とのセキュア・セッションを望み、Server2 はその通信を盗聴しようとしており、 しかも物理的にはそれが可能な場所に位置しています。シナリオは次のように進みます。

クライアントは SSL セッションの要求を送信します クライアントが SSL セッションの要求を Server1 に送ります。その要求 (および後続のすべてのトラフィック) は、実際は Server2 を介して進みます。Server2 は、クライアントの要求を Server1 に転送する代わりに、 その独自の証明書をクライアントに送ることによって、要求に直接応答します。
クライアントは証明書を受け取りトラステッド CA のリストを調べます クライアントは Server2 の証明書を受信し、それを信任 CA のリストに対照して検査します。Server2 の証明書は Server1 の証明書と同じ CA によって署名されていますから、 クライアントはその証明書を受け入れ、Server2 とのセキュア・セッションを作成します。
サーバーはその固有の SSL セッションを要求して作成します クライアントとのセキュア・セッションを完了させると、 Server2 は Server1 との独自の SSL セッションを要求して、作成します。この時点から、クライアントは暗号化された情報を Server2 に送信します。Server2 はその情報の暗号化を解き、再度暗号化し、それを Server1 に送信します。反対方向の情報の流れでも、同じことを行います。結果は、すべてのデータは、 インターネット上を流れる時には暗号化されますが、Server2 はその情報を読み取ることができるばかりでなく、 それを変更することさえできるということになります。

こうした危険を避けるために、サーバー認証 (SSL) オプションが提供されています。このオプションが使用されると、クライアントは、サーバーの証明書が信頼できることを確認した後で、証明書中のインターネット名がサーバーのインターネット名と一致しているかを検査します。一致する場合には、SSL 折衝が続きます。一致しなければ、接続は即時に終了します。

この検査を有効とし、肯定結果を得るには、2 つの条件が満たされなければなりません。

  1. クライアントがローカル・インストールでなければなりません。http を使用してダウンロードされたクライアントは、サーバー認証として信頼することはできません。サーバー認証がきわめて重要である場合には、ローカル・インストールのクライアントだけを使用するか、Web サーバー上で https を使用してください。
  2. サーバー証明書中の共通名がインターネット名と一致しなければなりません。

サーバー認証 (SSL) が使用可能であると、セキュリティーのシナリオは次のように進みます。

クライアントは SSL セッションの要求を送信します 1. クライアントが SSL セッションの要求を Server1 に送ります。その要求 (および後続のすべてのトラフィック) は、実際は Server2 を介して進みます。Server2 は、クライアントの要求を Server1 に転送する代わりに、 その独自の証明書をクライアントに送ることによって、クライアントの要求に直接応答します。
クライアントは証明書を受け取りトラステッド CA のリストを調べます 2. クライアントは Server2 の証明書を受信し、それを信任 CA のリスト に対照して検査します。Server2 の証明書は Server1 の証明書と同じ CA によって署名されていますから、 クライアントはその証明書を受け入れ、Server2 とのセキュア・セッションを作成します。
クライアントは証明書中のインターネット名とサーバーの名前を比較します 3. セキュア・セッションが完了した後で、かつ実際のデータが送信または受信される前に、クライアントは、受信した証明書中のインターネット名 (zie.S2.com) を接続したいサーバーの名前 (zie.S1.com) と比較します。両者が一致しないので、クライアントは、その接続が続けられないことを認識して、それを切断します。

関連トピック