以下、添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
<第1の実施形態>
(システムの構成と管理表)
図1は、本発明の実施形態における中継処理システムの構成を示す図である。
尚、図1のネットワーク上に接続される各種端末と各種装置の構成は、一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
中継処理システムは、利用者端末110と中継処理装置120と情報提供処理装置150から構成される。利用者端末110と中継処理装置120、中継処理装置120と情報提供処理装置150とはそれぞれネットワークを介して相互に通信可能に接続されている。
利用者端末110は、本発明のクライアント端末の適用例である。また、中継処理装置120は、本発明の中継処理装置の適用例である。また、情報提供処理装置150は、本発明の情報処理装置の適用例である。
利用者端末110は、情報提供処理装置150が提供するコンテンツデータを取得し表示するために使用する情報処理装置である。利用者端末110は、閲覧処理部111と拡張機能処理部112と暗号鍵保存部113と管理表保存部114とCA証明書保存部115とを備えている。
閲覧処理部111は、一般にWebブラウザと呼ばれるHTTPプロトコル、HTTPSプロトコルのクライアントプログラムに相当する機能処理部である。閲覧処理部111は、利用者からの指示を受付け、中継処理装置120を経由して情報提供処理装置150へ通信要求メッセージを送信し、該通信要求メッセージに対して情報提供処理装置150から応答された通信応答メッセージを受信し、該通信応答メッセージを整形したものを利用者端末110のCRT210等に表示する機能を備えている。この時、閲覧処理部111と中継処理装置120のクライアント通信部121との間で開設される通信コネクションをプロキシ回線161とする。
ここで、プロキシ回線161(第1のSSL通信)は、利用者端末110と中継処理装置120との間で確立されるSSLによる暗号化通信であって、物理的な回線を示しているのではなく、暗号化通信を行う仮想的な(論理的な)通信を示している。プロキシ回線161(第1のSSL通信)は、後述する制御通信(制御回線162)とは、異なる通信である。
暗号鍵保存部113は、利用者端末の公開鍵証明書に対応する秘密鍵を記憶する記憶領域である。
閲覧処理部111は、情報提供処理装置150との間でHTTPSによる通信を行う場合で、かつ情報提供処理装置150からSSL(TLSを含む)のクライアント認証が要求された場合に、暗号鍵保存部113に記憶されている公開鍵証明書と秘密鍵を用いてクライアント認証要求に応答する機能を備えている。
拡張機能処理部112は、閲覧処理部111と相互に接続されており、閲覧処理部111の通信処理に対して割り込み処理を実行する機能を備える。また、拡張機能処理部112は、中継処理装置120の制御処理通信部128と通信することができ、HTTPS通信要求イベント発生時に、該HTTPS通信の通信方式を中継処理装置へ問い合わせる機能と、問い合わせた結果情報を利用者へ提示し確認もしくは選択を求める機能と、前記確認もしくは選択の結果の情報を中継処理装置へ送信する機能を備える。さらに、拡張機能処理部112は、HTTPS通信時に通信先である情報提供処理装置150がもつサーバ公開鍵証明書を制御処理通信部128から取得する機能と、該サーバ公開鍵証明書を検証する機能を備えている。さらに、拡張機能処理部112は、HTTPS通信時に通信先である情報提供処理装置150がクライアント認証を要求した場合には、暗号鍵保存部113に記憶されているクライアント公開鍵証明書情報を制御処理通信部128へ送信する機能と制御処理通信部128から送信される署名対象データ(メッセージダイジェスト)を受信し、該署名対象データに対して暗号鍵保存部113に記憶されているクライアント秘密鍵によって署名を行う機能と該署名データを制御処理通信部128へ送信する機能とを備えている。拡張機能処理部112と中継処理装置120の制御処理通信部128との間で開設(確立)される通信コネクションを制御回線162とする。
なお、制御回線162は、利用者端末110と中継処理装置120との間で、SSLによる暗号化通信の回線として開設(確立)される。これにより、利用者端末110は、中継処理装置120のなりすましを防止することが可能となる。
すなわち、中継処理装置120は、利用者端末110との間で制御通信(制御回線162)を確立する(通信確立手段)。ここで、制御通信(制御回線162)は、利用者端末110と中継処理装置120との間で確立されるSSLによる暗号化通信のコネクションであって、物理的な回線を示しているのではなく、暗号化通信を行う仮想的な(論理的な)通信路を示している。
中継処理装置120は、制御通信(制御回線162)の確立を、一般的なSSL通信の確立の手順で行う。
管理表保存部114は、クライアント通信方式キャッシュ表とサーバ証明書キャッシュ表を記憶する記憶領域である。
(クライアント通信方式キャッシュ表の説明)
クライアント通信方式キャッシュ表は、図16で一例を示しているようなデータ構造もつ記憶領域である。各行のレコードは、利用者端末110の閲覧処理部111が特定の情報提供処理装置150との通信方式を決定した際に該通信方式を保持するためのものである。レコードは、サーバ識別子欄と決定日時欄と通信方式欄とをもつ。
サーバ識別子欄は、通信先となる情報提供処理装置150を識別するための情報提供処理装置150のホスト名とTCPポート番号の組み合わせを保存する場所である。決定日時欄は、通信方式が決定された日時情報を保存する場所である。通信方式欄は、決定された通信方式を保存する場所である。
通信方式欄に保存される値としては、”直接”と”代理”との2つの種類がある。”直接”は、中継処理装置120において、HTTPS通信のSSLコネクションを終端せずに通常プロキシサーバにおいて行われるようにトンネリングする処理が行われることを意味する値である。”代理”は、中継処理装置120において、HTTPS通信のSSLコネクションを終端する中間者方式で処理されることを意味する値である。
クライアント通信方式キャッシュ表(図16)が保持している各レコードは、その決定日時の情報に基づきキャッシュがクリア(削除)される。例えば、利用者端末110により、各レコードが定期的に検査され、決定日時欄の値が検査日時と比較され適当に決められた有効時間(例えば6時間)以上古い日時を表している場合には削除される。また、利用者端末110の閲覧処理部111に相当するブラウザプロセスが終了した時には、表(図16)のすべてのレコードが削除されるものとする。
利用者端末110は、情報提供処理装置150へのアクセス要求があった時、クライアント通信方式キャッシュ表を参照し、該情報提供処理装置150との通信方式に関する情報の再利用が可能であれば、利用者に都度通信方式の確認または選択させる処理を行わずに通信を開始することができる。
(サーバ証明書キャッシュ表の説明)
サーバ証明書キャッシュ表は、図17で一例を示しているようなデータ構造もつ記憶領域である。各行のレコードは、利用者端末110が代理方式でアクセスしたことがある特定の情報提供処理装置150との通信時に使用したSSLセッションID(単にセッションIDとも言う)とサーバ公開鍵証明書を保持するためのものである。レコードは、サーバ識別子欄と最終利用日時欄とセッションID欄とサーバ証明書欄とをもつ。
サーバ識別子欄は、通信した情報提供処理装置150を識別するための情報で情報提供処理装置150のホスト名とTCPポート番号の組み合わせを保存する場所である。最終利用日時欄は、該レコードによって表される通信処理を実施した日時情報を保存する場所である。セッションID欄は、前記通信で中継処理装置120から通知されたSSLセッションIDの値を保存する場所である。サーバ証明書欄は、前記通信で中継処理装置120から取得した情報提供処理装置150のサーバ公開鍵証明書を保存する場所である。
サーバ証明書キャッシュ表が保持している各レコードは、定期的に検査され、通常ブラウザ等のソフトウェアである閲覧処理部111が管理しているSSLセッションキャッシュ情報(ブラウザがSSLセッション再開処理のためにキャッシュしている情報)と突き合わせ処理を行い、SSLセッションキャッシュ情報の中に同じセッションIDが存在しない場合には、該レコードは削除される。
利用者端末110が情報提供処理装置150に対して、中継処理装置120を経由して代理方式でアクセスする時で、かつ利用者端末110と中継処理装置120とのSSLセッションでセッション再開機能が利用された場合に、利用者端末110がサーバ証明書キャッシュ表を参照することにより、利用者端末110を操作する利用者による、前記情報提供処理装置150のサーバ公開鍵証明書の確認のための内容表示要求に対して、都度、中継処理装置120へアクセスすることなくサーバ証明書キャッシュ表のサーバ証明書欄の値を使って表示処理を行うことができる。すなわち、利用者端末110は、中継処理装置120へアクセスすることなくサーバ証明書キャッシュ表のサーバ証明書欄の値を表示することができる。
CA証明書保存部115は、情報提供処理装置150のサーバ公開鍵証明書を検証する際に用いる利用者端末110が信頼するCA証明書を記憶する記憶領域である。
中継処理装置120は、一般にプロキシサーバと呼ばれるプログラムまたは装置がもつ機能を備える情報処理装置である。中継処理装置120は、利用者端末110から送信される通信要求メッセージを受信し、宛先である情報提供処理装置150へ該通信要求メッセージを中継し、該情報提供処理装置150から応答される通信応答メッセージを、該利用者端末110へ中継することができる。
中継処理装置120は、クライアント通信部121と、サーバ通信部122と、クライアント側暗号処理部123と、通信制御部124と、サーバ側暗号処理部125と、代理用暗号鍵保存部126と、サーバ暗号鍵保存部127と、制御処理通信部128と、管理表保存部129と、付加機能処理部130と、CA証明書保存部131と、から構成される。
クライアント通信部121は、利用者端末110の閲覧処理部111から接続要求を受け付け、通信要求メッセージを受信し、通信応答メッセージを閲覧処理部111に送信する機能を備える。
サーバ通信部122は、情報提供処理装置150のサーバ処理部151へ接続し、通信要求メッセージを送信し、通信応答メッセージをサーバ処理部151から受信する機能を備える。
クライアント側暗号処理部123は、中継処理装置120における通信方式が代理方式の場合に、利用者端末110の閲覧処理部111との通信回線(プロキシ回線161)において、SSL(TLSを含む)を確立するためのサーバ側処理を行う機能を備える。
通信制御部124は、クライアント通信部121が行う処理と、クライアント側暗号処理部123が行う処理と、付加機能処理部130が行う処理と、サーバ通信部122が行う処理と、サーバ側暗号処理部125が行う処理と、制御処理通信部128が行う処理と、の間で同期制御処理を行う機能をもつ。また、通信制御部124は、該同期制御処理において関連する情報を、管理表保存部129へ記憶させる機能と、管理表保存部129を参照する機能と、を備えている。
サーバ側暗号処理部125は、中継処理装置120における通信方式が代理方式の場合に、情報提供処理装置150のサーバ処理部151との通信回線(サーバ回線163)において、SSL(TLSを含む)コネクションのクライアント側処理を行う機能を備える。
ここで、サーバ回線163(第2のSSL通信)は、中継処理装置120と情報提供処理装置150との間で確立されるSSLによる暗号化通信であって、物理的な回線を示しているのではなく、暗号化通信を行う仮想的な(論理的な)通信である。
図1の例では、1つの物理的な通信回線を介して利用者端末110と中継処理装置120が相互に通信可能に接続されている。また、図1の例では、中継処理装置120と情報提供処理装置150とが相互に通信可能に接続されている。
代理用暗号鍵保存部126は、中継処理装置120における通信方式が代理方式の場合に、前記プロキシ回線161 上のSSL(TLSを含む)ハンドシェイク処理の中で利用されるサーバ公開鍵証明書と秘密鍵を記憶している記憶領域である。
制御処理通信部128は、HTTPSサーバとしての機能を備える機能処理部であり、利用者端末110の拡張機能処理部112との間で安全な通信コネクション(前記制御回線162)を開設し、利用者端末110の拡張機能処理部112が送信する通信要求メッセージを受信する機能と、利用者端末110の拡張機能処理部112へ通信応答メッセージを送信する機能と、利用者端末110の拡張機能処理部112からの特定の通信先に関する通信方式の問い合わせに対して、管理表保存部129の通信方式決定表の情報に基づいて通信方式を回答する機能と、利用者端末110の拡張機能処理部112から特定の通信先に関する通信方式の決定情報を受信し、該決定情報を管理表保存部129のプロキシ通信方式キャッシュ表に保存する機能と、利用者端末110の拡張機能処理部112へ情報提供処理装置150のサーバ公開鍵証明書を送信する機能と、利用者端末110の拡張機能処理部112からサーバ公開鍵証明書の検証結果を受信する機能と、通信制御部124へ検証結果を通知する機能と、利用者端末110の拡張機能処理部112へクライアント認証要求情報を送信する機能と、利用者端末110の拡張機能処理部112からクライアント公開鍵証明書を受信する機能と、通信制御部124から署名対象データを受信する機能と、利用者端末110の拡張機能処理部112へ前記署名対象データを送信する機能と、利用者端末110の拡張機能処理部112から署名データを受信する機能と、通信制御部124へ前記署名データを通知する機能と、を備える。
サーバ暗号鍵保存部127は、前記制御回線162上のSSL(TLSを含む)ハンドシェイク処理の中で利用されるサーバ公開鍵証明書と秘密鍵を記憶している記憶領域である。
管理表保存部129は、通信方式決定表とプロキシ通信方式キャッシュ表と代理通信セッション管理表を記憶するための記憶領域である。
(通信方式決定表の説明)
通信方式決定表(図8)は、プロキシ回線161によるHTTPS通信に先立ち、該HTTPS通信をどのように中継するか(通信方式)を決定するために使用される表である。通信方式決定表のレコードは、サーバ条件とクライアント条件と通信方式から構成される。通信方式決定表の例を図8で示す。通信方式決定表(図8)は、通信方式設定情報の適用例である。
サーバ条件はドメイン名欄とカテゴリー欄から構成される。ドメイン名欄は、通信における情報提供処理装置150のホスト名の文字列条件を保存する場所である。「*」はワイルドカード文字列を表し、任意の文字列にマッチする。カテゴリー欄は、通信における情報提供処理装置150のカテゴリーを保存する場所である。カテゴリーとは、任意の情報提供処理装置150がその提供するコンテンツに応じて属する分野のことである。中継処理装置120は、利用者端末110から送信される暗号化通信の要求イベントに含まれるURL(ホスト名を含む)に従って、当該URLのカテゴリーを判定する。例として、中継処理装置120が予めホスト名とカテゴリーとの対応を示す対応表を備え、当該対応表を参照して、利用者端末110から入力された当該URLのホスト名に対応するカテゴリーを決定(判定)することなどが考えられる。
ここで、サーバ条件は、利用者端末110から送信されるデータの中継先の情報提供処理装置150を示す中継先情報の適用例である。
クライアント条件は、アドレス欄と認証グループ欄から構成される。アドレス欄は、通信における利用者端末のIPアドレス条件を保存する場所である。IPアドレスの個別指定の他、ワイルドカード文字列やネットワークアドレス表現によって、複数のアドレスを表すことができる。認証グループ欄は、利用者端末110の利用者が属するグループ名を保存する場所である。
通信方式欄は、確立が許可された通信方式を保存する場所である。すなわち、通信方式欄は、データの中継を可能とするために、確立が許可された通信方式(通信方式情報)が設定されている。
通信方式欄に保存される値としては、”直接”(直接通信方式)と”代理”(代理通信方式)と”選択”の3つの種類がある。”直接”は、中継処理装置120においてHTTPS通信のSSL(TLSを含む)コネクションを終端せずに通常プロキシサーバにおいて行われるようにトンネリングする処理を指示する値である。”代理”は、中継処理装置120においてHTTPS通信のSSLコネクションを終端する中間者方式を指示する値である。”選択”(選択情報)は利用者端末110の利用者に直接方式か代理方式かを選択させることを指示する値である。
(プロキシ通信方式キャッシュ表の説明)
プロキシ通信方式キャッシュ表(図9)は、特定のHTTPS通信に対して適用する通信方式を記憶するために利用される表である。プロキシ通信方式キャッシュ表のレコードは、クライアント識別子欄、サーバ識別子欄、有効期限欄、通信方式欄から構成される。プロキシ通信方式キャッシュ表の例を図9で示す。
クライアント識別子欄は、利用者端末110の閲覧処理部111を識別するための情報(利用者端末を特定するクライアント特定情報)として、利用者端末110のIPアドレスと閲覧処理部111の識別子(閲覧処理部識別子)を組み合わせた情報を保存する場所である。閲覧処理部識別子は、例えばプロセスIDを使うことが想定される。サーバ識別子欄は、情報提供処理装置150を識別するための情報として、情報提供処理装置150のホスト名とTCPポート番号の組み合わせた情報を保存する場所である。有効期限欄は、対象レコードの有効期限情報を保存する場所である。通信方式欄は、決定された通信方式を保存する場所である。
プロキシ通信方式キャッシュ表が保持している各レコードは、中継処理装置120により、定期的に検査され、有効期限欄の日時が、検査日時より古い場合には削除される。
(代理通信セッション管理表の説明)
代理通信セッション管理表(図10)は、代理方式で中継する通信に関するセッション情報を記憶しておくために利用される表である。代理通信セッション管理表のレコードは、クライアント識別子欄、サーバ識別子欄、最終利用日時欄、クライアント側ハンドシェイク情報(セッションID―C欄、共通鍵その他―C欄、クライアント証明書欄)、サーバ側ハンドシェイク情報(セッションID―S欄、共通鍵その他―S欄、サーバ証明書欄、クライアント認証要求欄)から構成される。代理通信セッション管理表の例を図10で示す。
クライアント識別子欄は、利用者端末110の閲覧処理部111を識別するための情報として利用者端末110のIPアドレスと閲覧処理部111の識別子(閲覧処理部識別子)を組み合わせた情報を保存する場所である。サーバ識別子欄は、情報提供処理装置150を識別するための情報として情報提供処理装置150のホスト名とTCPポート番号の組み合わせた情報を保存する場所である。最終利用日時欄は、対象レコードによって表される通信が行われた日時情報を保存する場所である。セッションID―C欄は、プロキシ回線161上のSSLセッションのIDを保存する場所である。共通鍵その他―C欄は、プロキシ回線161上のSSLセッションのハンドシェイク処理で交換した共通鍵と暗号スイートに関する情報を保存する場所である。クライアント証明書欄は、利用者端末110から取得したクライアント公開鍵証明書を保存する場所である。セッションID―S欄は、サーバ回線163上のSSLセッションのIDを保存する場所である。共通鍵その他―S欄は、サーバ回線163上のSSLセッションのハンドシェイク処理で交換した共通鍵と暗号スイートに関する情報を保存する場所である。サーバ証明書欄は、サーバ回線163上のSSLセッションのハンドシェイク処理で取得した情報提供処理装置150のサーバ公開鍵証明書を保存する場所である。クライアント認証要求欄は、サーバ回線163上のSSLセッションのハンドシェイク処理で取得した情報提供処理装置150からのクライアント認証要求情報を保存する場所である。
代理通信セッション管理表が保持している各レコードは、中継処理装置120により、定期的に検査され、最終利用日時欄の値が、検査日時と比較され、適当に決められた有効時間(例えば12時間)以上古い日時を表している場合には削除される。
付加機能処理部130は、中継処理対象の通信がHTTPの場合と、HTTPSの場合でも中継方式が代理方式の場合に、利用者端末110から受信する通信要求メッセージと情報提供処理装置150から受信する通信応答メッセージとに対して、付加機能処理を行う機能を備える。付加機能処理とは、例えば、プロキシサーバにおいて一般に実施されるキャッシュ機能や、セキュリティゲートウェイ等で実施されるコンテンツフィルタリング機能、ウィルス検査・駆除機能、アクセス制御機能などに対応している。これらの機能は、通常はHTTPS通信のように通信メッセージが暗号化されている場合には適用(実施)できないが、本実施例に示す代理方式のようにHTTPS通信であっても中継処理装置において暗号化通信メッセージを平文化する手法を用いれば適用(実施)できるようになる。
CA証明書保存部131は、情報提供処理装置150のサーバ公開鍵証明書を検証する際に用いる、中継処理装置120が信頼するCA証明書を記憶する記憶領域である。
情報提供処理装置150は、利用者端末110から送られた通信要求メッセージを受信し、該通信要求メッセージの内容に基づき通信応答メッセージを応答する情報処理装置である。情報提供処理装置150は、サーバ処理部151とサーバ暗号鍵保存部152とを備えている。
サーバ処理部151は、一般にWebサーバと知られるプログラムに相当する機能処理部である。サーバ処理部151はHTTPプロトコルとHTTPSプロトコルのサーバ機能を備えている。
サーバ暗号鍵保存部152は、サーバ処理部151がHTTPSによる暗号化通信を行う場合に使用するサーバ公開鍵証明書と秘密鍵を記憶するための記憶領域である。
次に、図1の利用者端末110、中継処理装置120、情報提供処理装置150の各種端末のハードウェア構成について、図2を用いて説明する。利用者端末110、中継処理装置120、情報提供処理装置150は、一般に知られている情報処理装置である。
図2は、本発明の実施形態における各種端末のハードウェア構成を示す図である。
CPU201は、システムバス204に接続される各デバイスやコントローラを統括的に制御する。
また、ROM202あるいは外部メモリ211には、CPU201の制御プログラムであるBIOS(Basic Input / Output System)やオペレーティングシステムプログラム(以下、OS)や、各サーバ或いは各PCの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。RAM203は、CPU201の主メモリ、ワークエリア等として機能する。
CPU201は、処理の実行に際して必要なプログラム等をRAM203にロードして、プログラムを実行することで各種動作を実現するものである。
また、入力コントローラ(入力C)205は、キーボード209や不図示のマウス等のポインティングデバイスからの入力を制御する。
ビデオコントローラ(VC)206は、CRTディスプレイ(CRT)210等の表示器にへの表示を制御する。表示器はCRTだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。
メモリコントローラ(MC)207は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク(HD)やフロッピーディスク(登録商標 FD)或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュメモリ等の外部メモリ211へのアクセスを制御する。
通信I/Fコントローラ(通信I/FC)208は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いたインターネット通信等が可能である。
なお、CPU201は、例えばRAM203内の表示情報用領域へアウトラインフォントの展開(ラスタライズ)処理を実行することにより、CRT210上での表示を可能としている。また、CPU201は、CRT210上の不図示のマウスカーソル等でのユーザ指示を可能とする。
本発明を実現するためのプログラムは外部メモリ211に記録されており、必要に応じてRAM203にロードされることによりCPU201によって実行されるものである。さらに、本発明に係わるプログラムが用いる前述した暗号鍵保存部113、管理表保存部114、CA証明書保存部115、代理用暗号鍵保存部126、サーバ暗号鍵保存部127、管理表保存部129、CA証明書保存部131、及びサーバ暗号鍵保存部152は、外部メモリ211に格納されている。
(暗号化通信を代理方式によって中継する場合の通信メッセージ交換フロー)
次に、暗号化通信を介して通信されるデータを代理方式によって中継する場合の、利用者端末110と中継処理装置120と情報提供処理装置150との間の通信メッセージの交換フローの1つのケースを、図11を用いて説明する。
図11は、本発明の実施形態における暗号化通信を介して通信されるデータを代理方式によって中継する場合の、利用者端末110と中継処理装置120と情報提供処理装置150との間の通信メッセージの交換フローの例を示す図である。
なお、図11中のステップS1150からステップS1154で示される破線で囲われた通信は、制御回線162を介して行われる。それ以外の利用者端末110と中継処理装置120との間の通信は、プロキシ回線161を介して行われる。
また、中継処理装置120と情報提供処理装置150との間の通信は、サーバ回線163を介して行われる。
また、図11と図12においては、SSL(TLSを含む)規格において必要とされるメッセージ(ChangeCipherSpec等)は、一般的なSSL(TLSを含む)規格に基づく、一般に知られている処理であるため、ここでは説明を省略している。
ステップS1101では、利用者端末110において、利用者が閲覧処理部111が提供するブラウザ画面において、情報提供処理装置150上のコンテンツを指し示すURLをアドレスバーなどへ入力するか、または既にブラウザ画面に表示中のコンテンツの中の該URLへのリンク文字列をクリックするか、によってコンテンツ取得要求が指示される。
ステップS1102では、コンテンツ取得要求に対して閲覧処理部111に登録されたイベントハンドラによって拡張機能処理部112の処理が起動される。拡張機能処理部112では、該コンテンツ取得要求に含まれる該URLのスキーマ部を取得し、該スキーマがHTTPS(暗号化通信)であるか否かを判定する。すなわち、利用者端末110は、コンテンツ取得要求に含まれる暗号化通信によるデータの送受信を要求しているのか否かを判定する。
そして、利用者端末110は、該スキーマがHTTPSである(暗号化通信を介したデータの送受信の要求である)と判定された場合、中継処理装置120における通信方式を決定するために、中継処理装置120に対して通信方式の問い合わせを行う。すなわち、利用者端末110は、後述する通信方式問い合わせ要求メッセージを中継処理装置120に送信する。
ステップS1103では、中継処理装置120は、利用者端末110から送信された問い合わせ(通信方式問い合わせ要求メッセージ)に含まれる情報提供処理装置150の識別子(サーバ識別子)と利用者端末110の閲覧処理部識別子(クライアント識別子)との情報を元に、管理表保存部129の通信方式決定表(図8)から通信方式を決定し、該通信方式を利用者端末110へ応答する。この例では”選択”が応答される。
すなわち、中継処理装置120は、通信方式が“選択”と決定された場合、例えば、図14に示すダイアログボックス(通信方式選択ダイアログボックスとも言う)の画面を表示するための画面情報を、利用者端末110に送信する。
ステップS1104では、利用者端末110は、ステップS1103で受信した通信方式が”選択”であったため、図14で例を示すような画面(選択ダイアログボックスとも言う)を表示する。
すなわち、ステップS1103で送信された画面情報に従って、図14の画面を表示する。
ステップS1105では、利用者端末110において、利用者は前記選択ダイアログボックスを使用して”直接”、”代理”のいずれかから通信方式を選択する。例では利用者は”許可する”を選択して通信方式”代理”が選択される。
すなわち、ステップS1105では、利用者により、選択ダイアログボックスを介して、”許可する”ボタンか、”許可しない”ボタンが押下され、”許可する”ボタンが押下された場合は、通信方式が“代理”と決定され、”許可しない”ボタンが押下された場合は、通信方式が“直接”と決定される。ここの例では、利用者により”許可する”ボタンが選択され通信方式が”代理”と決定される。
ステップS1106では、利用者端末110は、選択結果(通信方式通知メッセージとも言う)(ここでの例では選択方式としての”代理”と、サーバ識別子と、クライアント識別子と、有効期限とが通信方式通知メッセージに含まれる。)を中継処理装置120へ送信する。
中継処理装置120は該選択結果を受信し、該選択結果(”代理”)を管理表保存部129のプロキシ通信方式キャッシュ表(図9)に保存する。
ステップS1107では、利用者端末110は、コンテンツ取得要求に関する通信方式を決定され、中継処理装置120への通信方式通知メッセージの通知(送信)も完了したことを受けて、閲覧処理部111が該コンテンツ取得要求の処理を再開する。閲覧処理部111は、中継処理装置120のクライアント通信部121へ接続してプロキシ回線161を開設し、該プロキシ回線161上でCONNECTメソッドによるプロキシリクエストを送信する。CONNECTメソッドによるプロキシリクエストとは、Webブラウザ等のクライアントがプロキシサーバを経由してHTTPSサーバへ接続する際に発行されるリクエストであり、次の形式をもつ。
CONNECT ホスト名:ポート番号 HTTP/1.0
また、拡張機能処理部112は、閲覧処理部111に、上記のプロキシリクエストにクライアント識別子をヘッダーとして追加するよう指示する。
プロキシリクエストの例を示す。
CONNECT www.xxx.co.jp:443 HTTP/1.0
User―Agent: XXXXX/X.X
X―client―id: 10.10.10.1:349263
次に、中継処理装置120は、受信した前記プロキシリクエストから、サーバ識別子(ホスト名:ポート番号)とクライアント識別子(X―client―id)を取得し、これらをキーに管理表保存部129のプロキシ通信方式キャッシュ表から通信方式欄を参照し、値”代理”を取得する。そして、中継処理装置120は、代理方式の中継処理の情報を管理するための記憶領域として、管理表保存部129の代理通信セッション管理表に新規レコード(代理通信セッションレコードと呼ぶ)を作成する。
ステップS1108では、中継処理装置120は、サーバ識別子の情報を元に情報提供処理装置150へTCP接続し、サーバ回線163を開設する。
ステップS1109では、中継処理装置120は、TCP接続が成功したことを受け、利用者端末110へ「HTTP/1.0 200」という接続成功メッセージを返し、情報提供処理装置150へ中継可能であることを伝える。
ステップS1110では、利用者端末110は、前記プロキシ回線161上でClient Helloメッセージを送信し、SSLのハンドシェイクを開始する。
そして、Client Helloメッセージを受けた中継処理装置120は、SSLのハンドシェイクの処理を開始し、ステップS1133でハンドシェイクの処理が終了するまで、プロキシ回線161を確立する処理を行う。
SSLによる暗号化通信の回線を確立するために、ステップS1110からハンドシェイクの処理を開始する。そして、ステップS1133でハンドシェイクの処理が終了すると、プロキシ回線161(SSLによる暗号化通信の回線)を確立することができる。プロキシ回線161は、本発明の第1のSSL通信の適用例である。
ステップS1111では、中継処理装置120は、サーバ回線163上で、情報提供処理装置150との間でSSLのセッションを開設(確立)するために、サーバ側暗号処理部125で生成したClient Helloメッセージを送信する。
そして、Client Helloメッセージを受けた情報提供処理装置150は、SSLのハンドシェイクの処理を開始し、ステップS1131でハンドシェイクの処理が終了するまで、サーバ回線163を確立する処理を行う。
SSLによる暗号化通信の回線を確立するために、ステップS1111からハンドシェイクの処理を開始する。そして、ステップS1131でハンドシェイクの処理が終了すると、サーバ回線163(SSLによる暗号化通信の回線)を確立することができる。サーバ回線163は、本発明の第2のSSL通信の適用例である。
ステップS1111では、中継処理装置は、前記サーバ回線163上でSSL Client Helloメッセージを送信し、SSLハンドシェイクを開始する。
SSLによる暗号化通信の回線を確立するために、ステップS1110でハンドシェイクの処理を開始する。そして、ステップS1133でハンドシェイクの処理が終了すると、プロキシ回線161(SSLによる暗号化通信の回線)を確立することができる。プロキシ回線161は、本発明の第1のSSL通信の適用例である。
以下にステップS1110以降の処理について説明する。
図11は、通信方式が”代理”(代理方式)の場合について説明する。
まず、利用者端末110は、ステップS1110でSSLハンドシェイク開始要求(SSL Client Hello)を送信する。
図11は、通信方式が”代理”の場合のシーケンス図であるので、中継処理装置120は、該SSLハンドシェイクで受信した各メッセージは、そのまま情報提供処理装置150へ中継せずに、自身がサーバとしてハンドシェイクを行う。
中継処理装置120は、自身がサーバとしてハンドシェイクの処理に応じるために、利用者端末110に、SSL Server Hello、SSL Server Certificate、SSL Server Hello Doneの各メッセージを送信する。
まず、利用者端末110の閲覧処理部111は、過去に中継処理装置120との通信で利用したSSLのセッション情報(セッションIDを含む)が記憶されているか否かを判定する。
そして、利用者端末110の閲覧処理部111は、過去に中継処理装置120との通信で利用したSSLのセッションIDが記憶されていると判定された場合は、当該セッションIDを含めたSSL Client Helloメッセージを中継処理装置120に送信する。
一方、利用者端末110の閲覧処理部111は、過去に中継処理装置120との通信で利用したSSLのセッションIDが記憶されていないと判定された場合は、当該セッションIDを含めずにSSL Client Helloメッセージを中継処理装置120に送信する。
そして、中継処理装置120は、利用者端末110からSSL Client Helloメッセージを受信する。
図11では、利用者端末111から受信したSSL Client Helloメッセージに当該セッションIDが含まれていない場合(SSLセッションを再開せずに新規のSSLセッションを用いる場合)について説明する。
利用者端末111から受信したSSL Client Helloメッセージに当該セッションIDが含まれている場合(SSLセッションを再開する場合)については、図12を用いて後で説明する。
中継処理装置120は、ステップS1110で利用者端末110からSSL Client Helloメッセージを受信すると、当該SSL Client Helloメッセージの中に、セッションIDが含まれているか否かを判定する。そして、中継処理装置120は、当該SSL Client Helloメッセージの中に、セッションIDが含まれていないと判定された場合に、新規のセッションを作成するために新規の固有のセッションIDを生成する。
そして、中継処理装置120は、当該生成されたセッションIDを含むSSL Server Helloメッセージを利用者端末110に送信する(ステップS1112)。
さらに、中継処理装置120は、当該生成されたセッションIDを代理通信セッション管理表(図10)のセッションIDーC欄に記憶する。当該セッションIDは次回以降にセッションを再開する場合の識別子となる。
利用者端末110は、セッションIDを含むSSL Server Helloメッセージを中継処理装置120から受信すると、当該SSL Server Helloメッセージに含まれているセッションIDをSSLのセッション情報としてRAM203等のメモリに記憶する(キャッシュする)。
次に、中継処理装置120は、代理用暗号鍵保存部に記憶されているサーバ公開鍵証明書を含むSSL Server Certificateメッセージを利用者端末110に送信する(ステップS1113)。
利用者端末110は、中継処理装置120からSSL Server Certificateメッセージを受信し、外部メモリ211などのメモリに記憶する。
そして、中継処理装置120は、中継処理装置120での一連の処理の終了を通知するSSL Server Hello Doneメッセージを利用者端末110に送信する(ステップS1114)。
利用者端末110は、中継処理装置120からSSL Server Hello Doneメッセージを受信すると、マスターシークレット(データの暗号化及び復号化に用いる共通鍵を生成するための情報)を生成する。
また、利用者端末110は、ここで生成されたマスターシークレットに従って、プロキシ回線161を介して中継処理装置120と通信する対象となるデータの暗号化及び復号を行うために用いる共通鍵を生成して、当該生成された共通鍵をRAM203等のメモリに記憶する。
利用者端末110は、ステップS1134以降の処理で、プロキシ回線161を介してデータを中継処理装置120に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。
また、利用者端末110は、中継処理装置120からプロキシ回線161を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
そして、利用者端末110は、中継処理装置120から受信したSSL Server Certificateメッセージに含まれているサーバ公開鍵証明書に含まれるサーバの公開鍵を用いて、当該生成されたマスターシークレットを暗号化する。
そして、利用者端末110は、当該暗号化されたマスターシークレットを含むClientKeyExchangeメッセージを中継処理装置120に送信する。
中継処理装置120は、利用者端末110からClientKeyExchangeメッセージを受信する。
そして、中継処理装置は、当該ClientKeyExchangeメッセージに含まれている暗号化されたマスターシークレットを、利用者端末110に送信したSSL Server Certificateメッセージに含まれるサーバ公開鍵証明書(サーバの公開鍵を含む)に対応する秘密鍵を用いて復号する。
なお、ここで用いる秘密鍵は、サーバ公開鍵証明書(サーバの公開鍵を含む)に対応付けられて代理用暗号鍵保存部126に記憶されており、利用者端末110に送信したサーバ公開鍵証明書(サーバの公開鍵を含む)に対応するものである。
次に、中継処理装置120は、復号されたマスターシークレットに従って共通鍵を生成する。そして、中継処理装置120は、該生成された共通鍵の情報を前記代理通信セッションレコードの共通鍵その他ーC欄に記憶する。
中継処理装置120は、ステップS1134以降の処理で、プロキシ回線161を介してデータを利用者端末110に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。また、中継処理装置120は、利用者端末110からプロキシ回線161を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
次に、ステップS1115以降の処理について説明する。
中継処理装置120は、利用者端末110からSSL Client Helloメッセージを受信すると、中継処理装置120をクライアントとして、情報提供処理装置150に、SSLハンドシェイク開始要求(SSL Client Helloメッセージ)を送信する(ステップS1111)。
情報提供処理装置150は、中継処理装置120から受信したSSL Client Helloメッセージに応答して、中継処理装置120に、SSL Server Helloメッセージ(ステップS1115)、SSL Server Certificateメッセージ(ステップS1116)、SSL Certificate Requestメッセージ(ステップS1117)、SSL Server Hello Doneメッセージ(ステップS1118)の各メッセージを送信する。
以下に、ステップS1115からステップS1118について、説明する。
まず、中継処理装置120は、過去に情報提供処理装置150との通信で利用したSSLのセッション情報(セッションID)が記憶されているか否かを判定する。
具体的には、過去に、代理方式で、利用者端末110と情報提供処理装置150とが中継処理装置120を介して通信する際に、中継処理装置120と情報提供処理装置150との間のサーバ回線163で利用したセッションIDが、代理通信セッション管理表(図10)のセッションID−Sの欄に記憶されているか否かを中継処理装置120が判定する。
そして、中継処理装置120は、過去に、代理方式で、利用者端末110と情報提供処理装置150とが中継処理装置120を介して通信する際に、中継処理装置120と情報提供処理装置150との間のサーバ回線163で利用したセッションIDが、代理通信セッション管理表(図10)のセッションID−Sの欄に記憶されていると判定された場合は、当該セッションIDを含めたSSL Client Helloメッセージを情報提供処理装置150に送信する。
一方、中継処理装置120は、過去に、代理方式で、利用者端末110と情報提供処理装置150とが中継処理装置120を介して通信する際に、中継処理装置120と情報提供処理装置150との間のサーバ回線163で利用したセッションIDが、代理通信セッション管理表(図10)のセッションID−Sの欄に記憶されていないと判定された場合は、当該セッションIDを含めずにSSL Client Helloメッセージを情報提供処理装置150に送信する(S1111)。
そして、情報提供処理装置150は、中継処理装置120からSSL Client Helloメッセージを受信する。
図11では、中継処理装置120から受信したSSL Client Helloメッセージに当該セッションIDが含まれていない場合(SSLセッションを再開せずに新規のSSLセッションを用いる場合)について説明する。
中継処理装置120から受信したSSL Client Helloメッセージに当該セッションIDが含まれている場合(SSLセッションを再開する場合)については、図12を用いて後で説明する。
情報提供処理装置150は、ステップS1111で中継処理装置120からSSL Client Helloメッセージを受信すると、当該SSL Client Helloメッセージの中に、セッションIDが含まれているか否かを判定する。
そして、情報提供処理装置150は、当該SSL Client Helloメッセージの中に、セッションIDが含まれていないと判定された場合に、新規のセッションを作成するために新規の固有のセッションIDを生成する。
そして、情報提供処理装置150は、当該生成されたセッションIDを含むSSL Server Helloメッセージを中継処理装置120に送信する(ステップS1115)。
さらに、情報提供処理装置150は、当該生成されたセッションIDをSSLのセッション情報としてRAM203等のメモリに記憶する(キャッシュする)。
中継処理装置120は、セッションIDを含むSSL Server Helloメッセージを情報提供処理装置150から受信すると、当該SSL Server Helloメッセージに含まれているセッションIDを、代理通信セッション管理表(図10)のセッションIDーS欄に記憶する。当該セッションIDは次回以降にセッションを再開する場合の識別子となる。
次に、情報提供処理装置150は、サーバ暗号鍵保存部152に記憶されている情報提供処理装置150のサーバ公開鍵証明書を含むSSL Server Certificateメッセージを中継処理装置120に送信する。
ステップS1116では、中継処理装置120は、情報提供処理装置150から、SSL Server Certificateメッセージを受信し、該メッセージに含まれる情報提供処理装置150のサーバ公開鍵証明書を取得する。
中継処理装置120は、CA証明書保存部131に記憶されているCA公開鍵証明書などを使って該サーバ公開鍵証明書が信頼できるか否かの検証処理を実施する。ここでの例では、該検証が成功し、該サーバ公開鍵証明書を代理通信セッションレコードのサーバ証明書欄に保存する。
ステップS1117では、中継処理装置120は、情報提供処理装置150からSSL Certificate Request メッセージ(クライアント認証の要求情報)を受信し、該メッセージに含まれるクライアント認証に関する要求条件の情報(署名アルゴリズム、CA識別名)を、前記代理通信セッションレコードのクライアント認証要求欄に保存する。
そして、情報提供処理装置150は、情報提供処理装置150での一連の処理の終了を通知するSSL Server Hello Doneメッセージを中継処理装置120に送信する。
ステップS1118では、中継処理装置120は、情報提供処理装置150から、SSL Server Hello Doneメッセージを受信する。
ステップS1119では、利用者端末110は、制御回線162を使って中継処理装置120へ情報提供処理装置150のサーバ公開鍵証明の取得要求メッセージを送信する。
ステップS1120では、中継処理装置120は、利用者端末110から送信された取得要求メッセージに応答して、代理通信セッションレコードのサーバ証明書欄に保存された情報提供処理装置150のサーバ公開鍵証明を取得し、該サーバ公開鍵証明書を利用者端末110へ送信する。(送信手段)
ステップS1121では、利用者端末110は、受信した前記サーバ公開鍵証明書の検証処理を行う。まず、利用者端末110は、利用者端末110のCA証明書保存部115に記憶されている信頼するCA(認証局)の公開鍵証明書によって、該サーバ公開鍵証明書の信頼性を検証する。次に、利用者端末110は、該サーバ公開鍵証明書に記載されている主体者情報(CN属性又はSubjectAltName属性)が、情報提供処理装置150のホスト名と一致するかどうかを確認する。利用者端末110は、その他、該サーバ公開鍵証明書の有効期限、失効状態確認など一般にサーバ公開鍵証明書の信頼性を検証するための処理を実行する。
次に、通常のブラウザでは、サーバ公開鍵証明書の情報として表示されるのはステップS1113で受信した中継処理装置120のサーバ公開鍵証明書であるが、拡張機能処理部112と協働する閲覧処理部111は、図15に示すダイアログボックスを表示するなどして、ステップS1120で受信した情報提供処理装置150の前記サーバ公開鍵証明書の情報を、利用者に確認させる。
すなわち、閲覧処理部111は、ステップS1120で受信した情報提供処理装置150のサーバ公開鍵証明書の情報を含む画面(図15)を表示する。
また、利用者に一時的に確認させるだけでなく、ブラウザの画面上で表示中のコンテンツを提供した情報提供処理装置150のサーバ公開鍵証明書を利用者がいつでも参照できるように、該ダイアログボックスなどのサーバ公開鍵証明書の内容を確認するための手段を呼び出すボタン等をブラウザの画面上に付加しておく。そのブラウザの画面の例を図18で示す。
通常(通信方式が直接の場合)は、図18の1801で示す場所に、表示中のコンテンツを提供した情報提供処理装置150の識別名(ホスト名)が表示され、該情報提供処理装置150のサーバ公開鍵証明書を表示するためのリンクになっている。しかし、本発明の代理方式の場合は、ここには中継処理装置120の識別名と、中継処理装置120のサーバ公開鍵証明書に関する情報を表示することになる。
このため、図18の例では、1802で示す場所に、本来のコンテンツ提供者である情報提供処理装置150の識別名と、情報提供処理装置150のサーバ公開鍵証明書に関する情報を表示するようにしている。このように、代理方式であっても情報提供処理装置150の識別名と、情報提供処理装置150のサーバ公開鍵証明書に関する情報を利用者がいつでも確認できるようにすることによって、利用者へコンテンツの提供者の真正性に関わる情報の確認を行うための手段を提供している。
最後に、利用者端末110は、サーバ公開鍵証明書の検証が成功すれば、管理表保存部114のサーバ証明書キャッシュ表(図17)に新規レコードを作成し、情報提供処理装置150の該サーバ公開鍵証明書と、情報提供処理装置150の前記サーバ識別子と、ステップS1112のServer Helloメッセージに含まれたセッションIDとを共に保存する。
ステップS1122では、利用者端末110は、サーバ公開鍵証明書の検証に成功し、その検証結果を中継処理装置120へ通知する。
ステップS1123では、中継処理装置120は、代理通信セッションレコードのクライアント認証要求欄の値を確認し、代理通信セッションレコードのクライアント認証要求欄に値が格納されていると判定されると、ステップS1117において情報提供処理装置150からクライアント認証の要求があったと判定する。そして、中継処理装置120は、これ(クライアントの認証要求)に対応するために、利用者端末110へ、前記クライアント認証要求欄の値を含めたクライアント証明書要求メッセージを送信する。
ステップS1124では、利用者端末110は、中継処理装置120からクライアント証明書要求メッセージを受信すると、該クライアント認証要求で示された条件に合致する公開鍵証明書を、暗号鍵保存部113から検索し取得する。そして、利用者端末110は、該条件に合致する公開鍵証明書が複数ある場合は、通常のブラウザにおけるSSLクライアント認証時の動作と同じように、ダイアログボックスを表示するなどして、利用者にどの公開鍵証明書を使って情報提供処理装置150へ認証されるのかを選択させ、利用者端末110の公開鍵証明書を1つ決定する。
ステップS1125では、利用者端末110は、利用者端末110の公開鍵証明書を中継処理装置120へ送信する。
ステップS1126では、中継処理装置120は、利用者端末110の公開鍵証明書を利用者端末から受信し、代理通信セッションレコードのクライアント証明書欄に保存する。そして、中継処理装置120は、情報提供処理装置150へ、該公開鍵証明書を含むClient Certificateメッセージを送信する。すなわち、中継処理装置120は、利用者端末の公開鍵証明書を、サーバ回線163を介して情報提供処理装置150に送信する(公開鍵送信手段)。
次に、中継処理装置120は、マスターシークレット(データの暗号化及び復号化に用いる共通鍵を生成するための情報)を生成する。
また、中継処理装置120は、ここで生成されたマスターシークレットに従って、サーバ回線163を介して情報提供処理装置150と通信する対象となるデータの暗号化及び復号を行うために用いる共通鍵を生成して、当該生成された共通鍵を代理通信セッションレコード(図10)の共通鍵その他−Sの欄に記憶する。
中継処理装置120は、ステップS1135以降の処理で、サーバ回線163を介してデータを情報提供処理装置150に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。
また、中継処理装置120は、情報提供処理装置150からサーバ回線163を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
そして、中継処理装置120は、情報提供処理装置150から受信したSSL Server Certificateメッセージに含まれているサーバ公開鍵証明書に含まれるサーバの公開鍵を用いて、当該生成されたマスターシークレットを暗号化する。
そして、中継処理装置120は、当該暗号化されたマスターシークレットを含むClientKeyExchangeメッセージを情報提供処理装置150に送信する。
情報提供処理装置150は、中継処理装置120からClientKeyExchangeメッセージを受信する。
そして、情報提供処理装置150は、当該ClientKeyExchangeメッセージに含まれている暗号化されたマスターシークレットを、中継処理装置120に送信したSSL Server Certificateメッセージに含まれるサーバ公開鍵証明書(サーバの公開鍵を含む)に対応する秘密鍵を用いて復号する。
なお、ここで用いる秘密鍵は、サーバ公開鍵証明書(サーバの公開鍵を含む)に対応付けられてサーバ暗号鍵保存部152に記憶されており、情報提供処理装置150が中継処理装置120に送信したサーバ公開鍵証明書(サーバの公開鍵を含む)に対応するものである。
次に、情報提供処理装置150は、復号されたマスターシークレットに従って共通鍵を生成する。そして、情報提供処理装置150は、該生成された共通鍵の情報を、外部メモリ211などのメモリに記憶する。
中継処理装置120は、ステップS1135以降の処理で、サーバ回線163を介してデータを情報提供処理装置150に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。
また、中継処理装置120は、情報提供処理装置150からサーバ回線163を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
SSL(TLSを含む)の規約では、クライアント認証は、まず、利用者端末110と情報提供処理装置150が共有している情報(ハンドシェイクで互いに交換したメッセージを連結した情報のメッセージダイジェスト)に対して署名した情報(署名データ)を、利用者端末110が、情報提供処理装置150に送信する。すなわち、利用者端末110は、当該メッセージダイジェストを、利用者端末110がSSL Client Certificateメッセージで情報提供処理装置150へ送信した公開鍵に対応する秘密鍵で署名した情報(署名データ)を、情報提供処理装置150へ送信する。そして、情報提供処理装置150が、利用者端末110から受信した該署名データを該公開鍵で復号し、情報提供処理装置150のメモリに記憶されている、利用者端末110と共有している情報(該メッセージダイジェスト)と同一であるか否か判定することで、クライアント認証を実施している。
以降で説明するステップS1127からステップS1128は、利用者端末110と中継処理装置120とが連携して署名データを作成する処理を行う。
ステップS1127では、中継処理装置120は、それまで情報提供処理装置150とSSLのハンドシェイクで交換した各メッセージを連結したデータにハッシュ関数を適用したメッセージダイジェスト(署名対象データ)を生成する。そして、中継処理装置120は利用者端末110へ該署名対象データを送信する。
利用者端末110は、中継処理装置120から署名対象データを受信し、該署名対象データに対してステップS1125で送信した利用者端末110の公開鍵証明書に対応する秘密鍵で署名を行い(暗号化を行い)、署名データを作成する。
そして、ステップS1128では、利用者端末110は、中継処理装置120へ該署名データを送信する。そして、中継処理装置120は、利用者端末110から該署名データを受信する。
ステップS1129では、中継処理装置120は、該署名データを含むSSL Certificate Verifyメッセージを作成し、情報提供処理装置150へ送信する。
すなわち、中継処理装置120は、S1126で送信されたクライアント端末の公開鍵証明書に対応する秘密鍵を用いて署名対象データを暗号化することにより生成される署名データを、サーバ回線163を介して情報提供処理装置に送信する(署名データ送信手段)。
そして、情報提供処理装置150は、中継処理装置120から受信した該メッセージ(署名データ)を上記の方法で検証することによって、利用者端末110のクライアント認証を実施する。
ステップS1130、ステップS1131では、中継処理装置120と情報提供処理装置150とは相互にHandshake finishメッセージを交換し、サーバ回線163上のSSLハンドシェイクを終了し、SSLによる暗号化通信であるサーバ回線163を確立する。
ステップS1132、ステップS1133では、利用者端末110と中継処理装置120とは相互にHandshake finishメッセージを交換し、前記プロキシ回線161上のSSLハンドシェイクを終了し、SSLによる暗号化通信であるプロキシ回線161を確立する。
ステップS1134では、利用者端末110は、ステップS1101において発生したコンテンツ取得要求に対応する通信要求メッセージを、プロキシ回線161上のSSLハンドシェイクで取り決めた方法で暗号化した暗号化通信要求メッセージを、中継処理装置120へ送信する。
すなわち、利用者端末110は、ステップS1101において発生したコンテンツ取得要求に対応する通信要求メッセージを、中継処理装置120と共有している共通鍵を用いて暗号化して、当該暗号化された暗号化通信要求メッセージを中継処理装置120に送信する。
ステップS1135では、中継処理装置120は、利用者端末110から受信した暗号化通信要求メッセージを、利用者端末110と共有している共通鍵(代理通信セッション管理(図10)表の共通その他−Cに格納されている共通鍵)を用いて復号化し、当該復号することで得られる通信要求メッセージを取得する。そして、中継処理装置120は、付加機能処理部130において該通信要求メッセージへアクセス制御等の付加機能処理を実行する。この例ではアクセス制御処理を行い、アクセスが許可されるとする。
すなわち、中継処理装置120は、通信要求メッセージの内容を解析して、情報提供処理装置150への通信要求メッセージの送信を許可するか否かの判定を行うことによりアクセス制御処理を行い、情報提供処理装置150への通信要求メッセージの送信を許可すると判定された場合は、当該通信要求メッセージを情報提供処理装置150に送信するように制御する。一方、中継処理装置120は、情報提供処理装置150への通信要求メッセージの送信を許可しないと判定された場合は、当該通信要求メッセージを情報提供処理装置150には送信しないように制御する。
次に、該通信要求メッセージをサーバ回線163上のSSLハンドシェイクで取り決めた方法で暗号化した暗号化通信要求メッセージを生成し、該メッセージを情報提供処理装置150へ送信する。
すなわち、中継処理装置120は、通信要求メッセージを情報提供処理装置150に送信するように制御する場合、該通信要求メッセージを、情報提供処理装置150と共有している共通鍵(代理通信セッション管理(図10)表の共通その他−Sに格納されている共通鍵)を用いて暗号化して、当該暗号化することにより生成される暗号化通信要求メッセージを情報提供処理装置150へ送信する。
ステップS1136では、情報提供処理装置150は、中継処理装置120から受信した暗号化通信要求メッセージを中継処理装置120と共有している共通鍵を用いて復号化し、当該復号することにより通信要求メッセージを生成する。
そして、情報提供処理装置150は、中継処理装置120からの通信要求メッセージの応答メッセージとして通信応答メッセージを作成し、該通信応答メッセージを、中継処理装置120と共有している共通鍵を用いて暗号化して暗号化通信応答メッセージを生成し、該暗号化通信応答メッセージを中継処理装置120へ送信する。
ステップS1137では、中継処理装置120は、情報提供処理装置150から受信した暗号化通信応答メッセージを、情報提供処理装置150と共有している共通鍵(代理通信セッション管理(図10)表の共通その他−Sに格納されている共通鍵)を用いて復号化して通信応答メッセージを取得する。そして、中継処理装置120は、付加機能処理部130において該通信応答メッセージへアクセス制御等の付加機能処理を実行する。
すなわち、中継処理装置120は、通信応答メッセージの内容を解析することにより、利用者端末110への通信応答メッセージの送信を許可するか否かの判定を行うことによりアクセス制御処理を行う。ここでの例では、中継処理装置120は、付加機能処理として通信応答メッセージ内のウィルス検査処理を行い、その結果、通信応答メッセージにはウィルスが検知されなかったとする。
中継処理装置120は、利用者端末110への通信応答メッセージの送信を許可すると判定された場合は、当該通信応答メッセージを利用者端末110送信するように制御する。一方、中継処理装置120は、利用者端末110への通信応答メッセージの送信を許可しないと判定された場合は、当該通信応答メッセージを利用者端末110には送信しないように制御する。
次に、中継処理装置120は、当該通信応答メッセージを利用者端末110に送信するように制御する場合、該通信応答メッセージをプロキシ回線161上のSSLハンドシェイクで取り決めた方法で暗号化した暗号化通信応答メッセージを生成し、該メッセージを利用者端末110へ送信する。
すなわち、中継処理装置120は、当該通信応答メッセージを利用者端末110に送信するように制御する場合、該通信応答メッセージを、利用者端末110と共有している共通鍵(代理通信セッション管理(図10)表の共通その他−Cに格納されている共通鍵)を用いて暗号化することによって、暗号化通信応答メッセージを生成し、当該暗号化通信メッセージを利用者端末110に送信する。
利用者端末110は、中継処理装置120から受信した暗号化通信応答メッセージを、中継処理装置120と共有している共通鍵を用いて復号化することによって、通信応答メッセージを生成し、該通信応答メッセージを閲覧処理部111の画面へ表示するなどの処理を行う。
ステップS1138では、情報提供処理装置150は、SSLコネクションを終了するためにSSLアラートプロトコルによる終了通知メッセージを中継処理装置120へ送信する。
ステップS1139では、中継処理装置120は、同じく終了通知メッセージを、情報提供処理装置150へ送信する。これにより、サーバ回線163を終了させる。
ステップS1140において、中継処理装置120は、SSLコネクションを終了するためにSSLアラートプロトコルによる終了通知メッセージを利用者端末110へ送信する。
ステップS1141において、利用者端末110は、同じく終了通知メッセージを、中継処理装置120へ送信する。これにより、前記プロキシ回線161を終了させる。
上述したSSLの暗号化通信の確立手順は、一例であり、上述したメッセージ以外のメッセージを装置間で送受信して暗号化通信を確立するようにしてもよい。
以上で、SSLの暗号化通信(回線)を介して通信される通信データを、通信方式が代理方式(“代理”)の場合に、中継する際の通信メッセージ交換フローの例の説明を終了する。
(セッション再開機能による暗号化通信を代理方式によって中継する場合の通信メッセージ交換フロー)
次に、暗号化通信されるデータを代理方式によって中継する場合であり、かつ、プロキシ回線161のSSLコネクションとサーバ回線163のSSLコネクションとにおいてセッション再開機能によりSSLセッションを開設した場合の、利用者端末110と中継処理装置120と情報提供処理装置150との間の通信メッセージの交換フローについて、図12を用いて説明する。
図12は、暗号化通信されるデータを代理方式によって中継する場合であり、かつ、プロキシ回線161のSSLコネクションとサーバ回線163のSSLコネクションとにおいてセッション再開機能によりSSLセッションを開設した場合の、利用者端末110と中継処理装置120と情報提供処理装置150との間の通信メッセージの交換フローの例を示す図である。
セッション再開機能とは、過去に開設して終了させたセッションを再開するための機能であり、SSLにおいてセッションを新規に作成せずに再開させた場合はセッションを確立するために必要なセッション鍵(共通鍵)の生成、交換に関わる負荷の高い処理を省略できるために、性能向上のために利用される機能である。
なお、図12中の利用者端末110と中継処理装置120との間のすべての通信はプロキシ回線161上で行われる。
ステップS1201の処理は、前述したステップS1101の処理と同じである。
次に、利用者端末110は、ステップS1201におけるコンテンツ取得要求に対して閲覧処理部111に登録されたイベントハンドラによって、拡張機能処理部112の処理が起動される。利用者端末110の拡張機能処理部112では、該コンテンツ取得要求のURLのスキーマ部を取得し、該スキーマがHTTPSであることから、中継処理装置120における通信方式を決定するための処理を行う。利用者端末110は、中継処理装置120へ問い合わせを行う前に、過去に中継処理装置120との通信で用いられた情報が利用できないかどうかを調べるために、管理表保存部114のクライアント通信方式キャッシュ表(図16)を参照し、該コンテンツ取得要求に含まれるURLから情報提供処理装置150のサーバ識別子(ホスト名:ポート番号)を生成し、該サーバ識別子をキーにしてクライアント通信方式キャッシュ表(図16)のレコードを検索する。ここの例では、利用者端末110は、検索の結果、該サーバ識別子を条件として満たすレコードを発見し、該レコードの通信方式欄を参照し、通信方式を”代理”と判定する。なお、検索の結果、通信方式が”直接”であると判定された場合は、通常の方式(直接方式)で利用者端末110と情報提供処理装置150とが直接、SSLの暗号化通信回線を確立するように制御する。
ステップS1202では、利用者端末110は前述したステップS1107と同じ処理を行う。
ステップS1203では、中継処理装置120は前述したステップS1108と同じ処理を行う。
ステップS1204では、中継処理装置120は前述したステップS1109と同じ処理を行う。
ステップS1205では、利用者端末110の閲覧処理部111は、情報提供処理装置150への過去の通信で利用したSSLのセッション情報がキャッシュされているので再開可能であると判定し、キャッシュされているセッション情報のセッションIDを付加したClient Helloメッセージを中継処理装置120へ送信する。
利用者端末110の閲覧処理部111は、情報提供処理装置150への過去の通信で利用したSSLのセッション情報がキャッシュされているか否かを判定した結果、SSLのセッション情報がキャッシュされていないと判定した場合は、図11のステップS1110で説明した通り、セッションIDを付加していないSSL Client Helloメッセージを中継処理装置120へ送信する。
ステップS1206では、中継処理装置120は、管理表保存部129のプロキシ通信方式キャッシュ表(図9)の中から、ステップS1202(ステップS1107)で受信したクライアント識別子とサーバ識別子を、それぞれクライアント識別子欄とサーバ識別子欄にもつレコードを取得し、該レコードの通信方式欄の値(”代理”)から、中継を代理方式で実施することを判定(決定)する。
次に、中継処理装置120は、管理表保存部129の代理通信セッション管理表(図10)の中から、ステップS1202(ステップS1107)で受信したクライアント識別子とサーバ識別子を、それぞれクライアント識別子欄とサーバ識別子欄にもつレコード(代理通信セッションレコードと呼ぶ)を取得する。代理通信セッション管理表(図10)は、代理通信記憶手段の適用例である。
中継処理装置120は、該代理通信セッションレコードのセッションIDーC欄を参照し、利用者端末110から受信したSSL Client HelloメッセージのセッションID(第1のセッション識別情報)と同じならば、中継処理装置120側もセッション再開が可能と判定する(判定手段)。
すなわち、中継処理装置120は、該代理通信セッションレコードのセッションIDーC欄の値が、利用者端末110から受信したSSL Client Helloメッセージに含まれるセッションIDと同一であるか否かを判定し、同一であると判定された場合は、中継処理装置120もセッションの再開が可能であると判定する。一方、中継処理装置120は、該代理通信セッションレコードのセッションIDーC欄の値が、利用者端末110から受信したSSL Client Helloメッセージに含まれるセッションIDと同一ではないと判定された場合は、中継処理装置120はセッションの再開が不可能であると判定する。ここで、中継処理装置120は、セッションの再開が不可能であると判定された場合は、これ以降の処理は実行しない。ここでの例では、セッション再開は可能と判定され、利用者端末110へ該セッションIDを付加したSSL Server Helloメッセージを送信する。
ステップS1207では、中継処理装置120は、代理通信セッションレコードのセッションIDーS欄にセッションIDの値があるか否かを判定し、代理通信セッションレコードのセッションIDーS欄にセッションID(第2のセッション識別情報)の値があると判定された場合に、サーバ回線163においてもセッションを再開することができると判定し、該セッションIDを付加したClient Helloメッセージを情報提供処理装置150へ送信する。一方、中継処理装置120は、代理通信セッションレコードのセッションIDーS欄にセッションIDの値が無いと判定された場合は、サーバ回線163においてはセッションを再開することが出来ないと判定し、これ以降の処理を実行しないように制御する。
ステップS1208では、情報提供処理装置150は、中継処理装置120から受信したセッションIDで識別されるSSLのセッション情報が情報提供処理装置150においても利用可能なことを確認したのち、中継処理装置120へ、該セッションIDを付加したServer Helloメッセージを応答する。これは、中継処理装置120と情報提供処理装置150の間におけるサーバ回線163のSSLコネクションにおいても、セッション再開の合意がとれたことを意味する。
ステップS1209では、情報提供処理装置150は中継処理装置120へSSL Handshake finishedメッセージを送信する。
ステップS1210では、中継処理装置120は情報提供処理装置150へSSL Handshake finishedメッセージを送信する。
以上をもって、中継処理装置120と情報提供処理装置150の間のサーバ回線163のSSLハンドシェイク処理を終了する。
ステップS1211では、中継処理装置120は利用者端末110へHandshake finishedメッセージを送信する。
ステップS1210では、利用者端末110は中継処理装置120へHandshake finishedメッセージを送信する。
以上をもって、利用者端末110と中継処理装置120と間のプロキシ回線161のSSLハンドシェイク処理を終了する。
以降は、図11を用いて説明した、ステップS1134からステップS1141までの処理と同じ処理を、図12におけるステップS1213からステップS1220までの処理で実施する。
以上で、セッション再開機能による暗号化通信を代理方式によって中継する場合の通信メッセージ交換フローの例の説明を終了する。
以上、説明したように、セッション再開機能を利用した中継処理では、SSLハンドシェイク処理を大幅に短縮し、計算負荷の高い処理を省略することができる。また、上記で説明した手順によれば、セッション再開機能を利用した場合でも、利用者端末110は、セッションを開設した通信時(図11のステップS1121)に管理表保存部114のサーバ証明書キャッシュ表に保存しておいたサーバ証明書欄を参照することにより、情報提供処理装置150のサーバ公開鍵証明書を、中継処理装置120から送信されることなく利用者に提示することができ、利用者に通信相手の真正性を確認する手段を与えることが可能となっている。なお、クライアント認証に関しては、情報提供処理装置150は、情報提供処理装置150のメモリに記憶されているセッション情報の中に利用者端末110の公開鍵証明書をキャッシュしているために再度、中継処理装置120にクライアント認証の要求情報を送信し検証処理を行うことも省略できている。
(中継処理装置120における通信処理フロー)
次に、利用者端末110が中継処理装置120を経由して情報提供処理装置150へ暗号化通信(代理方式による暗号化通信)を行う場合の中継処理装置120の処理フローを、図3を用いて説明する。
なお、図3に示すステップS301からステップS320は、中継処理装置120のCPU201が実行することにより実現される。
ステップS301では、中継処理装置120は、利用者端末110から情報提供処理装置150への暗号化通信の要求の発生を元に通信方式を決定する処理(通信方式決定処理)を行う(図11のステップS1101からステップS1106)。
通信方式決定処理では、利用者端末110が要求する通信に対する中継処理装置120における通信方式が決定され、管理表保存部129のプロキシ通信方式キャッシュ表(図9)に、決定された通信方式を通信方式欄にもつ新しいレコードが作成される。該レコードの通信方式欄の値は、”直接”か”代理”または”選択なし”のいずれかになる。処理の詳細は図4を用いて後述する。
ステップS302では、クライアント通信部121は、利用者端末110の閲覧処理部111から接続を受け付け、SSL(TLSを含む)のプロキシ接続プロトコルに則ったCONNECTメソッドによる接続要求メッセージ(情報提供処理装置150とのSSL通信の要求の情報)を受信し、通信制御部124へ該接続要求メッセージを渡す(図11のステップS1107)。
すなわち、中継処理装置120は、利用者端末110から、情報提供処理装置150へのSSL通信の要求を受信する(受信手段)。
すなわち、中継処理装置120は、利用者端末110からSSL通信の要求を受信したことを条件に、プロキシ回線161の確立、及びサーバ回線163の確立を開始するように制御する(制御手段)。
以降、中継処理装置120のクライアント通信部121と利用者端末110の閲覧処理部111との間で開設される接続回線をプロキシ回線161と呼ぶ。
次に、通信制御部124は、該接続要求メッセージのCONNECTメソッドで指定された情報提供処理装置150のホスト名とポート番号からサーバ識別子(ホスト名:ポート番号)を作成し、また該接続要求メッセージのリクエストヘッダーからクライアント識別子(IPアドレス:閲覧処理部識別子)を取得する。そして、通信制御部124は、該サーバ識別子と該クライアント識別子をキーにして、管理表保存部129のプロキシ通信方式キャッシュ表(図9)からレコードを検索し、検索結果、該レコードの通信方式を取得する。該通信方式はステップS301において記憶された値である。
通信制御部124は、通信方式が”直接”又は”代理”であった場合には、CONNECTメソッドで渡されたホスト名とポート番号をサーバ通信部122へ渡し、サーバ通信部122は該ホスト名の情報提供処理装置150の該ポート番号へ接続する(図11のステップS1108)。接続が失敗すると、通信制御部124は、クライアント通信部121を経由して利用者端末110へエラーメッセージを応答(送信)して終了する。接続が成功すると、通信制御部124は、クライアント通信部121を経由して利用者端末110へHTTP応答コード200を応答する(図11のステップS1109)。以降、前記中継処理装置120のサーバ通信部122と情報提供処理装置150のサーバ処理部151との間で開設される接続回線をサーバ回線163と呼ぶ。
また、通信制御部124は、通信方式が”代理”であった場合には、サーバ識別子とクライアント識別子をキーにして、管理表保存部129の代理通信セッション管理表(図10)からレコードを検索する。通信制御部124は、該キーに一致するレコードがなかった場合には、サーバ識別子とクライアント識別子を、それぞれサーバ識別子欄とクライアント識別子欄にもつ新しいレコードを作成する。通信制御部124は、検索で発見されたレコード又は新規作成したレコードを中継処理装置120のRAM203に記憶させる。以降、このレコードを代理通信セッションレコードと呼び通信制御部124において参照できるものとする。
ステップS303では、ステップS302で取得した通信方式によって処理を分岐させる。すなわち、中継処理装置120は、ステップS302で取得した通信方式が、”直接”であるか、”代理”であるか、”選択なし”であるかを判定する。前記通信方式が”直接”であった場合はステップS304へ進み、”代理”であった場合はステップS305へ進み、”選択なし”であった場合はステップS319へ進む。
(直接プロキシ処理)
ステップS304では、通常のプロキシサーバが行う方式(直接方式)によって暗号化通信(HTTPS通信)されるデータを中継する。
すなわち、中継処理装置120は、利用者端末110と情報提供処理装置150との間で送受信されるデータを素通しして中継する。これにより、従来のように、クライアント端末と情報処理装置との間でSSLによる暗号化通信(第3のSSL通信)が確立される。
そして、中継処理装置120は、ここで確立された暗号化通信を用いて、利用者端末110と情報提供処理装置150との間で通信される通信データを中継する。
通信制御部124は、ステップS302において通信制御部124が利用者端末110へHTTP応答コード200を応答した後、クライアント通信部121が利用者端末110の閲覧処理部111から受信する全ての暗号化通信メッセージ(暗号化されたデータ)を、そのまま、サーバ通信部122から情報提供処理装置150のサーバ処理部151へ送信する。また、通信制御部124は、サーバ通信部122が情報提供処理装置150のサーバ処理部151から受信する全ての暗号化通信メッセージ(暗号化されたデータ)を、そのまま、クライアント通信部121から利用者端末110の閲覧処理部111へ送信する。そして、通信制御部124は、サーバ回線163が情報提供処理装置150から切断されるかもしくはプロキシ回線161が利用者端末110から切断されるかのいずれかが発生すると反対側の通信回線も切断し、全ての処理を終了する。
なお、この直接方式による中継処理では、通信要求メッセージ、通信応答メッセージとも暗号化されたまま中継するので、通信制御部124を経由する際、中継処理装置120は、付加機能処理部130における付加機能処理(通信メッセージ検査や通信応答キャッシュなど)は実行しない。
(中継拒否通知)
ステップS319では、通信制御部124は、アクセスを許可しない旨の通信応答メッセージを作成し、クライアント通信部121を経由して該通信応答メッセージを利用者端末110の閲覧処理部111へ送信し、プロキシ回線161を切断し処理を終了する。
(代理方式:利用者端末110とのSSLハンドシェイク処理)
ステップS305では、通信制御部124は、クライアント側暗号処理部123に対して前記プロキシ回線161においてSSLセッションを開始するよう指示する。クライアント側暗号処理部123は、該プロキシ回線161においてクライアント通信部121を経由して、利用者端末110の閲覧処理部111から送信されるSSL Client Helloメッセージを受信し、SSLハンドシェイク処理を開始する。SSLのハンドシェイク方法には、セッションを新規に開始するケースと過去のセッションを再開するケースの2通りがある。
まず、セッションを新規に開始するケースについて説明する。
中継処理装置120は、前記SSL Client Helloメッセージの中にセッションIDが含まれているか否かを判定し、セッションIDが含まれていると判定された場合であって、該セッションIDが前記代理通信セッションレコードのセッションIDーC欄の値と同一と判定された場合、クライアント側のSSLコネクションでセッションを再開し、一方、同一でない場合は、利用者端末110側のSSLコネクションは新規のセッションを開始する。
すなわち、SSLセッションを新規に開始する処理では、中継処理装置120のクライアント側暗号処理部123は、利用者端末110から送信されたSSL Client Helloメッセージ(図11のステップS1110)に応答して、Server Hello、Server Certificate、Server Hello Doneの各メッセージを順次送信する(図11のステップS1112、ステップS1113、ステップS1114)。
具体的には、中継処理装置120は、SSL Client Helloメッセージの中に、セッションIDが含まれていないと判定した場合は、新規のセッションを作成するため新規の固有のセッションIDを生成する。
そして、中継処理装置120は、当該生成されたセッションIDを含む該SSL Server Helloメッセージを利用者端末110に送信し、当該生成されたセッションIDを代理通信セッションレコードのセッションIDーC欄に保存する。該セッションIDは次回以降にセッションを再開する場合の識別子となる。
利用者端末110は、セッションIDを含むSSL Server Helloメッセージを中継処理装置120から受信すると、当該SSL Server Helloメッセージに含まれているセッションIDをSSLのセッション情報としてRAM203等のメモリに記憶する(キャッシュする)。
次に、中継処理装置120は、代理用暗号鍵保存部に記憶されているサーバ公開鍵証明書を含むSSL Server Certificateメッセージを利用者端末110に送信する(ステップS1113)。
利用者端末110は、中継処理装置120からSSL Server Certificateメッセージを受信し、当該SSL Server Certificateメッセージに含まれるサーバ公開鍵証明書を外部メモリ211などのメモリに記憶する。
そして、中継処理装置120は、中継処理装置120での一連の処理の終了を通知するSSL Server Hello Doneメッセージを利用者端末110に送信する(ステップS1114)。
利用者端末110は、中継処理装置120からSSL Server Hello Doneメッセージを受信すると、マスターシークレット(データの暗号化及び復号化に用いる共通鍵を生成するための情報)を生成する。
また、利用者端末110は、ここで生成されたマスターシークレットに従って、プロキシ回線161を介して中継処理装置120と通信する対象となるデータの暗号化及び復号を行うために用いる共通鍵を生成して、当該生成された共通鍵をRAM203等のメモリに記憶する。
利用者端末110は、ステップS1134以降の処理(ステップS314)で、プロキシ回線161を介してデータを中継処理装置120に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。
また、利用者端末110は、中継処理装置120からプロキシ回線161を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
そして、利用者端末110は、中継処理装置120から受信したSSL Server Certificateメッセージに含まれているサーバ公開鍵証明書に含まれるサーバの公開鍵を用いて、当該生成されたマスターシークレットを暗号化する。
そして、利用者端末110は、当該暗号化されたマスターシークレットを含むClientKeyExchangeメッセージを中継処理装置120に送信する。
中継処理装置120は、利用者端末110からClientKeyExchangeメッセージを受信する。
そして、中継処理装置は、当該ClientKeyExchangeメッセージに含まれている暗号化されたマスターシークレットを、利用者端末110に送信したSSL Server Certificateメッセージに含まれるサーバ公開鍵証明書(サーバの公開鍵を含む)に対応する秘密鍵を用いて復号する。
なお、ここで用いる秘密鍵は、サーバ公開鍵証明書(サーバの公開鍵を含む)に対応付けられて代理用暗号鍵保存部126に記憶されており、利用者端末110に送信したサーバ公開鍵証明書(サーバの公開鍵を含む)に対応するものである。
次に、中継処理装置120は、復号されたマスターシークレットに従って共通鍵を生成する。そして、中継処理装置120は、該生成された共通鍵の情報を前記代理通信セッションレコードの共通鍵その他ーC欄に記憶する。
中継処理装置120は、ステップS1134以降の処理(ステップS314)で、プロキシ回線161を介してデータを利用者端末110に送信する際は、当該データを、ここで生成された共通鍵を用いて暗号化して送信する。また、中継処理装置120は、利用者端末110からプロキシ回線161を介して送信された暗号化されたデータを、ここで生成された共通鍵を用いて復号する。
次に、SSLセッションを再開するケースについて説明する。
中継処理装置120は、利用者端末110から受信したSSL Client HelloメッセージにセッションIDが含まれていると判定され、当該セッションIDが、前記代理通信セッションレコードのセッションIDーC欄に含まれていると判定された場合に、SSLセッションを再開すると判定する(S306:YES)。ここで、中継処理装置120が、利用者端末110から、セッションIDを含むSSL Client Helloメッセージを受信したことは、SSL通信の再開要求を受信したことを意味する。このとき、共通鍵その他ーC欄には既に当該SSLセッション用の共通鍵が保存されている。クライアント側暗号処理部123は、利用者端末110からの前記SSL Client Helloメッセージ(図12のステップS1205)に応答して、Server Helloメッセージを送信する(図12のステップS1206)。
(代理用暗号鍵保存部126のサーバ公開鍵証明書について)
代理用暗号鍵保存部126に記憶されているサーバ公開鍵証明書に関して説明する。該サーバ公開鍵証明書は、プロキシ回線161のSSLコネクションにおけるサーバ認証用のサーバ公開鍵証明書である。通常のプロキシ接続(直接方式による通信)においては、該サーバ公開鍵証明書は、情報提供処理装置150のサーバ暗号鍵保存部152に記憶されているサーバ公開鍵証明書が情報提供処理装置150から提示されるが、本実施例の代理方式では、中継処理装置120の代理用暗号鍵保存部に記憶されているサーバ公開鍵証明書が代わりに提示される。そのため該サーバ公開鍵証明書は、任意の情報提供処理装置150に対して有効と判定されるものでなければならない。このため、本実施例の代理方式では、該サーバ公開鍵証明書は、非特許文献1で示されているように、情報提供処理装置150のホスト名が記載される主体者のCommon Name(CN)属性又はSubjectAltName属性にワイルドカードを用いて任意の情報提供処理装置150を表す。サーバ公開鍵証明書とホスト名を元にした情報提供処理装置150の身元確認方法に関しては、RFC2818「3.終点の識別 3.1 サーバーの身元」に記載されている。
また、該サーバ公開鍵証明書には、主体者のDN(識別名)の中のCommon Nameより上の階層に、中継処理装置120のホスト名を属性値としてもつようにし、エンドポイント(情報提供処理装置150)の確認とともに中継点(中継処理装置120)の確認も同時に実施できるようにする。
DN(主体者識別名)の例を示す。
cn=*.*.*、ou=proxy.xxx.com,o=XXX Inc.,c=jp
この例では、cnはワイルドカードで表され、ホスト名に3つのドメインコンポーネントをもつ任意の情報提供処理装置150に対する代理用のサーバ公開鍵証明書であることを表している。代理用暗号鍵保存部126では、任意の情報提供処理装置150のサーバ公開鍵証明書として利用できるように、ワイルドカードのドメインコンポーネントが例えば2から10までに対応するcnをもつサーバ公開鍵証明書を予め記憶しておき、通信セッションにおける情報提供処理装置150のホスト名のドメインコンポーネントの数によって前記サーバ公開鍵証明書から適切なものが選択されるようにしておく。
また、Common Name(cn)の一つ上位のou属性値として中継処理装置120のホスト名(上記例:proxy.xxx.com)を記載している。該ou属性値はプロキシ回線161上のSSLコネクションにおける中継処理装置120の真正性確認に用いることができる。これは制御回線162で利用者端末110の拡張機能処理部112が明示的に接続する中継処理装置120のホスト名と前記属性値が同じであることで検証することができる。
ステップS306では、ステップS305において新規セッションを開設していればステップS307へ進み、セッションの再開機能を使っていればステップS316へ進む。
ステップS307では、サーバ側暗号処理部125は、ステップS302で開設したサーバ回線163を介して、サーバ通信部122を経由してSSL Client Helloメッセージを情報提供処理装置150に送信し、SSLハンドシェイク処理を新規に開始する(図11のステップS1111からステップS1118)。
サーバ側暗号処理部125は、情報提供処理装置150から、SSL Server Hello、SSL Server Certificate、SSL Certificate Request(オプション)、SSL Server Hello Doneメッセージ等を受信する。通信制御部124は、該SSL Server Certificateメッセージを受信すると該メッセージに含まれる情報提供処理装置150のサーバ公開鍵証明書を取得し、該サーバ公開鍵証明書を代理通信セッションレコードのサーバ証明書欄に保存する。
また、サーバ側暗号処理部125が前記Certificate Requestメッセージを受信した場合は(図11のステップS1117)、情報提供処理装置150がSSLクライアント認証を要求していることを意味するので、通信制御部124は、代理通信セッションレコードのクライアント認証要求欄に該Certificate Requestメッセージの内容を符号化して保存する。Certificate Requestメッセージには、クライアント認証の条件を示す署名アルゴリズムと情報提供処理装置150が信用しているルートCAの識別名情報が含まれている。
ステップS308では、制御処理通信部128は該代理通信セッションレコードのサーバ証明書欄に保存された情報提供処理装置150のサーバ公開鍵証明書を利用者端末110へ制御回線162を介して送信し、利用者端末110において該サーバ公開鍵証明書を検証させ、情報提供処理装置150に対するサーバ認証を実施させるステップである。そして、制御処理通信部128は、その検証結果を通信制御部124へ渡す(図11のステップS1119からステップS1122)。ステップS308の詳細処理は、図5を用いて後述する。
ステップS309では、通信制御部124は、制御処理通信部128から渡されたステップS308におけるサーバ認証処理の結果が、成功であればステップS310へ進み、失敗であればステップS320へ進む。ここで、通信制御部124は、ステップS308で、利用者端末110から検証が成功した旨を受信した場合は、サーバ認証処理の結果が、成功として判定し、一方、利用者端末110から、検証が成功しなかった旨を受信した場合は、サーバ認証処理の結果が、失敗として判定する。
ステップS310では、通信制御部124は、代理通信セッションレコードのクライアント認証要求欄を参照し、値が存在すればステップS311へ進み、値が存在しなければステップS312へ進む。
ステップS311では、中継処理装置120は、利用者端末110と連携することにより、情報提供処理装置150から要求されたクライアント認証に応答するための処理を行う(図11のステップS1123からステップS1129)。ステップS311の詳細処理は、図6を用いて後述する。
ステップS312では、サーバ側暗号処理部125において、サーバ通信部122を経由して、SSL Handshake finishedメッセージを情報提供処理装置150に送信して、前記サーバ回線163におけるSSLコネクションのハンドシェイク処理を終了する(図11のステップS1130からステップS1131)。
ステップS313では、クライアント側暗号処理部123において、クライアント通信部121を経由して、SSL Handshake finishedを利用者端末110に送信して、プロキシ回線161におけるSSLコネクションのハンドシェイク処理を終了する(図11のステップS1132からステップS1133)。
ステップS314では、既に確立した、プロキシ回線161のSSLセッションと、サーバ回線163のSSLセッションと、の2つのSSLセッションの間でアプリケーションメッセージを中継する。この時、付加機能処理部130において平文化されたメッセージに対して、付加機能による処理が実行される(図11のステップS1134からステップS1137)。詳細は後述する。
ステップS315では、ステップS314におけるアプリケーションメッセージの交換が終了すると、情報提供処理装置150もしくは利用者端末110からSSL close notifyメッセージによるセッション終了通知が送信される。クライアント側暗号処理部123もしくはサーバ側暗号処理部125において該メッセージを受信すると、クライアント側暗号処理部123もしくはサーバ側暗号処理部125はSSL close notifyメッセージを返信しSSLセッションを終了し、通信回線(プロキシ回線、又はサーバ回線)を切断する。次に反対側のSSLセッションの終了処理と通信回線(プロキシ回線、又はサーバ回線)の切断処理を実施する。
(SSLセッション再開機能を使う場合)
ステップS316では、通信制御部124は、サーバ回線163においてSSLセッションの再開が可能か否かを判定する。
すなわち、通信制御部124は、利用者端末110から受信したセッションIDが含まれている代理通信セッションレコードのセッションIDーS欄に値が存在するか否かを判定し、代理通信セッションレコードのセッションIDーS欄に値が存在すると判定された場合、サーバ側暗号処理部125から該セッションIDの値を付加したSSL Client Helloメッセージを、サーバ通信部122を経由してサーバ回線を介して情報提供処理装置150へ送信する。
次に、サーバ側暗号処理部125は、情報提供処理装置150からSSL Server Helloメッセージを受信する。通信制御部124は、該SSL Server Helloメッセージに該セッションIDが含まれているか否かを判定し、該セッションIDが含まれていると判定された場合は、セッション再開が可能と判定しステップS312へ進む。
通信制御部124は、代理通信セッションレコードのセッションIDーS欄に値が存在しない場合、もしくは存在してもSSL Server Helloメッセージに該セッションIDが含まれていなければ、セッション再開は不可と判定しステップS317へ進む。
ステップS317では、通信制御部124は、ステップS307と同様に、サーバ回線163上で新しいSSLセッションを開始する。
通信制御部124は、情報提供処理装置150からのSSL Server Certificateメッセージを受信すると、該メッセージからサーバ公開鍵証明書を取得し、該サーバ公開鍵証明書と代理通信セッションレコードのサーバ証明書欄の値とを比較する。当該比較の結果、両者が同一でなかった場合は、代理通信セッションレコードのサーバ証明書欄を該サーバ公開鍵証明書で上書き保存する。
また、通信制御部124は、情報提供処理装置150からSSL Certificate Requestメッセージを受信した場合は、ステップS307と同様に代理通信セッションレコードのクライアント認証要求欄に該SSL Certificate Requestメッセージの内容を符号化して保存する。
ステップS318では、通信制御部124は、ステップS317におけるサーバ公開鍵証明書の比較の結果を参照し、真(同一)ならばステップS310へ進み、偽(同一ではない)ならば再度サーバ公開鍵証明書を利用者端末110で検証させるためにステップS308へ進む。
(エラー処理)
ステップS320では、制御処理通信部128は、ステップS308におけるサーバ証明書の検証処理が失敗したことを通信制御部124へ通知し、通信制御部124は、サーバ側暗号処理部125に情報提供処理装置150とのSSLハンドシェイク処理をエラー終了するように通知し、サーバ側暗号処理部125は、サーバ通信部122を経由して、サーバ回線163を介してSSLのSSL bad certificate alertメッセージを情報提供処理装置150へ送信し、サーバ回線163を切断し、終了する。
(図4 通信方式決定処理の詳細)
次に、図3におけるステップS301の詳細である利用者端末110と中継処理装置120とにおける通信方式決定処理のフローを、図4を用いて説明する。
図4に示すステップS401からステップS403、ステップS406からステップS408の処理は、利用者端末110のCPU201により実行され実現される。
また、ステップS404、ステップS405、ステップS409の処理は、中継処理装置120のCPU201により実行され実現される。
なお、図4で示す利用者端末110と中継処理装置120との間の通信は、図1における制御回線162を使うものとする。
ステップS401では、利用者端末110の閲覧処理部111は、利用者が”https://・・・”形式のURLのリンクをクリックしたり、アドレスバーに入力するなどして、情報提供処理装置150への暗号化通信の要求イベントを検知すると、拡張機能処理部112へ該URLを渡し制御を移す。
ステップS402では、利用者端末110の拡張機能処理部112は、当該URLの中のホスト名とポート番号からサーバ識別子(サイト情報)を生成し、該サーバ識別子をキーに管理表保存部114のクライアント通信方式キャッシュ表(図16)からレコードを検索する。
利用者端末110の拡張機能処理部112は、検索処理にて条件に一致するレコードがあれば該レコードの通信方式欄の値を通信方式とし処理を終了する。この場合は、利用者端末110のクライアント通信方式キャッシュ表の該レコード(キャッシュ情報)が存在すれば、中継処理装置120のプロキシ通信方式キャッシュ表(図9)にも同じ通信条件のキャッシュ情報が存在する。
利用者端末110の拡張機能処理部112は、検索処理にて条件に一致するレコードがなければ新規に通信方式を決定するためにステップS403へ進む。
ステップS403では、利用者端末110の拡張機能処理部112は、中継処理装置120の制御処理通信部128へHTTPSで接続する。すなわち、利用者端末110と中継処理装置120との間でSSLによる暗号化通信の回線(制御回線162)を確立する。この接続回線を制御回線162と呼ぶ。利用者端末110の拡張機能処理部112は、ステップS402で生成したサーバ識別子と、利用者端末110のIPアドレスと閲覧処理部111識別子からなるクライアント識別子と、をもつ通信方式問い合わせ要求メッセージを中継処理装置120へ送信する。
ステップS404では、中継処理装置120の制御処理通信部128が、ステップS403の通信方式問い合わせ要求メッセージを受信し、サーバ識別子とクライアント識別子を取得する(受付手段)。サーバ識別子は、中継先情報の適用例である。また、クライアント識別子(IPアドレス)は、クライアント情報の適用例である。
ステップS405では、中継処理装置120の制御処理通信部128は、ステップS404で取得した情報提供処理装置150を識別するサーバ識別子と、利用者端末110の閲覧処理部111を識別するクライアント識別子と、を元に管理表保存部129の通信方式決定表(通信方式設定情報)(図8)のサーバ条件とクライアント条件に合致するレコードを検索し、合致するレコードの通信方式を、確立が許可された通信の通信方式として決定する(通信決定手段)。
サーバ条件のドメイン名欄との照合は、サーバ識別子から情報提供処理装置150のホスト名を取り出し、該ホスト名とドメイン名欄の値に対して文字列パターンマッチングを行う。サーバ条件のカテゴリー欄との照合は、ホスト名(ドメイン名)をカテゴリーに変換する。ここでは不図示の、ホスト名(ドメイン名)とカテゴリーとが対応付けられた変換テーブル等を用いて、サーバ識別子から取り出したホスト名から、当該ホスト名に対応するカテゴリーを算出(決定)し、該カテゴリーとカテゴリー欄の値を比較する。クライアント条件のアドレス欄の照合は、クライアント識別子からIPアドレスを取り出し、該IPアドレスと値との照合を行う。クライアント条件の認証グループ欄の照合は、中継処理装置120が利用者端末110の閲覧処理部111の利用者を認証した場合に入力された利用者の属性値と照合するにより行う。中継処理装置120が利用者端末110の閲覧処理部111を利用する利用者を認証する手段に関しては詳細には記載しないが、例えば、プロキシ回線161上でHTTPのプロキシ認証を実施する手段や制御回線162のHTTPSトランザクションにおいてSSLクライアント認証やHTTPダイジェスト認証等を実施する手段を使うことができる。
また、通信方式決定表では、図8の804で示されるような全ての通信要求条件に合致するレコードを持たせ必ず通信方式が決定されるようにしておく。
すなわち、通信方式決定表(図8)は、各レコードの条件を判断する優先順位を有しており、一番上のレコードから下のレコードに向って、順次、各レコードの条件に合致するかの判断がなされる。
次に、制御処理通信部128は、検索の結果、得られたレコードの通信方式欄の値を、利用者端末110の拡張機能処理部112へ応答メッセージとして送信する。
ここでは、中継処理装置120は、得られたレコードの通信方式欄の値(“直接”又は“選択”又は“代理”)を利用者端末110に送信し、利用者端末110は、中継処理装置120から受信した通信方式欄の値に従って、後述する図13又は図14に示す画面を表示する。
他の方法としては、得られたレコードの通信方式欄の値(“直接”又は“選択”又は“代理”)に従って決定される図13又は図14に示す画面を表示するための画面情報を中継処理装置120が利用者端末110に送信し、当該画面情報を受信した利用者端末110が、当該画面情報に従って図13又は14の画面を表示するようにしてもよい。
すなわち、中継処理装置120は、受け付けたサイト情報(中継先情報)(情報提供処理装置150を特定するホスト名やポート番号)に対して“選択(通信方式が選択を示す情報)”(“選択”は指示情報の適用例である)が通信方式決定表(図8)に記憶されていると判定された場合に、通信方式(直接または代理)を選択するための画面情報(図14)を、制御回線を介して利用者端末に送信する(通信方式送信手段)(ステップS405)。ここで送信される画面情報、又は通信方式は、通信方式指示情報の適用例である。
また、中継処理装置120は、受け付けたサイト情報(中継先情報)(情報提供処理装置150を特定するホスト名やポート番号)に対して、通信方式が代理を示す情報が、通信方式決定表(図8)に記憶されていると判定された場合に、通信方式(“代理”または“通信しない”)を選択するための画面情報(図13)を、制御回線を介して利用者端末に送信する(ステップS405)。
ステップS406では、利用者端末110の拡張機能処理部112は、通信方式を選択するための画面情報を中継処理装置120から受信する。
すなわち、利用者端末110は、中継処理装置から画面情報を受信すると、当該画面情報に従って、図13又は図14に示す画面を表示する。図14は、指示画面の適用例である。 このように、利用者端末110を操作しているユーザ(操作ユーザ)は、確立が許可される通信方式として、“代理”(代理通信方式)が決定された場合、代理通信方式で通信するか、通信自体を行わないかの選択しか行えず、通信を行うためには、必ず代理通信方式が選ばれることになる。すなわち、中継処理装置120は、確立が許可される通信方式として代理通信方式が決定されたことを条件に、代理通信方式による通信が確立されることとなる。
次に、中継処理装置120が、得られたレコードの通信方式欄の値(“直接”又は“選択”又は“代理”)を利用者端末110に送信し、利用者端末110が、中継処理装置120から受信した通信方式欄の値に従って、図13又は図14に示す画面を表示する場合について説明する。
ステップS406では、利用者端末110の拡張機能処理部112は、通信方式(直接または代理または選択)を中継処理装置120から受信する。
ステップS407では、利用者端末110の拡張機能処理部112は、ステップS406で受信した通信方式の値に基づき、図13又は図14に示すダイアログボックスを表示する。
このとき、通信方式が”直接”の場合は、ダイアログボックスは表示しない。すなわち、通信方式が“直接”(直接通信方式)の場合は、確立する通信の通信方式が“直接”(直接通信方式)となる。
利用者端末110は、ステップS406で受信した通信方式が”代理”の場合は、図13に例を示すようなダイアログボックス(画面)を表示し、利用者に、”利用者端末110と情報提供処理装置150の間の暗号化通信が中継処理装置120において一旦復号されセキュリティ検査等の付加機能処理が適用される”という旨のメッセージを表示し承諾するか否かを選択させる。利用者端末110は、図13の画面において利用者が「許可する」ボタンをクリックした場合は、拡張機能処理部112は通信方式を”代理”のままにし、「許可しない」ボタンをクリックした場合には通信方式を”選択なし”という値に更新する。
利用者端末110は、ステップS406で受信した通信方式が”選択”の場合は、図14に例を示すようなダイアログボックス(画面)を表示し、利用者に、利用者端末110と情報提供処理装置150の間の暗号化通信が中継処理装置120において一旦復号しセキュリティ検査等の付加機能処理を実行するか、もしくは情報提供処理装置150との間はエンドツーエンドの暗号化通信を行い、中継処理装置120では平文化通信メッセージが検査や記録できないようにするか、を選択させる。利用者端末110は、図14の画面において、利用者が「許可する」ボタンをクリックした場合は、拡張機能処理部112における通信方式を”代理”という値に更新し、「許可しない」ボタンをクリックした場合には通信方式を”直接”という値に更新する。
次に、拡張機能処理部112は、管理表保存部114のクライアント通信方式キャッシュ表(図16)にサーバ識別子と決定日時と、選択された通信方式の値からなる新しいレコードを作成する。
ステップS408では、利用者端末110の拡張機能処理部112は、利用者により選択されたボタンが「許可する」ボタンである場合(すなわち、通信方式が“代理”の場合)、中継処理装置120の制御処理通信部128へHTTPSで接続する(制御回線162の開設)。
また、拡張機能処理部112は、利用者により、図14の画面を介して選択されたボタンが「許可しない」ボタンである場合(すなわち、通信方式が“直接”の場合)、制御回線162は開設しない。また、拡張機能処理部112は、利用者により、図13の画面を介して選択されたボタンが「許可しない」ボタンである場合(すなわち、通信方式が“選択なし”の場合)、制御回線162は開設しない。
そして、利用者端末110の拡張機能処理部112は、サーバ識別子と、クライアント識別子と、ステップS407において選択された通信方式の値と、ステップS407で決定した通信方式の中継処理装置120における有効期限と、をもつ通信方式通知メッセージを中継処理装置120へ送信する。
該有効期限は通信方式の中継処理装置120上での利用可能な有効期限として表し、ステップS407の処理日時から数時間程度(所定時間)進めた日時などを用いる。
ステップS409では、中継処理装置120の制御処理通信部128は、ステップS408の通信方式通知メッセージ(選択結果)を受信し(通信方式受信手段)、当該通信方式通知メッセージに含まれる、サーバ識別子とクライアント識別子と決定された通信方式と有効期限とからなるレコードを作成し、該レコードを管理表保存部129のプロキシ通信方式キャッシュ表(図9)に保存する。以上で、通信方式決定処理を終了する。
(図5 サーバ証明書検証処理の詳細)
次に、図3におけるステップS308の詳細である利用者端末110と中継処理装置120とにおけるサーバ証明書検証処理のフローを、図5を用いて説明する。
図5に示すステップS503、ステップS505からステップS507の処理は、利用者端末110のCPU201により実行され実現される。
また、ステップS501、ステップS502、ステップS504、ステップS508の処理は、中継処理装置120のCPU201により実行され実現される。
なお、図5で示す利用者端末110と中継処理装置120との間の通信は、図1における制御回線162を使うものとする。
ステップS501では、中継処理装置120の通信制御部124は、代理通信セッションレコードのサーバ証明書欄から情報提供処理装置150のサーバ公開鍵証明書を取得し、該サーバ公開鍵証明書の有効性を検証する。
検証項目としては、該サーバ公開鍵証明書の認証パス中の署名機関(CA)が信頼される署名機関としてCA証明書保存部131中に記憶されているものと一致するか否か、検証日時は証明書有効期間内か否か、CRL又はOCSP(Online Certificate Status Protocol)による失効状態、認証パスの長さなどである。
ステップS502では、中継処理装置120は、ステップS501の前記サーバ公開鍵証明書の検証が成功したか否かを判定し、成功したと判定されればステップS504へ進み、失敗したと判定されたのであれば、失敗という結果情報を通信制御部124へ通知し終了する。
ステップS503では、利用者端末110の拡張機能処理部112は、制御回線162を介して、中継処理装置120の制御処理通信部128へHTTPSで接続し、情報提供処理装置150のサーバ識別子と利用者端末110のクライアント識別子と共に、情報提供処理装置150のサーバ公開鍵証明書の取得要求メッセージを送信する(図11のステップS1119)。
ステップS504では、制御処理通信部128は、ステップS501で送られたサーバ識別子とクライアント識別子をキーにして、管理表保存部129の代理通信セッション管理表の中から当該キーに一致するレコードを検索する。そして、制御処理通信部128は、管理表保存部129の代理通信セッション管理表の中から一致するレコード(代理通信セッションレコード)を取得する。そして該レコードのサーバ証明書欄の値を利用者端末110の拡張機能処理部112へ応答(送信)する(図11のステップS1120)(送信手段)。
すなわち、中継処理装置120は、サーバ回線163の暗号化通信の回線を確立する際に用いられる(情報提供処理装置150から取得した)情報提供処理装置150のサーバ公開鍵証明書を、制御回線162を介して利用者端末110に送信する。
ステップS505では、拡張機能処理部112は、ステップS503で受信したサーバ公開鍵証明書の有効性を検証する(図11のステップS1121)。検証手段としては閲覧処理部111によってSSLハンドシェイク中に実施されるサーバ証明書の検証と同程度の検証を実施する。検査項目としては、前記サーバ公開鍵証明書の認証パス中の署名機関(CA)が信頼される署名機関としてCA証明書保存部115中の保存されているものと一致するか否か、検証日時は証明書有効期間内か否か、CRL又はOCSP(Online Certificate Status Protocol)による失効状態、認証パスの長さなどである。さらに、拡張機能処理部112は、サーバ公開鍵証明書中の主体者名と情報提供処理装置150のホスト名が一致するか否かを確認する(RFC2818「3.終点の識別 3.1 サーバーの身元」記載の方法)。
ステップS506では、拡張機能処理部112は、ステップS503で実施した検証結果とサーバ公開鍵証明書の内容を、ダイアログボックスを用いて表示し、利用者へサーバ公開鍵証明書を信頼して通信を継続するか否かの確認を取る(図11のステップS1121)。図15にダイアログボックスの例を示す。
拡張機能処理部112は、図15に示す画面内の「許可する」ボタンが押下されたか否かを判定して、押下されたと判定された場合は、確認結果として検証が成功した旨を、中継処理装置120の制御処理通信部128へ送信する。一方、拡張機能処理部112は、「許可する」ボタンが押下されず、「許可しない」ボタンが押下されたと判定された場合は、確認結果として検証が成功しなかった旨を、中継処理装置120の制御処理通信部128へ送信する。
ステップS507では、拡張機能処理部112は、ステップS504で実施した利用者による情報提供処理装置150のサーバ公開鍵証明書の確認結果を検証結果として中継処理装置120の制御処理通信部128へ送信する(図11のステップS1122)。
ステップS508では、中継処理装置120の制御処理通信部128は、利用者端末110による情報提供処理装置150のサーバ公開鍵証明書の検証結果を受信し、該結果を通信制御部124へ通知する。
以上で、サーバ証明書検証処理を終了する。
ここでは、利用者端末110は、利用者端末110による情報提供処理装置150のサーバ公開鍵証明書の検証結果を、最終的な検証結果として、中継処理装置120に送信しているが、拡張機能処理部112が実行する検証処理の結果を、最終的な検証結果として中継処理装置120に送信するようにしてもよい。
(図6 クライアント認証処理の詳細)
次に、図3におけるステップS311の詳細である利用者端末110と中継処理装置120とにおけるクライアント認証処理のフローを、図6を用いて説明する。
図6に示すステップS601、ステップS603からステップS605、ステップS610、ステップS611、ステップS613、ステップS614は、利用者端末110のCPU201により実行され実現される。
また、ステップS603、ステップS606からステップS612、ステップS615、ステップS616は、中継処理装置120のCPU201により実行され実現される。
なお、図6で示す利用者端末110と中継処理装置120との間の通信は、図1における制御回線162を使うものとする。
ステップS601では、利用者端末110の拡張機能処理部112は、中継処理装置120の制御処理通信部128へHTTPSで接続し(制御回線162の開設)、サーバ識別子とクライアント識別子と共に、情報提供処理装置150のクライアント認証条件の取得要求メッセージを送信する。
ステップS602では、中継処理装置120の制御処理通信部128は、ステップS601で受信したサーバ識別子とクライアント識別子をキーにして、管理表保存部129の代理通信セッション管理表の中から、当該キーに一致するレコードを検索する。そして、中継処理装置120の制御処理通信部128は、検索の結果、管理表保存部129の代理通信セッション管理表の中から得られたレコード(代理通信セッションレコード)を取得する。
そして、中継処理装置120の制御処理通信部128は、取得された該代理通信セッションレコードのクライアント認証要求欄の値を利用者端末110の拡張機能処理部112へ応答(送信)する(図11のステップS1123)。
ステップS603では、利用者端末110の拡張機能処理部112は、ステップS601で中継処理装置120から受信したクライアント認証要求の値を解析し、条件となっている署名アルゴリズムやCA識別名を取得し、それらの条件に適合するクライアント公開鍵証明書を、暗号鍵保存部113に記憶されているクライアント公開鍵証明書群の中から取得する(図11のステップS1124)。
ステップS604では、利用者端末110の拡張機能処理部112は、ステップS603で取得したクライアント公開鍵証明書の内容を含むダイアログボックス等を表示することで利用者へ示す。そして、利用者端末110の拡張機能処理部112は、情報提供処理装置150へのクライアント認証に利用する証明書として、当該クライアント公開鍵証明書の使用の可否の選択を受け付ける(図11のステップS1124)。もし、ステップS603で取得したクライアント公開鍵証明書が複数の場合は、拡張機能処理部112は、ダイアログボックス等を表示してクライアント認証に用いるクライアント公開鍵証明書として利用者に1つを選択させた後に確認処理を行う(使用の可否の選択を受け付ける)。拡張機能処理部112は、ステップS603において条件に適合するクライアント公開鍵証明書がなかった場合は何もしない。
ステップS605では、利用者端末110の拡張機能処理部112は、ステップS604において利用者が利用確認した(利用者により選択された)クライアント公開鍵証明書を中継処理装置120へ送信する(図11のステップS1125)。また、拡張機能処理部112は、ステップS604においてクライアント公開鍵証明書がなかった場合は該当なしの旨のメッセージを送信する。
ステップS606では、中継処理装置120の制御処理通信部128は、利用者端末110からクライアント公開鍵証明書を受信し、該クライアント公開鍵証明書を通信制御部124へ渡す。すなわち、ステップS606では、中継処理装置120は、制御回線162を用いて、利用者端末110からクライアント公開鍵証明書を取得する(取得手段)。
ステップS607では、中継処理装置120の通信制御部124は、当該クライアント公開鍵証明書を代理通信セッションレコードのクライアント証明書欄に保存する。
次に、通信制御部124は、該クライアント公開鍵証明書をサーバ側暗号処理部125に渡す。サーバ側暗号処理部125は、サーバ回線163における情報提供処理装置150とのSSLハンドシェイク処理において、該クライアント公開鍵証明書を含んだSSL Client Certificateメッセージを作成し情報提供処理装置150へ送信する(図11のステップS1126)(公開鍵送信手段)。中継処理装置120は、ステップS606においてクライアント公開鍵証明書がないメッセージを受信していた場合は、サーバ側暗号処理部125は、SSL Client Certificateメッセージの証明書領域は空のままにして、SSL Client Certificateメッセージを送信する。
ステップS608では、中継処理装置120の制御処理通信部128は、SSL Client Certificateメッセージの中にクライアント公開鍵証明書がない場合は、中継処理装置120側の処理を終了する。制御処理通信部128は、中継処理装置120の制御処理通信部128は、当該メッセージの中にクライアント公開鍵証明書があった場合はステップS609へ進む。
ステップS609では、中継処理装置120の通信制御部124は、SSL(TLSを含む)の規約に基づいて署名対象データを作成する。例えば、TLS/1.0における署名対象データは、RFC2246の「7.4.8.CertificateVerifyメッセージ」に記載されているように、SSL ClientHelloメッセージから現在までのメッセージで、CertificateVerifyメッセージを除く、送信または受信した全てのハンドシェイクメッセージを連結したデータのメッセージダイジェスト値となる。すなわち、署名対象データは、サーバ回線163の暗号化通信を確立するために情報提供処理装置150と通信したデータである。中継処理装置120の通信制御部124は、作成した署名対象データを制御処理通信部128へ渡す。
ステップS610では、利用者端末110の拡張機能処理部112は、ステップS604において条件に適合するクライアント公開鍵証明書がなかった場合は、利用者端末側の処理を終了する。拡張機能処理部112は、クライアント公開鍵証明書があった場合はステップS611へ進む。
ステップS611では、利用者端末110の拡張機能処理部112は、中継処理装置120の制御処理通信部128へHTTPSで接続し、署名対象データ要求メッセージを中継処理装置120に送信する。利用者端末110の拡張機能処理部112は、中継処理装置120がステップS612において送信した署名対象データを受信する。
ステップS612では、中継処理装置120の制御処理通信部128は、当該署名対象データ要求メッセージを利用者端末110から受信すると、ステップS609で生成された署名対象データを利用者端末110の拡張機能処理部112へ送信する(図11のステップS1127)。
ステップS613では、利用者端末110の拡張機能処理部112は、ステップS605で中継処理装置120へ送信したクライアント公開鍵証明書と対になる秘密鍵を暗号鍵保存部113から取得し、該秘密鍵を用いてステップS611で受信した署名対象データに対して署名処理を施して(暗号化して)署名データを作成する。
ステップS614では、利用者端末110の拡張機能処理部112は、中継処理装置120の制御処理通信部128へHTTPSで接続し、ステップS613で作成した署名データを中継処理装置120に送信する(図11のステップS1128)。
ステップS615では、中継処理装置120の制御処理通信部128は、当該署名データを利用者端末110から受信し、該署名データを通信制御部124へ渡す。
ステップS616では、中継処理装置120の通信制御部124は、当該署名データをサーバ側暗号処理部125へ渡し、サーバ側暗号処理部125は該署名データを含んだSSL Certificate Verifyメッセージを作成し、情報提供処理装置150へ送信する(図11のステップS1129)(署名データ送信手段)。
以上で、クライアント認証処理を終了する。
(図7 APデータ中継処理の詳細)
次に、図3におけるステップS314の詳細である中継処理装置120におけるAP(アプリケーション)データ(通信データ)の中継処理のフローを、図7を用いて説明する。
なお、図7に示すステップS701からステップS713は、中継処理装置120のCPU201が実行することにより実現される。
ステップS701では、クライアント通信部121は、プロキシ回線161を介して利用者端末110から暗号化通信要求メッセージを受信し、該暗号化通信要求メッセージをクライアント側暗号処理部123へ渡す。
ステップS702では、クライアント側暗号処理部123は、当該暗号化通信要求メッセージ(第1の暗号化データ)を、代理通信セッションレコード(図10の現在処理対象のレコード)の共通鍵その他ーC欄の記憶されている共通鍵(第1の共通鍵)を用いて復号化し(第1復号手段)、当該復号化された平文化通信要求メッセージを作成する。クライアント側暗号処理部123は、該平文化通信要求メッセージを通信制御部124へ渡す。
ステップS703では、通信制御部124は、平文化通信要求メッセージ(第1の暗号化データを復号することにより得られる通信データ)を付加機能処理部130へ渡し、付加機能処理部130は、前記平文化通信要求メッセージに対して付加機能(検査)を実行する(第1検査手段)。付加機能処理部130は、付加機能の実行結果(検査結果)として、中継処理の継続可否を示す中継可否判定結果と、中継用の平文化通信要求メッセージと、を通信制御部124へ渡す。
付加機能(検査処理)の例としては、例えば、平文化通信要求メッセージに対し、キーワード検査を行って機密情報として外部への送信が禁止されているデータが含まれているか否かを検査する処理などがある。その結果、平文化通信要求メッセージに禁止されているデータが含まれていなかったと判定されれば、中継可否判定結果は”可”となり、中継用の平文化通信要求メッセージは、元の平文化通信要求メッセージに対して「検査済み」であるヘッダーが付加されたメッセージとなるケースなどが想定されている。このように、付加機能処理部130は、復号されたデータを検査する付加機能の処理(検査処理)を行う。
ステップS704では、通信制御部124は、付加機能の処理の結果、中継可否判定結果が”可”ならばステップS705へ進み、”不可”ならばステップS713へ進む(第1決定手段)。
ステップS705では、通信制御部124は、中継用の平文化通信要求メッセージをサーバ側暗号処理部125へ渡し、サーバ側暗号処理部125は、該中継用の平文化通信要求メッセージを代理通信セッションレコードの共通鍵その他ーS欄の記憶されている共通鍵を用いて暗号化して、中継用の暗号化通信要求メッセージを作成する。
ステップS706では、サーバ側暗号処理部125は、中継用の暗号化通信要求メッセージをサーバ通信部122へ渡し、サーバ通信部122は、該中継用の暗号化通信要求メッセージを情報提供処理装置150のサーバ処理部151へ送信する。
ステップS707では、サーバ通信部122は情報提供処理装置150のサーバ処理部151から暗号化された暗号化通信応答メッセージ(第2の暗号化データ)を受信し、該暗号化通信応答メッセージをサーバ側暗号処理部125へ渡す。
ステップS708では、サーバ側暗号処理部125は、該暗号化通信応答メッセージを代理通信セッションレコードの共通鍵その他ーS欄の記憶されている共通鍵(第2の共通鍵)を用いて復号化して(第2復号手段)、当該復号された平文化通信応答メッセージを作成する。サーバ側暗号処理部125は、該平文化通信応答メッセージを通信制御部124へ渡す。
ステップS709では、通信制御部124は、平文化通信応答メッセージ(第2の暗号化データを復号することにより得られた通信データ)を付加機能処理部130へ渡し、付加機能処理部130は、該平文化通信応答メッセージに対して付加機能を実行する(第2検査手段)。付加機能処理部130は、前記付加機能の実行結果として、中継処理の継続可否を示す中継可否判定結果と、中継用平文化通信応答メッセージと、を通信制御部124へ渡す。
付加機能の例としては、例えば、平文化通信応答メッセージに対しアンチウィルス処理を行うなどがある。この場合、付加機能処理部130は、平文化通信応答メッセージにウィルスが含まれているか否かを検査して、平文化通信応答メッセージにウィルスが含まれていると判定されれば、中継可否判定結果は”不可”となる。この場合、中継処理装置120は、中継用の平文化通信応答メッセージを利用者端末110には送信せず、”ウィルスが検知されたため通信回線を遮断しました”等のメッセージを利用者端末110に送信するなどが想定されている。
すなわち、中継処理装置120は、付加機能処理部130による付加機能の実行結果として、中継可否判定結果が”不可”の場合は、平文化通信応答メッセージを利用者端末110には送信せず、一方、中継可否判定結果が“可”の場合は、平文化通信応答メッセージを利用者端末110に中継することを決定する(第2決定手段)。
付加機能処理部130による検査結果として中継可否判定結果が“可”の場合(例えば、平文化通信応答メッセージにウィルスが含まれていないと判定された場合)、ステップS710では、通信制御部124は、中継用の平文化通信応答メッセージをクライアント側暗号処理部123へ渡し、クライアント側暗号処理部123は、該中継用の平文化通信応答メッセージを代理通信セッションレコードの共通鍵その他ーC欄の記憶されている共通鍵を用いて暗号化して中継用の暗号化通信応答メッセージを作成する。
ステップS711では、クライアント側暗号処理部123は、中継用の暗号化通信応答メッセージをクライアント通信部121へ渡し、クライアント通信部121は、該中継用の暗号化通信応答メッセージを、利用者端末110の閲覧処理部111へ送信する。
ステップS712では、通信制御部124は平文化通信応答メッセージなどからアプリケーション通信(HTTPトランザクション)を終了するかどうか判定し、終了すると判定すれば処理を終了する。継続すると判定すればステップS701へ進む。
ステップS713では、通信制御部124は、ステップS703で生成された中継可否判定結果(中継可否判定結果が”不可”)と中継用の平文化通信要求メッセージに基づき、「リクエスト送信は禁止されました」等の中継用の平文化通信応答メッセージを作成して、ステップS710へ進む。ステップS710では、中継処理装置120は、ここで生成された中継用の平文化通信応答メッセージを、代理通信セッションレコードの共通鍵その他ーC欄の記憶されている共通鍵を用いて暗号化して、中継用の暗号化通信応答メッセージを作成し、ステップS711で利用者端末110に送信する。
以上で、APデータ中継処理を終了する。
以上説明したように、本実施形態によれば、暗号化通信によるデータを中継する際に、当該データを検査可能にすると共に、真正な証明書に基づき通信相手の真正性を確認できる。
さらに、本実施形態によれば、例えば、銀行の預金などのWebページを利用者端末で閲覧する場合、中継処理装置で、利用者端末の操作ユーザのパスワードなどの個人の情報も検査してしまうことが低減される。
すなわち、Webサイトに応じて、通信されるデータを検査するか否かを決定することができるため、情報漏えい等のセキュリティを向上させると共に、個人の情報を取得し検査しないように制御することも可能である。
また、本実施形態によれば、情報提供処理装置は、通信相手である利用者端末の真正性を確認することができるようになる。
また、本発明によれば、代理方式による暗号化通信を再開する場合、既に記憶されているセッションIDや共通鍵を用いて再開することが可能となる。
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
<第2の実施形態>
第1の実施形態では、HTTPS(HTTP over SSL(TLSを含む))通信において、利用者端末110が中継処理装置120(プロキシサーバ)へCONNECTメソッドで接続し情報提供処理装置150(Webサーバ)への通信をトンネリングする仕組みに対して、暗号化通信情報を復号化し付加機能を実行する方法と、その場合においてもエンティティ認証を有効に機能させる方法について説明した。しかしながら、CONNECTメソッドによる中継プロトコルはHTTP通信に限定されない汎用のトランスポート通信のトンネリング手法であるため、たとえば、IMAP over SSL(TLSを含む)、POP3 over SSL(TLSを含む)、SMTP over SSL(TLSを含む)等のSSL(TLSを含む)を使う他の通信プロトコルの場合でも同様の構成で適用することができる。
例えば、IMAP over SSL(TLSを含む)に適用する場合は、利用者端末110の閲覧処理部111はIMAP over SSL(TLSを含む)クライアント機能を備えたメールユーザエージェントであり、情報提供処理装置150のサーバ処理部151はIMAP over SSL(TLSを含む)機能を備えたIMAPサーバとなる。
以上説明したように、本実施の形態によれば、各通信規約を変更することなく、暗号化通信によるデータを中継する際に、当該データを検査可能にすると共に、真正な証明書に基づき通信相手の真正性を確認することができる。
また、制御回線もSSL通信であるので、中継処理装置自体のなりすましも防止できる。 次に、図19、及び図20を用いて、本発明における中継処理装置の機能について説明する。
図19は、本発明における中継処理装置の機能ブロック図である。1901は、本発明における中継処理装置を示している。
すなわち、1901は、クライアント端末(利用者端末110)と情報処理装置(情報提供処理装置150)との間で通信される通信データを中継する中継処理装置120である。
ここで、本実施例の利用者端末110は、本発明のクライアント端末の適用例である。また、本実施例の情報提供処理装置150は、本発明の情報処理装置の適用例である。 1902は、クライアント端末と通信データの通信で用いられる第1のSSL通信を確立する第1確立部である。 1903は、情報処理装置と通信データの通信で用いられる第2のSSL通信を確立する第2確立部である。
1904は、第2確立部で第2のSSL通信を確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書を、第1の確立部により第1のSSL通信を確立するクライアント端末に送信する送信部である。
次に、図20を用いて、本発明における中継処理装置の機能について説明する。
図20は、本発明における中継処理装置の機能ブロック図である。
2000は、クライアント端末(利用者端末110)と情報処理装置(情報提供処理装置150)との間で通信される通信データを中継する中継処理装置120である。
1902、1903、1904は、図19で説明した機能と同様であるため、ここでは説明を省略する。 2001は、クライアント端末と制御通信を確立する通信確立部である。
また、送信部1904は、第2確立部で第2のSSL通信を確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書を、通信確立部により確立された制御通信を用いて、第1の確立部により第1のSSL通信の確立を行うクライアント端末に送信する。
2002は、クライアント端末から、情報処理装置へのSSL通信の要求を受信する受信部である。
2003は、受信部でクライアント端末からSSL通信の要求を受信したことを条件に、第1確立部による第1のSSL通信の確立、及び第2確立部による第2のSSL通信の確立を行うように制御する制御部である。
2004は、クライアント端末と情報処理装置との間で確立される第3のSSL通信を用いて、クライアント端末と情報処理装置との間で通信される通信データを中継する中継部である。
2005は、クライアント端末から送信される通信データの中継先の情報処理装置を示す中継先情報に対して、通信データの中継を許可する通信方式として、中継部で第3のSSL通信を用いて通信データの中継を行う直接通信方式か、第1確立部により確立される第1のSSL通信、及び第2確立部により確立される第2のSSL通信を用いて通信データの中継を行う代理通信方式かを示す通信方式情報が設定された通信方式設定情報を記憶する記憶部である。
2006は、通信データを中継する中継先情報をクライアント端末から受け付ける受付部である。
2007は、記憶部に記憶された通信方式設定情報と、受付部で受け付けた中継先情報とに従って、受付部で受け付けた中継先情報に示される中継先の情報処理装置とクライアント端末との間での通信を許可する通信方式が直接通信方式であるか、代理通信方式であるかを決定する通信決定部である。
ここで、制御部2003は、通信決定部で、情報処理装置とクライアント端末との間での通信を許可する通信方式として代理通信方式が決定されたことを条件に、第1確立部による第1のSSL通信の確立、及び第2確立部による第2のSSL通信の確立を行うように制御する。
また、中継部2004は、更に、通信決定部で、情報処理装置とクライアント端末との間での通信を許可する通信方式として直接通信方式が決定されたことを条件に、クライアント端末と情報処理装置との間で確立される第3のSSL通信を用いて、クライアント端末と情報処理装置との間で通信される通信データを中継する。
また、記憶部に記憶されている通信方式設定情報は、更に、中継先情報に対して、クライアント端末を示すクライアント情報が設定されており、受付部は、中継先情報を受け付けたクライアント端末のクライアント情報を更に受け付け、通信決定部は、記憶部に記憶された通信方式設定情報と、受付部で受け付けた中継先情報と、受付部で受け付けたクライアント情報とに従って、受付部で受け付けた中継先情報に示される中継先の情報処理装置と、受付部で受け付けたクライアント情報により示されるクライアント端末との間での通信を許可する通信方式を決定する。
記憶部に記憶された通信方式設定情報の通信方式情報は、通信を行う通信方式を、クライアント端末の操作ユーザよる指示に従って決定することを示す指示情報を更に含んでいる。
2008は、受付部で受け付けた中継先情報に対する、記憶部に記憶された通信方式設定情報の通信方式情報が指示情報である場合に、通信方式の指示を受け付けるための指示画面を前記クライアント端末に表示するための通信方式指示情報をクライアント端末に送信する通信方式送信部である。
2009は、通信方式送信部で送信された通信方式指示情報に従って表示される指示画面を介してクライアント端末の操作ユーザにより指示された通信方式を示す通信方式情報を、クライアント端末から受信する通信方式受信部である。
また、通信決定部は、更に、通信方式受信部で受信した通信方式情報に示される通信方式を、受付部で受け付けた中継先情報に示される中継先の情報処理装置とクライアント端末との間で通信を行う通信方式として決定し、制御部は、更に、通信決定部で、情報処理装置とクライアント端末との間で通信を行う通信方式として代理通信方式が決定されたことを条件に、第1確立部による第1のSSL通信の確立、及び第2確立部による第2のSSL通信の確立を行うように制御する。
また、記憶部に記憶されている通信方式設定情報は、中継先情報に対して、クライアント端末を示すクライアント情報が更に設定されており、受付部は、中継先情報を受け付けたクライアント端末のクライアント情報を更に受け付け、通信方式送信部は、受付部で受け付けた中継先情報、及びクライアント情報に対する、記憶部に記憶された通信方式設定情報の通信方式情報が指示情報である場合に、通信方式を指示するための指示画面をクライアント端末に表示するための通信方式指示情報をクライアント端末に送信する。
2010は、通信確立部で確立した制御通信を用いてクライアント端末からクライアント端末の公開鍵証明書を取得する取得部である。
2011は、取得部で取得したクライアント端末の公開鍵証明書を、第2確立部で第2のSSL通信を確立する際に用いられる中継処理装置の公開鍵証明書として情報処理装置に送信する公開鍵送信部である。
2012は、第2確立部で第2のSSL通信を確立するために情報処理装置と通信したデータが、公開鍵送信部により情報処理装置に送信したクライアント端末の公開鍵証明書に対応する秘密鍵を用いて暗号化されることにより生成される署名データを情報処理装置に送信する署名データ送信部である。
2013は、第1確立部により確立された第1のSSL通信を用いてクライアント端末から受信した、通信データが暗号化された第1の暗号化データを、第1確立部で第1のSSL通信を確立する際に生成した第1の共通鍵を用いて復号する第1復号部である。
2014は、第1復号部で第1の暗号化データを復号することにより得られる通信データを検査する第1検査部である。
2015は、第1検査部による検査結果に従って、第1検査部で検査された通信データを情報処理装置に中継するか否かを決定する第1決定部である。
2016は、第2確立部により確立された第2のSSL通信を用いて情報処理装置から受信した、通信データが暗号化された第2の暗号化データを、第2確立部で第2のSSL通信を確立する際に生成した第2の共通鍵を用いて復号する第2復号部である。
2017は、第2復号部で第2の暗号化データを復号することにより得られた通信データを検査する第2検査部である。
2018は、第2検査部による検査結果に従って、第2検査部で検査された通信データをクライアント端末に中継するか否かを決定する第2決定部である。
2019は、第1確立部で第1のSSL通信を確立する際に生成した第1の共通鍵と、該第1のSSL通信のセッションを識別する第1のセッション識別情報と、第2確立部で第2のSSL通信を確立する際に生成した第2の共通鍵と、該第2のSSL通信のセッションを識別する第2のセッション識別情報とを関連付けて記憶する代理通信記憶部である。
2020は、クライアント端末から情報処理装置への、第1のセッション識別情報を含むSSL通信の再開要求を受信する再開要求受信部である。
2021は、再開要求受信部で受信した、SSL通信の再開要求に含まれる第1のセッション識別情報が、代理通信記憶部に記憶されているかを判定する判定部である。
2022は、判定部で、第1のセッション識別情報が代理通信記憶部に記憶されていると判定された場合に、該第1のセッション識別情報に関連付けて代理通信記憶部に記憶された第1の共通鍵を用いてクライアント端末と第1のSSL通信を再開し、かつ該第1のセッション識別情報に関連付けて代理通信記憶部に記憶された、第2の共通鍵と、第2のセッション識別情報とを用いて情報処理装置と第2のSSL通信を再開する通信再開部である。
なお、通信確立部2001で確立される制御通信はSSL通信である。
以上、本発明の一実施形態を詳述したが、本発明は、例えば、システム、装置、方法、装置で実行可能なプログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM等を用いることができる。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(基本システム或いはオペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。