SSL 入門

この記事は翻訳作業中です。

はじめに

このドキュメントは、 Secure Sockets Layer (SSL) プロトコルの紹介です。 SSLは、World Wide Web上での信頼と暗号化されたクライアント・サーバのコミュニケーションのために一般的に公認されています。

Transport Layer Security (TLS) と呼ばれる新しい Internet Engineering Task Force (IETF) 標準プロトコル は SSL を基にしています。このプロトコルの詳細は、Request for Comments (RFC): 2246, The TLS Protocol Version 1.0 として利用できます。いくつかの Red Hat 製品では既に TLS がサポートされています。 他のほとんどの Red Hat 製品も、将来のバージョンでプロトコルのサポートを計画しています。

このドキュメントは、おもに Red Hat サーバ製品の管理者向けに意図していましたが、この情報は SSL をサポートするアプリケーションの開発者にも役立つものが含まれています。ドキュメントは、あなたが "公開鍵暗号入門" にまとめられているような公開鍵暗号の基本概念に詳しいと仮定しています。

SSL プロトコル

伝送制御プロトコル/インターネットプロトコル (TCP/IP) は、インターネット上のデータのトランスポートとルーティングを規定しています。ハイパーテキスト・トランスポート・プロトコル (HTTP)、ライトウェイト・ディレクトリ・アクセス・プロトコル (LDAP)、インターネット・メッセージング・アクセス・プロトコル (IMAP) などの他のプロトコルは、Web ページの表示や電子メール・サーバの実行などの典型的なアプリケーション・タスクをサポートするために TCP/IP を使用するという意味で、TCP/IP の「上」で実行されます。

SSL プロトコルは、TCP/IP の上に、HTTP や IMAP などの高レベルのプロトコルの下で動作します。上位プロトコルの代わりに TCP/IP を使用し、その過程で SSL 対応のサーバが SSL 対応のクライアントに自分自身を認証し、クライアントがサーバに自分自身を認証し、両方のマシンが暗号化された接続を確立することを可能にします。

これらの機能は、インターネットやその他の TCP/IP ネットワーク上の通信に関する基本的な問題に対処します。

  • SSL サーバ認証は、ユーザがサーバの身元を確認することを可能にします。SSL 対応のクライアントソフトウェアは、公開鍵暗号の標準的な技術を使用して、サーバの証明書と公開 ID が有効であり、クライアントの信頼できる CA のリストに記載されている証明書局 (CA) によって発行されたものであることを確認することができます。例えば、ユーザがネットワーク経由でクレジットカード番号を送信していて、受信側のサーバの身元を確認したい場合などには、この確認が重要になるかもしれません
  • SSL クライアント認証では、サーバがユーザの身元を確認することができます。サーバ認証に使用されるのと同じ技術を使用して、SSL 対応のサーバソフトウェアは、クライアントの証明書と公開 ID が有効で、サーバの信頼できる CA のリストにリストされている証明書局 (CA) によって発行されたものであることを確認することができます。この確認は、例えば銀行が顧客に機密の金融情報を送信していて、受信者の身元を確認したい場合に重要になるかもしれません
  • 暗号化された SSL 接続では、クライアントとサーバ間で送信されるすべての情報が送信側のソフトウェアによって暗号化され、受信側のソフトウェアによって復号化される必要があるため、高度な機密性を提供します。機密性は、プライベートな取引を行う上で、双方にとって重要です。さらに、暗号化された SSL 接続を介して送信されるすべてのデータは、改ざんを検出するためのメカニズムで保護されており、転送中にデータが改ざんされたかどうかを自動的に判断します

SSL プロトコルには、SSL レコードプロトコルと SSL ハンドシェイクプロトコルの2つのサブプロトコルがあります。SSL レコードプロトコルはデータを送信するためのフォーマットを定義します。SSL ハンドシェイクプロトコルでは、SSL レコードプロトコルを使用して、SSL 対応サーバと SSL 対応クライアントが最初に SSL 接続を確立するときに、一連のメッセージを交換します。このメッセージの交換は、以下の動作を容易にするように設計されています。

  • サーバをクライアントに認証します
  • クライアントとサーバがサポートしている暗号アルゴリズム (暗号化方式) を選択できるようにします
  • オプションで、クライアントをサーバに認証します
  • 公開鍵暗号化技術を使用して共有シークレットを生成します
  • 暗号化された SSL 接続を確立します

ハンドシェイク処理の詳細については、"SSL ハンドシェイク" を参照してください。

SSL で使用される暗号

SSL プロトコルは、サーバとクライアントの相互認証、証明書の送信、セッションキーの確立などの操作に使用される様々な異なる暗号アルゴリズム、または暗号の使用をサポートしています。クライアントとサーバは、サポートしている SSL のバージョン、許容できる暗号化強度に関する会社の方針、SSL 対応ソフトウェアの輸出に対する政府の制限などの要因によって、異なる暗号スイート、または暗号のセットをサポートしているかもしれません。他の機能の中でも、SSL ハンドシェイクプロトコルは、サーバとクライアントがどの暗号スイートを使ってお互いを認証し、証明書を送信し、セッション鍵を確立するかをネゴシエートする方法を決定します。

KEA や RSA 鍵交換のような鍵交換アルゴリズムは、サーバとクライアントが SSL セッション中に使用する対称鍵を決定する方法を管理します。最も一般的に使われている SSL 暗号化スイートは RSA 鍵交換を使用しています。

SSL 2.0 と SSL 3.0 プロトコルは重複する暗号化スイートのセットをサポートしています。管理者はクライアントとサーバの両方でサポートされている暗号化スイートを有効にしたり無効にしたりすることができます。特定のクライアントとサーバが SSL ハンドシェイク中に情報を交換するとき、共通して有効になっている最も強力な暗号スイートを識別し、SSL セッションにそれらを使用します。

注: Firefox 2 はデフォルトで SSL 2.0 のサポートが無効になっており、SSL 3.0 が採用されています。詳しくは、Firefox 2 のセキュリティ の記事を参照してください。また、Firefox 8 では SSL 2.0 のサポートは完全に削除されています。

特定の組織がどの暗号を有効にするかの決定は、関係するデータの機密性、暗号の速度、輸出規則の適用可能性とのトレードオフによって決まります。

組織によっては、より弱い暗号化による SSL 接続を防ぐために、より弱い暗号を無効にしたいと思うかもしれません。しかし、米国政府は 40 ビット暗号化より強い暗号化をサポートする製品に制限を設けているため、すべての 40 ビット暗号化のサポートを無効にすると、米国内でのみ利用可能なネットワークブラウザへのアクセスが事実上制限されます (関係するサーバが、国際的なクライアントがより強い暗号化に「ステップアップ」することを許可する特別なグローバルサーバ ID を持っている場合を除く)。

できるだけ多くのユーザーにサービスを提供するために、管理者はできるだけ幅広い範囲の SSL 暗号スイートを有効にすることをお勧めします。そうすれば、国内のクライアントやサーバが他の国内のサーバやクライアントを相手にしているときに、それぞれが利用可能な最も強力な暗号の使用を交渉することができます。また、国内のクライアントやサーバが国際的なサーバやクライアントを相手にする場合には、米国の輸出規制で許可されている暗号の使用をネゴシエートします。

しかし、40ビットの暗号は比較的すぐに破られる可能性があるので、ユーザーコミュニティが輸出規制に違反することなくより強力な暗号を使用できる管理者は、盗聴者によるデータへのアクセスを懸念している場合は、40ビットの暗号を無効にすべきです。

Red Hat Console は Red Hat クライアントやサーバでサポートされているすべての暗号スイートをサポートしているわけではありません。Red Hat Console が SSL 対応サーバを確実に制御するためには、サーバが SSL 3.0 の次の暗号スイートのうち少なくとも 1 つを有効にしている必要があります。
  • 128ビット暗号化と MD5 メッセージ認証の RC4
  • 40ビット暗号化と MD5 メッセージ認証の RC4
  • 40ビット暗号化と MD5 メッセージ認証の RC2
  • 暗号化なし、MD5 メッセージ認証のみ

RSA 鍵交換による暗号スイート

表1は RSA 鍵交換アルゴリズムを使った SSL でサポートされている暗号スイートのリストです。別段の指示がない限り、表に記載されているすべての暗号は SSL 2.0 と SSL 3.0 の両方でサポートされています。暗号スイートは強いものから弱いものへとリストアップされています。

テーブル 1. RSA 鍵交換アルゴリズムを使用する SSL プロトコルでサポートされている暗号スイート
強度カテゴリと推奨用途
暗号スイート

最強の暗号スイート 米国内での展開にのみ許可されています。この暗号化スイートは、機密性の高いデータを扱う銀行やその他の機関に適しています。Red Hat Console はこの暗号スイートをサポートしていません。

トリプル DES 168 ビット暗号化と SHA-1 メッセージ認証 トリプル DES は SSL でサポートされている最強の暗号ですが、RC4 ほど高速ではありません。トリプル DES は標準 DES の3倍の長さの鍵を使用します。鍵のサイズが非常に大きいため、他のどの暗号よりも可能な鍵の数が多く、約 3.7 * 1050  になります。この暗号は FIPS に準拠しています。SSL 2.0 と SSL 3.0 は両方ともこの暗号スイートをサポートしています。

強力な暗号スイート 米国内での展開のみが許可されています。これらの暗号化スイートは、ほとんどのビジネスや政府のニーズに十分強い暗号化をサポートします。

128ビット暗号化と MD5 メッセージ認証を備えた RC4 RC4 および RC2 暗号は 128 ビット暗号化であるため、168 ビット暗号化のトリプル DES (データ暗号化標準) に次いで 2 番目に強力な暗号化です。RC4 と RC2 の 128 ビット暗号化では、約 3.4 * 1038 個の鍵を使用することができるため、クラックすることが非常に困難です。RC4 暗号化はサポートされている暗号化方式の中で最も速い暗号化方式です。SSL 2.0 と SSL 3.0 はこの暗号化方式をサポートしています。Red Hat Console はこの暗号化方式群の SSL 3.0 バージョンのみをサポートしています。

128ビット暗号化と MD5 メッセージ認証を備えた RC2 RC4 および RC2 暗号は 128 ビット暗号化であるため、168 ビット暗号化のトリプル DES (データ暗号化標準) に次いで 2 番目に強力な暗号化です。RC4 と RC2 の 128 ビット暗号化では、約 3.4 * 1038 個の可能な鍵が許可されているため、クラックすることが非常に困難です。RC2 暗号は RC4 暗号よりも遅いです。この暗号化方式は SSL 2.0 でサポートされていますが、SSL 3.0 ではサポートされていません。Red Hat Console はこの暗号化方式をサポートしていません。

56ビット暗号化と SHA-1 メッセージ認証の DES DES は 40 ビット暗号化よりは強力ですが、128 ビット暗号化ほどではありません。DES 56 ビット暗号化では、約 7.2 * 1016 の可能な鍵が可能です。この暗号化は FIPS に準拠しています。SSL 2.0 と SSL 3.0 は両方ともこの暗号化スイートをサポートしていますが、SSL 2.0 はメッセージ認証に SHA-1 ではなく MD5 を使用しています。Red Hat Console はこの暗号化スイートをサポートしていません。

輸出可能な暗号スイート これらの暗号化スイートは上記のものほど強力ではありませんが、ほとんどの国に輸出することができます (フランスでは SSL には許可されていますが、S/MIME には許可されていないことに注意してください)。これらは輸出可能な製品で利用可能な最も強力な暗号化を提供します。1

40ビット暗号化と MD5 メッセージ認証を備えた RC4 RC4 40 ビット暗号化では、約 1.1 * 1012 (1 兆個) の鍵を使用できます。RC4 暗号はサポートされている暗号の中で最も高速です。SSL 2.0 と SSL 3.0 の両方がこの暗号化方式をサポートしています。Red Hat Console はこの暗号化スイートの SSL 3.0 バージョンのみをサポートしています。

40ビット暗号化と MD5 メッセージ認証を備えた RC2 RC2 40 ビット暗号化では、約 1.1 * 1012 (1 兆個) の鍵を使用できます。RC2 暗号は RC4 暗号よりも遅くなります。SSL 2.0 と SSL 3.0 の両方がこの暗号化方式をサポートしています。Red Hat Console はこの暗号化方式の SSL 3.0 バージョンのみをサポートしています。

最弱の暗号スイート この暗号化スイートは認証と改ざん検出を提供しますが、暗号化は提供しません。しかし、この暗号化スイートを使って送信されたデータは暗号化されておらず、盗聴者によってアクセスされる可能性があるため、サーバ管理者はこの暗号化スイートを有効にすることに注意しなければなりません。 暗号化なし、MD5 メッセージ認証のみ この暗号スイートは、改ざんを検出するために MD5 メッセージ認証を使用します。これは通常、クライアントとサーバが他の暗号に共通するものがない場合にサポートされます。この暗号は SSL 3.0 でサポートされていますが、SSL 2.0 ではサポートされていません。

1 RC4 と RC2 の暗号化方式では、「40 ビット暗号化」という表現は、鍵の長さが 128 ビットのままで、40 ビットだけが暗号化されていることを意味していることに注意してください。

Fortezza 暗号スイート

表 2 は、Red Hat 製品が Fortezza でサポートしている追加の暗号スイートの一覧です。Fortezza は、米国政府機関が機密情報を管理するために使用する暗号化システムです。連邦政府によって開発された2つの暗号のハードウェア実装を提供します。Fortezza KEA と SKIPJACK です。SSL 用の Fortezza 暗号は、前項で述べた RSA 鍵交換アルゴリズムの代わりに鍵交換アルゴリズム (KEA) を使用し、クライアント認証に Fortezza カードと DSA を使用しています。

テーブル 2. Fortezza for SSL 3.0 を使用する際に Red Hat がサポートする暗号スイート
強度カテゴリと推奨用途 暗号スイート
ストロングフォートレスのサイファースイート 米国内での展開のみが許可されています。これらの暗号化スイートは、ほとんどのビジネスや政府のニーズに十分な強度の暗号化をサポートしています。Red Hat コンソールはこれらの暗号化スイートをサポートしていません。

128ビット暗号化と SHA-1 メッセージ認証を備えた RC4 128 ビット暗号化と MD5 メッセージ認証を持つ RC4 と同様に、この暗号はトリプル DES に次いで 2 番目に強力な暗号の 1 つです。約 3.4 * 1038 の可能な鍵を許可しており、クラックするのが非常に困難です。この暗号は SSL 3.0 でサポートされていますが、SSL 2.0 ではサポートされていません。

SKIPJACK 80ビット暗号化と SHA-1 メッセージ認証を備えた RC4 SKIPJACK 暗号は、Fortezza 準拠のハードウェアに実装された分類対称鍵暗号アルゴリズムです。SKIPJACK の実装の中には、Law Enforcement Access Field (LEAF) を使用したキーエスクローをサポートしているものがあります。最近の実装ではサポートされていません。この暗号は SSL 3.0 ではサポートされていますが、SSL 2.0 ではサポートされていません。

Weakest Fortezza Cipher Suite この暗号化スイートは認証と改ざん検出を提供しますが、暗号化は提供しません。しかし、この暗号化スイートを使用して送信されたデータは暗号化されておらず、盗聴者によってアクセスされる可能性があるため、サーバ管理者はこの暗号化スイートを有効にすることに注意しなければなりません。Red Hat Console はこれらの暗号化スイートを提供しません。

暗号化なし、SHA-1 メッセージ認証のみ この暗号は改ざんを検出するために SHA-1 メッセージ認証を使用します。この暗号は SSL 3.0 でサポートされていますが、SSL 2.0 ではサポートされていません。

SSL ハンドシェイク

SSL プロトコルは公開鍵暗号化と対称鍵暗号化を組み合わせて使用します。対称鍵暗号化は公開鍵暗号化よりも高速ですが、公開鍵暗号化の方がより優れた認証技術を提供します。SSL セッションは常に SSL ハンドシェイクと呼ばれるメッセージの交換から始まります。このハンドシェイクにより、サーバは公開鍵技術を使ってクライアントに対して自分自身を認証し、その後のセッション中にクライアントとサーバが迅速な暗号化、復号化、改ざん検知のための対称鍵を作成するために協力することができます。オプションとして、ハンドシェイクによって、クライアントがサーバに対して自分自身を認証することもできます。

SSL ハンドシェイク中に交換されるメッセージの正確なプログラム的な詳細はこの文書の範囲を超えています。しかし、関係するステップは以下のように要約することができます ("RSA 鍵交換による暗号スイート"に記載されている暗号スイートの使用を前提としています)。

  1. クライアントは、クライアントの SSL バージョン番号や暗号設定、ランダムに生成されたデータなど、サーバが SSL を使ってクライアントと通信するために必要な情報をサーバに送信します
  2. サーバはクライアントに、サーバの SSL バージョン番号、暗号化設定、ランダムに生成されたデータ、およびクライアントが SSL を介してサーバと通信するために必要なその他の情報を送信します。また、サーバは自身の証明書を送信し、クライアントがクライアント認証を必要とするサーバリソースを要求している場合には、クライアントの証明書を要求します
  3. クライアントはサーバから送信された情報の一部を用いてサーバを認証します (詳細は "サーバ認証" を参照)。サーバの認証ができない場合は,ユーザに問題があることを警告し,暗号化された認証済みの接続が確立できないことを通知します.サーバの認証に成功した場合は、ステップ4に進みます
  4. これまでのハンドシェイクで生成されたすべてのデータを使用して、クライアントは (使用されている 暗号に応じてサーバの協力を得て) セッションのプレマスタシークレットを作成し、(ステップ2で送られたサーバの証明書から取得した) サーバの公開鍵で暗号化し、暗号化されたプレマスタシークレットをサーバに送信します
  5. サーバがクライアント認証を要求した場合 (ハンドシェイクのオプションステップ)、クライアントは、このハンドシェイクに固有の、クライアントとサーバの両方が知っている別のデータにも署名する。この場合、クライアントは署名されたデータとクライアント自身の証明書の両方を、暗号化されたプレマスタシークレットとともにサーバに送信します
  6. サーバがクライアント認証を要求した場合、サーバはクライアントの認証を試みます (詳細は "クライアント認証" を参照)。クライアントの認証ができなかった場合、セッションは終了する。クライアントの認証に成功した場合、サーバは秘密鍵を使用してプレマスタ秘密を復号化し、(クライアントも同じプレマ スター秘密から開始して) 一連の手順を実行してマスタ秘密を生成する
  7. これは SSL セッション中に交換された情報を暗号化・復号化し、その完全性を検証するために使用される対称鍵で、送信されてから SSL 接続で受信されるまでの間のデータの変化を検出します
  8. クライアントは、クライアントからの今後のメッセージがセッションキーで暗号化されることをサーバに通知す るメッセージをサーバに送信します。その後、ハンドシェイクのクライアント部分が終了したことを示す別の (暗号化された) メッセージを送信する
  9. サーバは、サーバからの今後のメッセージがセッションキーで暗号化されることをクライアントに通知するメッセージを送信します。その後、サーバはハンドシェイクのサーバ部分が終了したことを示す別の (暗号化された) メッセージを送信する
  10. SSL ハンドシェイクが完了し、SSL セッションが開始されました。クライアントとサーバはセッションキーを使って、お互いに送信するデータを暗号化・復号化し、その整合性を検証します

セッションを続行する前に、クライアントの証明書が LDAP ディレクトリのユーザーのエントリに存在することを確認するように Red Hat サーバを設定できます。この設定オプションは、クライアントの証明書が失効されていないことを確認するための一つの方法を提供します。

クライアント認証とサーバ認証では、公開/秘密鍵ペアの一方の鍵でデータを暗号化し、もう一方の鍵で復号化することに注意してください。

  • サーバ認証の場合、クライアントはプレマスタの秘密をサーバの公開鍵で暗号化する。対応する秘密鍵だけが秘密を正しく復号できるため、クライアントは、公開鍵に関連付けられた ID が実際にクライアントが接続しているサーバであることをある程度保証する。そうでなければ、サーバはプレマスタ秘密を復号化できず、セッションに必要な対称鍵を生成できず、セッションは終了する
  • クライアント認証の場合、クライアントはクライアントの秘密鍵でランダムなデータを暗号化します。クライアントの証明書の公開鍵は、対応する秘密鍵が使用された場合にのみ、電子署名を正しく検証することができます。そうでない場合、サーバは電子署名を検証できず、セッションは終了します

次のセクションでは、サーバ認証とクライアント認証の詳細について説明します。

サーバ認証

Red Hat の SSL 対応クライアントソフトウェアでは、常にサーバ認証、つまりクライアントがサーバの身元を暗号化して検証する必要があります。"SSL ハンドシェイク" のステップ 2 で説明したように、サーバは自分自身を認証するための証明書をクライアントに送信します。クライアントはステップ3で証明書を使用して、証明書が表現すると主張する身元を認証する。

公開鍵とその公開鍵を含む証明書によって識別されるサーバとの間の結合を認証するために、SSL 対応クライアントは図2に示す4つの質問に対して「はい」の答えを受け取らなければなりません。4つ目の質問は技術的には SSL プロトコルの一部ではありませんが、この要件をサポートするのはクライアントの責任です。

SSL 対応のクライアントは以下の手順でサーバの身元を認証します。

  1. 今日の日付は有効期限内ですか? クライアントは、サーバ証明書の有効期間を確認します。現在の日時がその範囲外であれば、認証処理はそれ以上進みません。現在の日時が証明書の有効期間内であれば、クライアントはステップに進みます
  2. 発行した CA は信頼できる CA ですか? 各 SSL 対応クライアントは、図3の右側の網掛け部分で表される信頼できる CA 証明書のリストを保持しています。このリストは、クライアントがどのサーバ証明書を受け入れるかを決定します。発行した CA の識別名 (DN) がクライアントの信頼できる CA のリストにある CA の DN と一致する場合、この質問の答えは「はい」であり、クライアントはステップ3に進みます。発行 CA がリストにない場合、クライアントがリストにある CA で終わる証明書チェーンを検証できない限り、サーバは認証されません
  3. 発行局の公開鍵は発行者の電子署名を検証するか? クライアントは、提示されたサーバ証明書の CA のデジタル署名を検証するために、CA の証明書の公開鍵 (ステップ 2 で信頼できる CA のリストに含まれている) を使用します。サーバ証明書の情報が CA によって署名された後に変更された場合、または CA 証明書の公開鍵がサーバ証明書に署名するために CA が使用した秘密鍵と一致しない場合、クライアントはサーバの身元を認証しません。CA のデジタル署名を検証できる場合、サーバはユーザの証明書をその CA からの有効な「紹介状」として扱い、処理を進める。この時点で、クライアントはサーバ証明書が有効であると判断したことになります。ステップ5の前にステップ4を行うのはクライアントの責任です
  4. サーバの証明書に記載されているドメイン名は、サーバ自体のドメイン名と一致していますか? このステップでは、サーバがサーバ証明書のドメイン名で指定されたネットワークアドレスに実際に存在することを確認します。ステップ4は技術的には SSL プロトコルの一部ではありませんが、これは「中間者」と呼ばれるセキュリティ攻撃からの唯一の防御手段です。クライアントはこのステップを実行し、ドメイン名が一致しない場合はサーバの認証を拒否したり、接続を確立したりしなければなりません。サーバの実際のドメイン名がサーバ証明書のドメイン名と一致した場合、クライアントはステップ5に進みます
  5. サーバが認証されています。クライアントは SSL ハンドシェイクを行います。クライアントが何らかの理由でステップ5に進まなかった場合、証明書で識別されたサーバは認証できず、ユーザは問題を警告され、暗号化された認証済みの接続が確立できないことを通知されます。サーバがクライアント認証を必要とする場合、サーバは "クライアント認証" で説明したステップを実行します

ここで説明した手順の後、サーバはその秘密鍵を使用して、クライアントが "SSL ハンドシェイク" のステップ4で送信したプレマスタ秘密を復号化することに成功しなければなりません。そうでなければ、SSL セッションは終了します。これにより、サーバの証明書の公開鍵に関連付けられた ID が、実際にクライアントが接続しているサーバであることがさらに保証されます。

中間者攻撃

上記のステップ4で提案されているように、クライアントアプリケーションは、クライアントが通信しようとしているサーバの実際のドメイン名に対して、サーバ証明書で指定されたサーバドメイン名をチェックしなければなりません。このステップは、以下のように動作する中間者攻撃から保護するために必要です。

"中間者" とは、クライアントと SSL を介して通信しようとしているサーバとの間のすべての通信を遮断する不正なプログラムのことです。不正プログラムは、SSL ハンドシェイク中に行き来する正当な鍵を傍受し、自分の鍵を代用して、クライアントには自分がサーバであるように、サーバには自分がクライアントであるように見せかけます。

SSL ハンドシェイクの最初に交換される暗号化された情報は、実際にはクライアントやサーバの実際の鍵ではなく、不正プログラムの公開鍵や秘密鍵で暗号化されます。不正なプログラムは、実際のサーバで使用するためのセッション鍵のセットを確立し、クライアントで使用するための別のセッション鍵を送信します。これにより、不正プログラムはクライアントと実サーバの間を流れるすべてのデータを読み取ることができるだけでなく、削除されることなくデータを変更することができます。したがって、サーバ証明書のドメイン名が、クライアントが通信しようとしているサーバのドメイン名と一致しているかどうかを確認することは、「サーバ認証」で説明した他のステップを実行して証明書の有効性を確認することに加えて、クライアントにとって非常に重要です。

クライアント認証

SSL 対応のサーバは、クライアント認証を要求するように設定することができます。このように設定されたサーバがクライアント認証を要求するとき ("SSL ハンドシェイク" のステップ6を参照)、クライアントはサーバに証明書と自分自身を認証するための別個のデジタル署名されたデータの両方を送ります。サーバはデジタル署名されたデータを使って、証明書の公開鍵を検証し、証明書が表現すると主張する身元を認証します。

SSL プロトコルでは、クライアントはハンドシェイク中にランダムに生成され、クライアントとサーバのみが知っているデータから一方向ハッシュを作成してデジタル署名を作成する必要があります。データのハッシュは、サーバに提示される証明書の公開鍵に対応する秘密鍵で暗号化されます。

公開鍵と公開鍵を含む証明書によって識別される個人やその他のエンティティとの間の結合を認証するために、SSL 対応サーバは、図3に示す最初の4つの質問に対して「はい」の答えを受け取らなければなりません。5 番目の質問は SSL プロトコルの一部ではありませんが、認証プロセスの一部として LDAP ディレクトリへのユーザーの入力を利用するために、Red Hat サーバはこの要件をサポートするように設定することができます。

SSL 対応サーバは、以下の手順でユーザーの身元を認証します。

  1. ユーザーの公開鍵は、ユーザーの電子署名を検証していますか? サーバは、ユーザのデジタル署名が証明書の公開鍵で検証できるかどうかを確認します。そうであれば、サーバは、John Doe に属すると主張された公開鍵が署名の作成に使用された秘密鍵と一致し、署名されてからデータが改ざんされていないことを確認したことになります
    しかし、この時点では、公開鍵と証明書に指定された DN との間のバインドはまだ確立されていません。証明書は、ユーザになりすまそうとする者によって作成された可能性があります。公開鍵と DN の結合を検証するために、サーバはステップ3とステップ4も完了しなければなりません
  2. 今日の日付は有効期限内ですか? サーバは証明書の有効期間をチェックします。現在の日時がその範囲外の場合、認証処理はそれ以上進みません。現在の日時が証明書の有効期間内であれば、サーバはステップ 3 に進みます
  3. 発行した CA は信頼できる CA ですか? 各 SSL 対応サーバは、図3の右側の網掛け部分で表される信頼できる CA 証明書のリストを保持しています。このリストはサーバがどの証明書を受け入れるかを決定します。発行する CA の DN がサーバの信頼できる CA のリストにある CA の DN と一致していれば、この質問の答えは「はい」であり、サーバはステップ 4 に進みます。発行 CA がリストにない場合、サーバがリストにある CA で終わる証明書チェーンを検証できない限り、クライアントは認証されません。管理者は、クライアントとサーバによって維持される CA 証明書のリストを制御することで、組織内でどの証明書が信頼されているか、あるいは信頼されていないかを制御することができます
  4. 発行局の公開鍵は発行者の電子署名を検証しますか? サーバは、提示された証明書の CA のデジタル署名を検証するために、CA の証明書の公開鍵 (ステップ 3 で信頼できる CA のリストに含まれている) を使用します。証明書の情報が CA によって署名された後に変更された場合、または CA 証明書の公開鍵が CA が証明書に署名するために使用した秘密鍵と一致しない場合、サーバはユーザの身元を認証しません。CA のデジタル署名が検証できる場合、サーバはユーザの証明書をその CA からの有効な「紹介状」として扱い、処理を進めます。この時点で、SSL プロトコルにより、サーバーはクライアントが認証されたとみなし、ステップ 6 で説明したように接続を続行します。Red Hat サーバーは、オプションでステップ 6 の前にステップ 5 を実行するように設定することができます
  5. ユーザーの LDAP エントリにユーザーの証明書が記載されていますか? このオプションのステップは、他のすべてのステップでテストに合格した場合でも、システム管理者がユーザーの証明書を失効させる方法の 1 つを提供します。Red Hat 証明書システムは、LDAP ディレクトリ内のユーザーのエントリから失効した証明書を自動的に削除することができます。このステップを実行するように設定されているすべてのサーバーは、その証明書の認証や接続の確立を拒否します。ディレクトリ内のユーザーの証明書が SSL ハンドシェイクで提示されたユーザーの証明書と同一である場合、サーバーはステップ 6 に進みます
  6. 認証されたクライアントは、要求されたリソースへのアクセスを許可されていますか? サーバは、サーバのアクセス制御リスト (ACL) に従って、クライアントがアクセスを許可されているリソースを確認し、適切なアクセス権を持つ接続を確立します。サーバが何らかの理由でステップ6に到達しなかった場合、証明書で特定されたユーザは認証できず、ユーザは認証を必要とするサーバリソースへのアクセスを許可されません

Original Document Information

  • Author(s): [Author Names]
  • Other Contributors: Giacomo Magnini
  • Last Updated Date: September 26, 2005
  • Copyright Information: © 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.