Secure Sockets Layer (SSL) は、情報を自動的に暗号化してからそれをインターネット上で送信し、使用前に相手側でそれを暗号化解除するシステムです。これにより、インターネット上の伝送中に、クレジット・カード番号などの機密情報が保護されます。
Caching Proxy は SSL を使用して代理サーバーの安全を保護し、以下のセクションで説明するように セキュア・リモート管理を可能にします。また、SSL を使用して、バックエンド・ サーバー (例えば、コンテンツ・サーバーやアプリケーション・サーバー) への接続を保護したり、 プロキシー・サーバーとそのクライアントの間の通信を保護したりすることもできます。
フォワード・プロキシーの場合、Caching Proxy は SSL トンネリングをサポートします。これにより、SSL がバイパスされ、既に暗号化されたデータが変更なしに送り出されます。
SSL 保護は、セキュア・コネクション要求が 1 つのマシンから別のマシンに送信されるとき、例えば、 ブラウザーが要求を代理プロキシー・サーバーに送信するときに、開始されます。 要求構文として http:// の代わりに https:// を使用すると、サーバーがセキュア接続要求を listen するポート 443 (通常の要求用のポート 80 の代わり) 上で要求を送信するようにブラウザーに指示されます。 ブラウザーとサーバーの間でセキュア・セッションを確立するには、2 つのマシンが SSL ハンドシェーク と呼ばれる交換を実行してその暗号仕様に関して同意し、情報の暗号化および暗号化解除に使用される鍵を選択します。鍵は自動的に生成され、セッションが満了するとその有効期限が切れます。 一般的なシナリオ (SSL バージョン 3 を想定) は、次のとおりです。
クライアントは、クライアントの暗号化能力を説明する Client Hello メッセージを送信して、Caching Proxy との SSL セッションを開始する。
サーバーはクライアントに証明書を送信し、データ暗号化に使用する暗号方式を選択する。
クライアントは、暗号化されたデータの対称暗号鍵の作成に使用される鍵の情報を送信する。この鍵の材料は、プリマスターリング・シークレット と呼ばれ、サーバーの公開鍵 (サーバーの証明書から取得します。鍵および認証の管理を参照) で暗号化されます。 サーバーもクライアントも、このプリマスター・シークレットから、読み取りおよび書き込みの対称暗号鍵を得ることができます。
サーバーは、ハンドシェーク・プロトコル全体の最終確認とメッセージ確認コード (MAC) を送信する。
クライアントは、サーバーの最終メッセージを検証するためのメッセージを送信する。
クライアントがサーバーの最終メッセージを検証すると、暗号化されたデータのフローが始まる。
Caching Proxy をセキュア接続のエンドポイントとして使用することによって、コンテンツ・サーバーまたは アプリケーション・サーバーの負荷を軽減することができます。Caching Proxy は、セキュア接続を維持する場合に、 すべて CPU 集中操作となる暗号化および暗号化解除と、鍵の作成を行います。 また、Caching Proxy によって SSL セッションのタイムアウトを構成して、それぞれの鍵の使用を 最大限にすることができます。
SSL の制限
WebSphere® Application Server の Caching Proxy 内の SSL には、以下のような制限が適用されます。
HTTPS トラフィックの量が増すと、Caching Proxy サーバーが原因で、CPU 使用が高くなることがあります。 環境変数 (GSK_V3_SIDCACHE_SIZE) およびプロキシー・ディレクティブ (SSLV3Timeout) に対する変更を調整すると、 プロキシー・サーバーが負荷を処理しやすくなり、また CPU 使用の削減にも役立ちます。
SSL セッション ID は、再使用可能な SSL セッションを識別する ID です。 ブラウザーとサーバーの両者で使用される、暗号化または暗号化解除の鍵を含みます。 また、SSL セッション ID は、 新規接続での不要な SSL ハンドシェーク (サーバーの CPU 時間を大きく消費します) を 回避するためにも使用されます。 Caching Proxy サーバー用の GSKit ライブラリーは、 SSL セッション ID をサポートし、 SSL セッション ID キャッシュを含んでいます。 デフォルトでは、SSL セッション ID キャッシュに 512 個の項目が含まれています。 項目の制限に達すると、一番古いセッション項目が除去され、 新規の項目がキャッシュに追加されます。
SSL セッション ID キャッシュのデフォルトのサイズを変更するには、 GSK_V3_SIDCACHE_SIZE 環境変数を使用します。 この変数の有効な値は、1 から 4096 です。このサイズを大きくするほど、 キャッシュ SSL セッションを探し出すために必要な検索時間が増加します。 ただし、検索時間が増加することは、 SSL 接続を確立するために必要となるオーバーヘッドと比較すると、 それほど重要なことではありません。 キャッシュ・サイズを大きくすると、プロキシー・サーバーは、 より多くの並行 SSL セッションを処理できるようになります。 また、プロキシー・サーバーに高い HTTPS 負荷がかかっているときの CPU 使用も削減されます。
Caching Proxy には、調整可能な SSLV3Timeout ディレクティブもあります。 (SSLV3Timeout - SSLV3 セッションが有効期限切れになるまでの待ち時間を指定するを参照してください。) このディレクティブのデフォルト値は、1000 秒です。 このディレクティブでは、セッション・キャッシュでの SSL セッションの存続時間を定義します。 着信 SSL 接続で既存の SSL セッションが使用されず、 しかもセッションの存続時間がこの値を超えると、 そのセッションはセッション・キャッシュから除去されます。 SSLV3Timeout 値は、 保護されたクライアント・セッションの標準的な長さに設定することをお勧めします。 タイムアウトをあまり短く設定すると、 プロキシーのパフォーマンスが低下することがあります。 これは、単一の保護セッションを完了するために、 複数の SSL ハンドシェーク・セッションが必要となるからです。 ただし、長過ぎる値を設定すると、 保護セッションのセキュリティーが損なわれる場合があります。
これは、フォワード・プロキシー構成にのみ適用されます。
Caching Proxy は、フォワード・プロキシー・サーバーとして構成されると、SSL トンネリングを使用して、クライアントとコンテンツ・サーバーの間のセキュア接続をサポートします。SSL トンネリングでは、暗号化されたデータが変換されずにプロキシー・サーバーをパススルーします。プロキシー・サーバーはデータの暗号化を解除しないため、プロキシー・サーバーが要求をまたは文書ヘッダーを読み取る必要のある機能は SSL トンネリングではサポートされていません。またトンネルに入れられる要求はキャッシュに入れられません。
図 2 では、SSL トンネリングを使用することにより接続を確立する方法を示しています。
SSL トンネリング・プロセスは、次のとおりです。
順方向プロキシー設定では、SSL トンネリングのみが使用可能です。SSL トンネリング を使用可能にするには、「構成および管理」フォームで、「プロキシー構成」–>「プロキシー設定」を選択します。次に、 「SSL トンネリング」チェック・ボックスを選択します。
SSL トンネリング接続では、CONNECT メソッド (デフォルトでは使用不可) も使用可能にする必要があります。これを 使用可能にするには、「構成および管理」フォームで、「サーバー構成」–>「要求処理」を選択し、「HTTP メソッド」 フォームを使用します。
拡張 SSL トンネリング・セキュリティーのために、 Enable CONNECT ディレクティブには 3 つのオプション (OutgoingPorts、OutgoingIPs、IncomingIPs) が用意されています。 少なくとも OutgoingPorts には、値を指定する必要があります。 このオプションの値を指定しないと、CONNECT メソッドは有効になりません。
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]
SSL トンネリングのために、
クライアントがリモート・サーバーのポート 443
にのみ接続できるようにするには、次のディレクティブを設定します。
(通常、ポート 443 は、リモート・サーバー上の HTTPS 要求に使われます。)
Enable CONNECT OutgoingPorts 443
SSLTunneling on
SSL トンネリングのために、
クライアントがリモート・サーバーのすべてのポートに接続できるようにするには、
次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all
SSLTunneling on
SSL トンネリングのために、クライアントがリモート・サーバーのポート 80、
8080-8088、および 9000 以上のポートに接続できるようにするには、
次のディレクティブを設定します。
Enable CONNECT OutgoingPorts 80,8080-8088,9000-*
SSLTunneling on
ポートおよびポート範囲は、 リスト内にスペースを入れずに、コンマで区切って指定します。
重要: フォワード・プロキシー構成の場合、 通常の SSL トンネリングを有効にするためには、 OutgoingPorts オプションで、 少なくとも 443 または all を指定してください。
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]
例えば、IP/ホスト名 *.ibm.com に一致し、192.168.*.*
には一致しないリモート・サーバーのすべてのポートに、
クライアントが接続できるようにするには、次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.*
SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP_Pattern,...]
例えば、SSL トンネリングのために、
IP アドレスが 192.168.*.* であるクライアントが、
リモート・サーバーのすべてのポートへ接続を行えるようにするには、
次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.*
SSLTunneling on
プロキシー構成ファイルを編集して、 SSL トンネリングおよび CONNECT ディレクティブを使用可能にするには、 次のディレクティブの付録B. 構成ファイル・ディレクティブにおいて、 それぞれの解説セクションを参照してください。
Caching Proxy のリモート管理は、Secure Sockets Layer (SSL) が提供するセキュリティー機能とパスワード認証を使用することにより行うことができます。 この方法をとると、許可されない人がプロキシー・サーバーにアクセスする可能性が大幅に減少します。
サーバーのリモート管理を実行しているときに SSL を適用するには、http:// 要求の代わりに https:// 要求を使用して、「構成および管理」フォームをオープンします。 例えば、次のとおりです。
https://your.server.name/yourFrontPage.html
SSL を構成する前に、鍵データベースをセットアップし、 証明書を取得または作成する必要があります。 証明書は、サーバー ID を認証するために使用されます。 IBM 鍵管理ユーティリティー (iKeyman と呼ばれる場合もある) を使用して、証明書ファイルをセットアップしてください。 このユーティリティーは、Java Development Kit (JDK) の一部です。 iKeyman には、証明書ファイルを開くための、Java ベースのグラフィカル・インターフェースも含まれています。
以下は、SSL 鍵および証明書をセットアップするための基本的な手順です。
Linux 以外のすべてのオペレーティング・システムで、証明書の 有効期限が切れた場合、Caching Proxy は適切に開始せず、鍵データベースの有効期限が切れたことを 示すエラー・メッセージが表示されます。Linux の場合は、プロキシーが現れて開始しますが、 プロセスは即時に消失し、何のエラー・メッセージも生成しません。
Red Hat Enterprise Linux 3.0 システムでこの問題を回避するには、 GCC パッケージが以下に示しているレベルか、 またはそれ以上のレベルであることを確認してください。
公開鍵は、サーバーのトラステッド・ルート認証局 (CA) と指定された CA による、デジタル署名済み証明書に関連したものでなければなりません。 署名済み証明書は、認証局 (CA) プロバイダーに証明書要求を依頼することによって、購入することができます。Caching Proxy は、次の外部 CA をサポートしています。
デフォルトでは、トラステッド CA として、以下のものが指定されています。
この項では、IBM 鍵管理ユーティリティー (iKeyman) の使用に関するクイック・リファレンスを提供します。鍵管理を使用して、SSL 鍵データベース・ファイル、公開鍵と秘密鍵のペア、および証明書要求を作成します。CA の署名済み証明書を受け取ったら、鍵管理を使用して、その証明書を、オリジナルの証明書要求を作成した鍵データベースに入れてください。
IBM 鍵管理および GSKit の詳細な資料が、GSKit ソフトウェアと同梱されています。
鍵管理を実行するためのシステムのセットアップ
IKeyman GUI を開始する前に、以下を実行してください。
JAVA_HOME/jre/lib/security/java.security ファイルを更新して、 以下の例で示す場所に IBM CMS プロバイダーと IBM JCE プロバイダーの両方を追加します。
鍵管理の開始
JDK の iKeyman ツールを実行して、鍵管理グラフィカル・ユーザー・インターフェースを開始します。 例えば、以下のコマンドを使用します。
鍵データベースは、1 つ以上の鍵ペアと証明書を保管するために、サーバーが使用するファイルです。すべての鍵ペアと証明書に 1 つの鍵データベースを使用することも、複数のデータベースを作成することもできます。鍵管理ユーティリティーを使用して、新規の鍵データベースを作成し、そのパスワードと stash ファイルを指定します。
鍵データベースおよび stash ファイルを作成する手順は、次のとおりです。
新規の鍵データベースを作成するときに指定するパスワードは、秘密鍵を保護します。文書に署名し、公開鍵で暗号化されたメッセージを暗号化解除することができるのは、秘密鍵だけです。
パスワードを指定する際には、以下のガイドラインに従ってください。
鍵データベースのパスワードをしばしば変更するのは、よい方法です。ただし、パスワード に有効期限を指定した場合は、パスワードの変更時期を記録してください。変更する前にパスワードが有効期限切れになると、 エラー・ログにメッセージが書き込まれます。この場合、サーバーは始動しますが、安全なネットワーク接続ができなくなります。
鍵データベース・パスワードを変更するには、次のステップに従ってください。
プロキシー・サーバーと LDAP サーバーの間の SSL 接続の場合は、 鍵データベース・パスワードを pac_keyring.pwd ファイルに入れます。 (pac_keyring.pwd ファイルは iKeyman の生成する stash ファイルではないことに注目してください。)
新規の鍵ペアと証明書要求を作成する
鍵データベースは、鍵ペアと証明書要求を保管します。公開鍵と秘密鍵のペアおよび証明書要求を作成するには、次のようにします。
A new certificate request has been successfully created
in the file keyfile_database_name.
自己署名の証明書を作成する
証明書が発行されるのを待つ間に、鍵管理ユーティリティーを使用して自己署名のサーバー証明書を作成し、クライアントとプロキシー・サーバー間の SSL セッションを使用可能にすることができます。 また、この自己署名の証明書はテスト目的にも使用できます。
次の手順に従って、自己署名の証明書を作成します。
鍵をエクスポートする
次の手順を使用して、鍵を別の鍵データベースにエクスポートします。
鍵をインポートする
別の鍵データベースから鍵をインポートするには、次のようにします。
認証局のリスト表示
鍵データベース中のトラステッド認証局 (CA) のリストを表示するには、次のようにします。
この手順は、デフォルトによってトラステッド CA として指定された認証局 (CA) から電子メールで送信されてきた証明書を受け取るために使用します (認証局のリストを参照)。 CA の署名済み証明書を発行する CA が、鍵データベースのトラステッド CA でない場合は、まず CA の証明書を保管し、その CA をトラステッド CA に指定しなければなりません。 そうすれば、CA の署名済み証明書を、データベースに受け入れることができます。 トラステッド CA 以外の CA から、CA の署名済み証明書を受け取ることはできません。(CA の証明書を保管するを参照)
CA の署名入り証明書を鍵データベースに受け入れるには、次のようにします。
セキュア接続を確立するために、トラステッド CA によって署名された証明書のみが受け入れられます。 トラステッド認証局のリストに CA を追加するには、そのトラステッド証明書を取得し、保管する必要があります。新規 の CA から発行された証明書を保管するには、それをデータベースに受け入れる前に 次の手順に従います。
鍵データベースのデフォルト鍵を表示する
次の手順でデフォルトの鍵項目を表示します。
SSL のバージョン 2 および 3 で使用されている、暗号化アルゴリズムとハッシュを次の表に示します。
鍵ペアの生成: RSA 512 - 1024 秘密鍵のサイズ
SSL バージョン 2
米国内バージョン | エクスポート・バージョン |
RC4 US | RC4 エクスポート |
RC2 US | RC2 エクスポート |
DES 56 ビット | 適用不可 |
Triple DES US | 適用不可 |
RC4 エクスポート | 適用不可 |
RC2 エクスポート | 適用不可 |
SSL バージョン 3
米国内バージョン | エクスポート・バージョン |
Triple DES SHA US | DES SHA エクスポート |
DES SHA エクスポート | RC2 MD5 エクスポート |
RC2 MD5 エクスポート | RC4 MD5 エクスポート |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 エクスポート | NULL NULL |
RC4 SHA 56 ビット | 適用不可 |
DES CBC SHA | 適用不可 |
NULL SHA | 適用不可 |
NULL MD5 | 適用不可 |
NULL NULL | 適用不可 |
これらの SSL 仕様は、プロキシー構成ファイルを直接に編集しても構成できます。詳しくは、以下のディレクティブの 付録B. 構成ファイル・ディレクティブの該当するセクションを参照してください。
Caching Proxy の場合の 128 ビット暗号化
Caching Proxy の 128 ビット暗号化バージョンのみが出荷されます。56 ビット・バージョンは使用できなくなりました。直前のバージョンを更新する場合には、現在インストール済みの 128 ビットまたは 56 ビット・バージョンに Caching Proxy を直接インストールすることができます。これまで 56 ビット (エクスポート) ブラウザーを使用していた場合には、プロキシーで 128 ビット暗号化を活用できるように、128 ビット・ブラウザーにアップグレードする必要があります。
Caching Proxy の 56 ビット・バージョンから 128 ビット・バージョンへのアップグレード後に、証明書の暗号化に使用される鍵のサイズが 1024 に設定されている場合には、構成の変更は不要です。 しかし、鍵のサイズが 512 に設定されている場合には、プロキシーの 128 ビット暗号化を活用できるように、鍵のサイズが 1024 の新規証明書を作成する必要があります。 IBM 鍵管理ユーティリティー (iKeyman) を使用して、新しい鍵を作成します。
IBM 鍵管理ユーティリティーの詳細な説明については、鍵および認証の管理を参照してください。
製品のこのバージョンでは、SUSE Linux での暗号化はサポートされないことに注意してください。