このドキュメントは、 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 をサポートするアプリケーションの開発者にも役立つものが含まれています。ドキュメントは、あなたが "公開鍵暗号入門" にまとめられているような公開鍵暗号の基本概念に詳しいと仮定しています。
伝送制御プロトコル/インターネットプロトコル (TCP/IP) は、インターネット上のデータのトランスポートとルーティングを規定しています。ハイパーテキスト・トランスポート・プロトコル (HTTP)、ライトウェイト・ディレクトリ・アクセス・プロトコル (LDAP)、インターネット・メッセージング・アクセス・プロトコル (IMAP) などの他のプロトコルは、Web ページの表示や電子メール・サーバの実行などの典型的なアプリケーション・タスクをサポートするために TCP/IP を使用するという意味で、TCP/IP の「上」で実行されます。
SSL プロトコルは、TCP/IP の上に、HTTP や IMAP などの高レベルのプロトコルの下で動作します。上位プロトコルの代わりに TCP/IP を使用し、その過程で SSL 対応のサーバが SSL 対応のクライアントに自分自身を認証し、クライアントがサーバに自分自身を認証し、両方のマシンが暗号化された接続を確立することを可能にします。
これらの機能は、インターネットやその他の TCP/IP ネットワーク上の通信に関する基本的な問題に対処します。
SSL プロトコルには、SSL レコードプロトコルと SSL ハンドシェイクプロトコルの2つのサブプロトコルがあります。SSL レコードプロトコルはデータを送信するためのフォーマットを定義します。SSL ハンドシェイクプロトコルでは、SSL レコードプロトコルを使用して、SSL 対応サーバと SSL 対応クライアントが最初に SSL 接続を確立するときに、一連のメッセージを交換します。このメッセージの交換は、以下の動作を容易にするように設計されています。
ハンドシェイク処理の詳細については、"SSL ハンドシェイク" を参照してください。
SSL プロトコルは、サーバとクライアントの相互認証、証明書の送信、セッションキーの確立などの操作に使用される様々な異なる暗号アルゴリズム、または暗号の使用をサポートしています。クライアントとサーバは、サポートしている SSL のバージョン、許容できる暗号化強度に関する会社の方針、SSL 対応ソフトウェアの輸出に対する政府の制限などの要因によって、異なる暗号スイート、または暗号のセットをサポートしているかもしれません。他の機能の中でも、SSL ハンドシェイクプロトコルは、サーバとクライアントがどの暗号スイートを使ってお互いを認証し、証明書を送信し、セッション鍵を確立するかをネゴシエートする方法を決定します。
KEA や RSA 鍵交換のような鍵交換アルゴリズムは、サーバとクライアントが SSL セッション中に使用する対称鍵を決定する方法を管理します。最も一般的に使われている SSL 暗号化スイートは RSA 鍵交換を使用しています。
SSL 2.0 と SSL 3.0 プロトコルは重複する暗号化スイートのセットをサポートしています。管理者はクライアントとサーバの両方でサポートされている暗号化スイートを有効にしたり無効にしたりすることができます。特定のクライアントとサーバが SSL ハンドシェイク中に情報を交換するとき、共通して有効になっている最も強力な暗号スイートを識別し、SSL セッションにそれらを使用します。
特定の組織がどの暗号を有効にするかの決定は、関係するデータの機密性、暗号の速度、輸出規則の適用可能性とのトレードオフによって決まります。
組織によっては、より弱い暗号化による SSL 接続を防ぐために、より弱い暗号を無効にしたいと思うかもしれません。しかし、米国政府は 40 ビット暗号化より強い暗号化をサポートする製品に制限を設けているため、すべての 40 ビット暗号化のサポートを無効にすると、米国内でのみ利用可能なネットワークブラウザへのアクセスが事実上制限されます (関係するサーバが、国際的なクライアントがより強い暗号化に「ステップアップ」することを許可する特別なグローバルサーバ ID を持っている場合を除く)。
できるだけ多くのユーザーにサービスを提供するために、管理者はできるだけ幅広い範囲の SSL 暗号スイートを有効にすることをお勧めします。そうすれば、国内のクライアントやサーバが他の国内のサーバやクライアントを相手にしているときに、それぞれが利用可能な最も強力な暗号の使用を交渉することができます。また、国内のクライアントやサーバが国際的なサーバやクライアントを相手にする場合には、米国の輸出規制で許可されている暗号の使用をネゴシエートします。
しかし、40ビットの暗号は比較的すぐに破られる可能性があるので、ユーザーコミュニティが輸出規制に違反することなくより強力な暗号を使用できる管理者は、盗聴者によるデータへのアクセスを懸念している場合は、40ビットの暗号を無効にすべきです。
表1は RSA 鍵交換アルゴリズムを使った SSL でサポートされている暗号スイートのリストです。別段の指示がない限り、表に記載されているすべての暗号は SSL 2.0 と SSL 3.0 の両方でサポートされています。暗号スイートは強いものから弱いものへとリストアップされています。
|
強度カテゴリと推奨用途
|
暗号スイート
|
|---|---|
|
最強の暗号スイート 米国内での展開にのみ許可されています。この暗号化スイートは、機密性の高いデータを扱う銀行やその他の機関に適しています。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 ビットだけが暗号化されていることを意味していることに注意してください。 |
表 2 は、Red Hat 製品が Fortezza でサポートしている追加の暗号スイートの一覧です。Fortezza は、米国政府機関が機密情報を管理するために使用する暗号化システムです。連邦政府によって開発された2つの暗号のハードウェア実装を提供します。Fortezza KEA と SKIPJACK です。SSL 用の Fortezza 暗号は、前項で述べた RSA 鍵交換アルゴリズムの代わりに鍵交換アルゴリズム (KEA) を使用し、クライアント認証に Fortezza カードと DSA を使用しています。
| 強度カテゴリと推奨用途 | 暗号スイート |
|---|---|
| ストロングフォートレスのサイファースイート 米国内での展開のみが許可されています。これらの暗号化スイートは、ほとんどのビジネスや政府のニーズに十分な強度の暗号化をサポートしています。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 ハンドシェイク中に交換されるメッセージの正確なプログラム的な詳細はこの文書の範囲を超えています。しかし、関係するステップは以下のように要約することができます ("RSA 鍵交換による暗号スイート"に記載されている暗号スイートの使用を前提としています)。
セッションを続行する前に、クライアントの証明書が LDAP ディレクトリのユーザーのエントリに存在することを確認するように Red Hat サーバを設定できます。この設定オプションは、クライアントの証明書が失効されていないことを確認するための一つの方法を提供します。
クライアント認証とサーバ認証では、公開/秘密鍵ペアの一方の鍵でデータを暗号化し、もう一方の鍵で復号化することに注意してください。
次のセクションでは、サーバ認証とクライアント認証の詳細について説明します。
Red Hat の SSL 対応クライアントソフトウェアでは、常にサーバ認証、つまりクライアントがサーバの身元を暗号化して検証する必要があります。"SSL ハンドシェイク" のステップ 2 で説明したように、サーバは自分自身を認証するための証明書をクライアントに送信します。クライアントはステップ3で証明書を使用して、証明書が表現すると主張する身元を認証する。
公開鍵とその公開鍵を含む証明書によって識別されるサーバとの間の結合を認証するために、SSL 対応クライアントは図2に示す4つの質問に対して「はい」の答えを受け取らなければなりません。4つ目の質問は技術的には SSL プロトコルの一部ではありませんが、この要件をサポートするのはクライアントの責任です。
SSL 対応のクライアントは以下の手順でサーバの身元を認証します。
ここで説明した手順の後、サーバはその秘密鍵を使用して、クライアントが "SSL ハンドシェイク" のステップ4で送信したプレマスタ秘密を復号化することに成功しなければなりません。そうでなければ、SSL セッションは終了します。これにより、サーバの証明書の公開鍵に関連付けられた ID が、実際にクライアントが接続しているサーバであることがさらに保証されます。
上記のステップ4で提案されているように、クライアントアプリケーションは、クライアントが通信しようとしているサーバの実際のドメイン名に対して、サーバ証明書で指定されたサーバドメイン名をチェックしなければなりません。このステップは、以下のように動作する中間者攻撃から保護するために必要です。
"中間者" とは、クライアントと SSL を介して通信しようとしているサーバとの間のすべての通信を遮断する不正なプログラムのことです。不正プログラムは、SSL ハンドシェイク中に行き来する正当な鍵を傍受し、自分の鍵を代用して、クライアントには自分がサーバであるように、サーバには自分がクライアントであるように見せかけます。
SSL ハンドシェイクの最初に交換される暗号化された情報は、実際にはクライアントやサーバの実際の鍵ではなく、不正プログラムの公開鍵や秘密鍵で暗号化されます。不正なプログラムは、実際のサーバで使用するためのセッション鍵のセットを確立し、クライアントで使用するための別のセッション鍵を送信します。これにより、不正プログラムはクライアントと実サーバの間を流れるすべてのデータを読み取ることができるだけでなく、削除されることなくデータを変更することができます。したがって、サーバ証明書のドメイン名が、クライアントが通信しようとしているサーバのドメイン名と一致しているかどうかを確認することは、「サーバ認証」で説明した他のステップを実行して証明書の有効性を確認することに加えて、クライアントにとって非常に重要です。
SSL 対応のサーバは、クライアント認証を要求するように設定することができます。このように設定されたサーバがクライアント認証を要求するとき ("SSL ハンドシェイク" のステップ6を参照)、クライアントはサーバに証明書と自分自身を認証するための別個のデジタル署名されたデータの両方を送ります。サーバはデジタル署名されたデータを使って、証明書の公開鍵を検証し、証明書が表現すると主張する身元を認証します。
SSL プロトコルでは、クライアントはハンドシェイク中にランダムに生成され、クライアントとサーバのみが知っているデータから一方向ハッシュを作成してデジタル署名を作成する必要があります。データのハッシュは、サーバに提示される証明書の公開鍵に対応する秘密鍵で暗号化されます。
公開鍵と公開鍵を含む証明書によって識別される個人やその他のエンティティとの間の結合を認証するために、SSL 対応サーバは、図3に示す最初の4つの質問に対して「はい」の答えを受け取らなければなりません。5 番目の質問は SSL プロトコルの一部ではありませんが、認証プロセスの一部として LDAP ディレクトリへのユーザーの入力を利用するために、Red Hat サーバはこの要件をサポートするように設定することができます。
SSL 対応サーバは、以下の手順でユーザーの身元を認証します。