JP2004206573A - データ転送装置、サーバー装置、情報提供システム、データ転送方法及びプログラム - Google Patents

Abstract

【課題】複数のサーバーを対象として、各サーバーと各クライアントとの間でデータを暗号化してやり取りする場合に、該暗号化されたデータを復号化したものを用いたデータ処理を行うことが可能なプロキシを提供すること。
【解決手段】クライアントからサーバーへの接続要求を受信すると、サーバーを代行してクライアントとの間で、クライアント・サーバー間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するとともに、サーバーとの間で、クライアント・サーバー間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、データを転送するデータ転送装置、情報を提供するサーバー装置、データ転送装置と複数のサーバー装置とを含む情報提供システム、データ転送方法及びプログラムに関する。
【０００２】
【従来の技術】
従来、Ｗｅｂ閲覧では、Ｗｅｂ閲覧者がクライアント上のＷｅｂ閲覧ソフトを用いてＷｅｂサーバーにリクエストを送信し、リクエストを受信したＷｅｂサーバーはリクエストに応じたレスポンスをクライアントに送信し、クライアントはレスポンスを受けＷｅｂ閲覧ソフトへの表示等を行う。その際、クライアント−サーバー間を流れるＷｅｂデータは、クライアントとＷｅｂサーバーを経由するネットワークの途中にあるプロキシに代表されるデータ転送装置上でキャッシュが行なわれる。キャッシュを利用することで、実際にネットワークを流れるデータ量を削減することができるとともに、レスポンスタイムの向上にも有効に働く。
【０００３】
また、近年、インターネットの普及に伴いＷｅｂサーバーへのリクエストが増加し、Ｗｅｂサーバーの負荷がレスポンスタイムに大きな影響を及ぼしている。このような状況下で、Ｗｅｂサーバーへのリクエストを削減するために、サーバー側システムの一部としてリバース型プロキシが導入されている。リバース型プロキシは、Ｗｅｂサーバー一つに対して一つ設置され、クライアントからのリクエストを受けると、キャッシュされているページがＬＲＵやＬＦＵアルゴリズムによりその有効性が保証されている場合は、Ｗｅｂサーバーに代わってクライアントにレスポンスを返す。これによって、Ｗｅｂサーバーの負荷を軽減し、レスポンスタイムの向上を実現するとともに、Ｗｅｂサーバーが過負荷によってダウンする事態の回避を実現している。
【０００４】
一方、近年のインターネットの利用拡大に伴って、ＥＣサイト等を利用して個人情報や企業情報等といった機密情報をＷｅｂ経由でデータ交換を行なう機会が増加している。このようにＷｅｂ閲覧者・Ｗｅｂサーバー以外の第三者に機密情報の漏洩を防ぐ技術として、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）が利用されている。ＳＳＬを用いることで、クライアント−Ｗｅｂサーバー間で行なわれるデータ交換を暗号化し、ネットワーク途中での機密情報の盗聴や漏洩、サーバーやクライアントの成りすまし等によるデータの盗聴や改ざん等を防止し、機密情報の第三者への流出等を防ぐ安全なＷｅｂデータ交換が実現されている。ＳＳＬは、いわゆるＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）アプリケーションの一つであり、ＲＳＡに代表される暗号化アルゴリズムを用いた公開鍵暗号化方式を利用している。クライアント−Ｗｅｂサーバー間でＳＳＬコネクションを確立するためには、サーバーが正当なものであることをＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）が保証するサーバー証明書と秘密鍵のペアを、Ｗｅｂサーバーが保持している必要がある。サーバー証明書には、そのサーバーのサーバー名や管理者の氏名、住所、メールアドレス等の他に公開鍵が含まれており、その正当性を保証するためにＣＡが電子署名を行なったものである。ＳＳＬの公開鍵暗号化方式によってクライアント−サーバー間に暗号化ネットワークが確立されると、公開鍵暗号化方式より高速にデータの暗号化・復号化を行なうために、ＤＥＳやトリプルＤＥＳ等といった暗号化アルゴリズムによる共通鍵をＷｅｂサーバー・クライアント間で交換・共有し、実際のデータ暗号化・復号化には、その共通鍵を用いた共通鍵暗号化方式が利用される。つまり、ＳＳＬでは、共通鍵をクライアント−サーバー間で安全に交換するために、公開鍵暗号化方式が用いられる。Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージの送信から共通鍵の交換までを、ＳＳＬハンドシェイクと呼ぶ。また、ＳＳＬハンドシェイクを終了し、サーバークライアント間で共通鍵による暗号化・復号化が行なわれるコネクションを、ＳＳＬコネクションと呼ぶ。
【０００５】
リバース型プロキシの場合、ＳＳＬコネクションを確立するのに必要なサーバー証明書と秘密鍵はプロキシが保有し、クライアント−プロキシ間でＳＳＬコネクションが確立される。この場合、プロキシ上でデータが復号化されるため、キャッシュ等といった復号化されたデータに対するデータ処理を実行することが可能である。ただし、リバース型プロキシの場合は、一つのプロキシに対して一つのＷｅｂサーバーしか復号化することが出来ない。
【０００６】
一方、フォーワード型プロキシの場合、プロキシは、ＳＳＬ通信には関与せず、クライアント−Ｗｅｂサーバー間で確立されたＳＳＬコネクションによって暗号化されたＷｅｂデータを、素通し（トンネリング）している。これは、フォーワード型プロキシはその上流に複数のＷｅｂサーバーがあり、それらのサーバー証明書と秘密鍵を保有していないことや、プロキシがサーバー側システムにあるとは限らないために、安全性の面からプロキシ上でＷｅｂデータの復号化を行なうことに、問題があるためである。このため、フォーワード型プロキシ上で、キャッシュ等といった復号化されたデータを用いたデータ処理を行うことができない。
【０００７】
なお、プロキシについては例えば非特許文献１に詳しく開示されている。
【０００８】
【非特許文献１】
「Web プロキシサーバー」、アリ・ルネトオン著、1998年、プレンティスホール出版、ISBN：4-89471-089-7
【０００９】
【発明が解決しようとする課題】
従来のプロキシでは、リバース型であってもフォーワード型であっても、複数のＷｅｂサーバーが行なう暗号化された通信を復号化し、データ処理を行なうことができなかった。
【００１０】
本発明は、上記事情を考慮してなされたもので、複数のサーバー装置を対象として、各サーバー装置と各クライアント装置との間でデータを暗号化してやり取りする場合に、該暗号化されたデータを復号化したものを用いたデータ処理を行うことが可能なデータ転送装置、サーバー装置、情報提供システム、データ転送方法及びプログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明に係るデータ転送装置は、クライアント装置から送信された、サーバー装置への接続要求メッセージを受信するための手段と、前記接続要求メッセージが受信された場合に、前記サーバー装置を代行して、前記クライアント装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するための第１のコネクション設定手段と、前記接続要求メッセージが受信された場合に、前記サーバー装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定するための第２のコネクション設定手段とを備えたことを特徴とする。
【００１２】
好ましくは、前記第１のコネクションを介して、前記クライアント装置から転送されてきた、暗号化されたリクエストメッセージを受信するための手段と、受信された前記暗号化されたリクエストメッセージを復号化するための手段と、復号化された前記リクエストメッセージに対して、所定のデータ処理を施すための第１の処理手段と、前記所定のデータ処理を施された前記リクエストメッセージを再度暗号化するための手段と、暗号化された前記リクエストメッセージを前記第２のコネクションを介して前記サーバー装置へ送信するための手段とを更に備えるようにしてもよい。
【００１３】
好ましくは、前記第２のコネクションを介して、前記サーバー装置から転送されてきた、暗号化されたレスポンスメッセージを受信するための手段と、受信された前記暗号化されたレスポンスメッセージを復号化するための手段と、復号化された前記レスポンスメッセージに対して、所定のデータ処理を施すための第２の処理手段と、前記所定のデータ処理を施された前記レスポンスメッセージを再度暗号化するための手段と、暗号化された前記レスポンスメッセージを前記第１のコネクションを介して前記クライアント装置へ送信するための手段とを更に備えるようにしてもよい。
【００１４】
また、本発明に係る情報提供システムは、前記データ転送装置と、複数のサーバー装置とを備えたことを特徴とする。
【００１５】
また、本発明に係るサーバー装置は、前記データ転送装置との間で、前記固有の情報を暗号化して転送するためのコネクションを設定した後に、該コネクションを介して該データ転送装置から前記固有の情報を要求するリクエストメッセージを受信した場合に、前記固有の情報を記述したレスポンスメッセージを該コネクションを介して該データ転送装置へ送信する手段を備えたことを特徴とする。
【００１６】
また、本発明に係る情報提供システムは、前記データ転送装置と、複数の前記サーバー装置とを備えたことを特徴とする。
【００１７】
また、本発明に係るデータ転送方法は、クライアント装置から送信された、サーバー装置への接続要求メッセージを受信するステップと、前記接続要求メッセージが受信された場合に、前記サーバー装置を代行して、前記クライアント装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するステップと、前記接続要求メッセージが受信された場合に、前記サーバー装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定するステップとを有することを特徴とする。
【００１８】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００１９】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２０】
本発明によれば、複数のサーバー装置を対象として、各サーバー装置と各クライアント装置との間でデータを暗号化してやり取りする場合に、復号化されたデータを取得できるため、該暗号化されたデータを復号化したものを用いたデータ処理を行うことが可能になる。
【００２１】
また、本発明によれば、例えば、複数のＷｅｂサーバーとＷｅｂブラウザの間で行なわれるＳＳＬによる暗号化通信をプロキシ上で復号化した状態でのデータ処理が可能となる。また、例えば、新規Ｗｅｂサーバーの導入やサーバー証明書の更新に伴う手間を大幅に削減することが可能となる。
【００２２】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２３】
本実施形態のＷｅｂサーバー、プロキシ、Ｗｅｂブラウザは、いずれも計算機上でソフトウェア（Ｗｅｂサーバー・プログラム、プロキシ・プログラム、Ｗｅｂブラウザ・プログラム）を動作させる形で実現することができる。この場合に、必要に応じて計算機所望の機能を有するＯＳやドライバソフト、あるいは通信インターフェース装置や外部記憶装置や入出力装置といったハードウェアが搭載、あるいは接続される。また、この場合に、ユーザーあるいは管理者からの情報やユーザーへの情報呈示等のために、グラフィカル・ユーザー・インターフェース（ＧＵＩ）を用いると好ましい。
【００２４】
本実施形態では、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂシステムでの通信は、ＨＴＴＰプロトコルに従って行なわれる。また、暗号化通信は、ＨＴＴＰＳプロトコルに従って行なわれる。ＨＴＴＰＳ（ＨＴＴＰ ｏｖｅｒ ＳＳＬ）プロトコルは、ＨＴＴＰプロトコルにＳＳＬプロトコルの機能を追加したものである。本実施形態では、ＨＴＴＰプロトコルに関してはＲＦＣ１９４５に示されているＨＴＴＰ１．０を用いて説明する。ＳＳＬプロトコルに関しては、“http://home.netscape.com/eng/ssl3/ssl-toc.html”に示されているＳＳＬ３を用いて説明する。なお、以下の説明で用いられるＨＴＴＰのＣＯＮＮＥＣＴメソッドに関しては例えばＲＦＣ２８１７に詳しい。
【００２５】
図１に、本発明の一実施形態に係るシステムの基本的な構成例を示す。
【００２６】
図１の構成例において、プロキシ（情報転送装置）１は、複数のＷｅｂサーバー（図１の例では、２０１，２０２，２０３の３台）に接続されているとともに、ＬＡＮ６を経由してファイアーウォール３に接続されている。イントラネット５は、例えばオフィスやデータセンタなどに設けられ、ファイアーウォール３によって外部からの不正な進入を防止している。もちろん、イントラネット５内の構成は、図１の例に限定されるものではない。
【００２７】
他方、クライアント４は、Ｗｅｂブラウザ４０１を用いて、外部ネットワーク７を経由してＷｅｂサーバー（図１の例ではＷｅｂサーバー２０１，２０２，２０３）にアクセス可能である。外部ネットワーク７は、例えばモデムを用いた公衆回線やＰＨＳ等を用いたワイヤレスネットワークなどでもよい。なお、プロキシ１が対象とするクライアントは、複数台存在し得るものであり、図１では、図中４の１台のクライアントのみを例示している。
【００２８】
なお、図１では、当該イントラネット５の内部に設けられたプロキシ１が、当該イントラネット５内部のＷｅｂサーバーを対象とする構成であるが、複数のイントラネットの外部に設けられたプロキシが、それら複数のイントラネットの内部に（それぞれ１又は複数）存在するＷｅｂサーバーを対象とする構成も可能である。
【００２９】
図２に、プロキシ１の内部構成例を示す。ただし、図２には、本実施形態を説明するのに必要な部分のみ示されている。図３は、Ｗｅｂブラウザ２０１とプロキシ１との間の第１のＳＳＬコネクションと、プロキシ１とＷｅｂブラウザ２０１との間の第２のＳＳＬコネクションとを概念的に示したものである。なお、図２は、矢印によって、図３に示されている第１のＳＳＬコネクション及び第２のＳＳＬコネクションを確立するまでのデータの流れをも併せて示している。
【００３０】
図２に示されるように、プロキシ１は、通信部１１０、サーバー情報管理部１２０、ＳＳＬコネクション確立部１３０、暗号化・復号化部１４０、データ処理部１５０を備えている。
【００３１】
また、通信部１１０は、クライアント側ネットワークからデータを受信するクライアント側受信部１１１、クライアント側ネットワークへデータを送信するクライアント側送信部１１２、Ｗｅｂサーバー側ネットワークからデータを受信するサーバー側受信部１１３及びＷｅｂサーバー側ネットワークへデータを送信するサーバー側送信部１１４を含む。ただし、クライアント側受信部１１１、クライアント側送信部１１２、サーバー側受信部１１３及びサーバー側送信部１１４は、物理的には同じネットワーク・インターフェースであってもよく、本実施形態では説明の簡易化のために仮想的に分割した場合を示している。
【００３２】
サーバー情報管理部１２０は、サーバー名取得部１２１、複製サーバー鍵取得部１２２、複製サーバー鍵保持部１２３、複製サーバー鍵登録部１２４を含む。
【００３３】
ＳＳＬコネクション確立部１３０は、ＳＳＬハンドシェイクプロトコルに従ってＷｅｂブラウザとサーバー側ＳＳＬハンドシェイクを行なうクライアント側ＳＳＬハンドシェイク部１３１、ＳＳＬハンドシェイクプロトコルに従ってＷｅｂサーバーとクライアント側ＳＳＬハンドシェイクを行なうサーバー側ＳＳＬハンドシェイク部１３２を含む。
【００３４】
暗号化・復号化部１４０は、Ｗｅｂブラウザから受信する暗号化されたデータを復号化するクライアント側復号部１４１、Ｗｅｂブラウザへ送信するデータを暗号化するクライアント側暗号化部１４２、Ｗｅｂサーバーから受信する暗号化されたデータを復号化するサーバー側復号化部１４３、Ｗｅｂサーバーへ送信するデータを暗号化するサーバー側暗号化部１４４を含む。
【００３５】
データ処理部１５０は、復号化されたデータをもとに所定の処理を行うデータ処理部１５１を含む。データ処理部１５１は、ＷｅｂブラウザからＷｅｂサーバーへのリクエストのみについて処理を行うものであってもよいし、ＷｅｂサーバーからＷｅｂブラウザへのレスポンスのみについて処理を行うものであってもよいし、それらリクエストとレスポンスとの両方について処理を行うものであってもよい。また、それらリクエストとレスポンスとの両方について処理を行う場合に、１つのデータ処理部でそれらリクエストとレスポンスとの両方について処理を行うようにしてもよいし、リクエストを処理するデータ処理部とレスポンスを処理するデータ処理部を別々に備えるようにしてもよい。
【００３６】
複製サーバー鍵登録部１２４によって予め登録された複製サーバー証明書・秘密鍵（ｋ０１とする）は、複製サーバー鍵保持部１２３から複製サーバー鍵取得部１２２によって取得され、クライアント側ＳＳＬハンドシェイク部１３１に渡される。複製サーバー鍵登録部１２４は、例えば、プロキシ管理者などによって、設定ファイル・コマンドラインによる指令等によって、サーバー名をキーとして、該当Ｗｅｂサーバーのサーバー証明書・秘密鍵の複製を、複製サーバー鍵保持部１２３に登録する。
【００３７】
クライアント側共通鍵（ｋ０２とする）は、クライアント側ＳＳＬハンドシェイク部１３１によって確立された第１のＳＳＬコネクションで用いられる共通鍵であり、クライアント側ＳＳＬハンドシェイク部１３１からクライアント側復号化部１４１及びクライアント側暗号化部１４２に渡される。
【００３８】
サーバー側共通鍵（ｋ０３とする）は、サーバー側ＳＳＬハンドシェイク部１３２によって確立された第２のＳＳＬコネクションで用いられる共通鍵であり、サーバー側ＳＳＬハンドシェイク部１３２からサーバー側復号化部１４３及びサーバー側暗号化部１４４に渡される。
【００３９】
以下、本実施形態の処理の流れについて説明する。
【００４０】
図４に、Ｗｅｂブラウザ４０１、プロキシ１、Ｗｅｂサーバー２０１（www.aaa.co.jp）の間での処理の流れの一例を示す。なお、図４の例では、第２のＳＳＬコネクションが第１のＳＳＬコネクションより時間的に早く確立されているが、その逆でも構わない。
【００４１】
図５は、図３に示されている第１のＳＳＬコネクション（図中２１）及び第２のＳＳＬコネクション（図中２２）が確立されるプロセスを、図２に示されている各構成要素の働きを含めて示したフローチャートの一例である。
【００４２】
プロキシ１のクライアント側受信部１１１がＷｅｂブラウザ４０１からのリクエスト“CONNECT www.aaa.co.jp：443 HTTP1.0”を受信（ステップＳ１、Ｐ１）すると、サーバー名取得部１２１はリクエストからサーバー名“www.aaa.co.jp”を取得する（ステップＳ２）。サーバー名取得部１２１は複製サーバー鍵取得部１２２にサーバー名を渡し、複製サーバー鍵取得部１２２は複製サーバー鍵保持部１２３に該当するＷｅｂサーバーが登録されているか否かを問い合わせる（ステップＳ３）。
【００４３】
ステップＳ４において、該当するＷｅｂサーバーが複製サーバー鍵保持部１２３に登録されている場合は、複製サーバー鍵取得部１２２は複製サーバー鍵保持部１２３よりＷｅｂサーバー（www.aaa.co.jp）の複製サーバー証明書・秘密鍵ｋ０１を取得し（ステップＳ１０）、クライアント側ＳＳＬハンドシェイク部１３１にそれらを渡すとともに、サーバー側ＳＳＬハンドシェイク部１３２に該当サーバー名（www.aaa.co.jp）を渡す。クライアント側ＳＳＬハンドシェイク部１３１は渡された（ステップＳ１１）複製サーバー鍵・秘密鍵ｋ０１を用いてＳＳＬハンドシェイクプロトコルに従ってＷｅｂブラウザ４０１とクライアント側受信部１１１・送信部１１２を経由して第１のＳＳＬコネクションを確立する（ステップＳ１２，Ｓ１３、Ｐ３）。第１のＳＳＬコネクションで利用される共通鍵ｋ０２は、クライアント側復号化部１４１及びクライアント側暗号化部１４２に渡される（ステップＳ１４）。他方、サーバー側ＳＳＬハンドシェイク部１３２は、ＳＳＬハンドシェイクプロトコルに従って、サーバー側受信部１１３・送信部１１４を経由してＷｅｂサーバー（www.aaa.co.jp）とＳＳＬハンドシェイクを行なう（ステップＳ１６，Ｓ１７，Ｓ１８、Ｐ２）。このハンドシェイクには、Ｗｅｂサーバー（www.aaa.co.jp）が持っているサーバー証明書と秘密鍵を用いて実現される。こうして確立された第２のＳＳＬコネクションで利用される共通鍵ｋ０３はサーバー側復号化部１４３及びサーバー側復号化部１４４に渡される（ステップＳ１９）。
【００４４】
なお、ステップＳ４において、該当するＷｅｂサーバーが複製サーバー鍵保持部１２３に登録されていない場合は、例えばＤＮＳやＨｏｓｔｓファイル等により、リクエストされたＷｅｂサーバーがネットワーク内に存在するかを調べ（ステップＳ５）、該当するＷｅｂサーバーがネットワーク内に存在するときは（ステップＳ６）、通常のフォーワード型プロキシと同様にＷｅｂブラウザ４０１に対して“200 Connection Established”メッセージを送信して、トンネリングの準備が完了した旨を通知する（ステップＳ７）。以後、Ｗｅｂブラウザ４０１−Ｗｅｂサーバー２０１（www.aaa.co.jp）の間でＣｌｉｅｎｔ Ｈｅｌｌｏから始まるＳＳＬハンドシェイクが実行されＳＳＬコネクションが確立される（ステップＳ８）。ＳＳＬハンドシェイク中及び暗号化通信中は、プロキシはＷｅｂブラウザ４０１−Ｗｅｂサーバー２０１間のデータ交換をトンネリングする。他方、該当するＷｅｂサーバーがネットワーク内に存在しないときは（ステップＳ９）、“404 Not Found”というＨＴＴＰレスポンスをＷｅｂブラウザ４０１にクライアント側送信部１１２を経由して送信する。
【００４５】
図６に、プロキシ１の複製サーバー鍵保持部１２３の構造例を示す。
【００４６】
この構造例では、複製サーバー鍵保持部１２３は、サーバー名を識別子として、当該サーバー名が示すＷｅｂサーバーの複製されたサーバー証明書へのポインタ及び秘密鍵へのポインタを持つ。この例では、ポインタとしてファイル名が指定されているが、例えば、メモリ上のアドレスを持つなどの他の方法でもよい。
【００４７】
図７に、第１のＳＳＬコネクション及び第２のＳＳＬコネクションが確立された後のプロキシ１上でのＷｅｂ通信プロセスの説明を簡易化するために、図２からサーバー情報管理部１２０とＳＳＬコネクション確立部１３０を省いた構成要素を示す。
【００４８】
第１及び第２のＳＳＬコネクションが確立された後、Ｗｅｂブラウザ４０１から例えば“GET www.aaa.co.jp/hello.html HTTP/1.0”というリクエストが送信されたとする（Ｐ４）。このリクエストは、第１のＳＳＬコネクションでＷｅｂブラウザとプロキシ１で交換された共通鍵ｋ０２で暗号化されている。プロキシ１のクライアント側受信部１１１が暗号化されたリクエストを受信すると、該暗号化されたリクエスト（図中、３１）はクライアント側復号化部１４１で共通鍵ｋ０２によって復号化される。復号化されたリクエスト（図中、３２）は第２のＳＳＬコネクションでＷｅｂサーバー（www.aaa.co.jp）と交換した共通鍵ｋ０３をによってサーバー側暗号化部１４４で暗号化され、該暗号化されたリクエスト（図中、３３）はサーバー側送信部１１４からＷｅｂサーバー（www.aaa.co.jp）へ送信される（Ｐ５）。
【００４９】
送信されてきた暗号化されたリクエストを受けたＷｅｂサーバー（www.aaa.co.jp）は、これを共通鍵ｋ０３で復号化し、該リクエストをもとにレスポンスを生成し、該レスポンスを共通鍵ｋ０３で暗号化し、これをプロキシ１へ送信する（Ｐ６）。
【００５０】
プロキシ１のサーバー側受信部１１３は、送信されてきた暗号化されたレスポンスをサーバー側受信部１１３で受信し、サーバー側復号部１４３で該暗号化されたレスポンス（図中、３４）を共通鍵ｋ０３によって復号化する。復号化されたレスポンス（図中、３５）は、例えばキャッシュやデータ圧縮や差分情報の抽出などの所定のデータ処理をデータ処理部１５１で施された後、クライアント側暗号化部１４２で共通鍵ｋ０２によって暗号化され、該暗号化されたレスポンス（図中、３６）はクライアント側送信部１１２を経由してブラウザ４０１へ送信される（Ｐ７）。
【００５１】
以上説明してきたように、本実施形態のプロキシ１は、サーバー名取得部１２１、複製サーバー鍵取得部１２２、複製サーバー鍵保持部１２３という新たな手段を持つことで、従来トンネリングしてきたＷｅｂブラウザ−Ｗｅｂサーバー間で確立されるＳＳＬコネクションによって暗号化されたデータをプロキシ上で復号化し、データ処理部１５１によって復号化されたデータに対して所望のデータ処理を行なうことが可能となる。
【００５２】
また、図１に示すように、本実施形態のプロキシ１と複数のＷｅｂサーバーをファイアーウォールに守られた安全なネットワークに配置することで、複数のＷｅｂサーバーとＷｅｂブラウザとの通信をプロキシ上で復号化・データ処理を行なうデータ提供システムの構築が可能となる。
【００５３】
なお、クライアント側ＳＳＬハンドシェイク部１３１・クライアント側復号化部１４１・クライアント側暗号化部１４２は、通常、Ｗｅｂサーバーに備わっている機能である。サーバー側ＳＳＬハンドシェイク部１３２・サーバー側復号化部１４３・サーバー側暗号化部１４４は、通常、Ｗｅｂブラウザに備わっている機能である。これらは、ＳＳＬプロトコルを実装したソフトウェアもしくはハードウェアである。
【００５４】
データ処理部１５１には、例えば、ｓｑｕｉｄ等の従来のプロキシでも行なってきた静的ページのキャッシュや、画像の圧縮等の処理が該当する。静的なページとは、サーバー上にスタティックに配置されたｈｔｍｌや画像ファイル等といったＷｅｂリソースの事を指し、ＨＴＴＰプロトコルで規定される有効期限内ではアクセスの度に変更されないものである。なお、本実施形態のデータ処理部１５１は、静的なページのキャッシュに加え動的なページのキャッシュについても適用可能である。動的なページとは、ＣＧＩ、ＡＳＰ、Ｓｅｒｖｌｅｔ等が代表する動的ページ生成技術によって生成されたページのことを指し、Ｗｅｂサーバーへリクエストが届いた時点で上記プログラムによって生成されるページのことである。動的なページはアクセスの度にページの内容が変化し、従来の静的なページをキャッシュするｓｑｕｉｄなどのプロキシ・プログラムでは、キャッシュの対象外となっていた。特開２００２−２６８９３５に示されたフィンガープリントを用いたキャッシュ機構を備えることで、フィンガープリントのみの転送やベースコンテンツからの差分データとフィンガープリントのみの転送ですみ、ネットワーク上を流れるデータ転送量を削減することが可能であるが、本実施形態のデータ処理部１５１は、このフィンガープリントキャッシュもその対象とすることが可能である。この場合、プロキシ１は、サーバー側プロキシを兼ねることとなる。また、クライアント側プロキシは、別途、クライアント４上に、あるいはクライアント４に接続された計算機上に、構築されることとなる。クライアント側プロキシがＷｅｂブラウザのＰｌｕｇ−ｉｎとして実現されている場合は、本実施形態で示されている構成でよい。
【００５５】
次いで、図８に、図２のプロキシ１を修正した構成例を示す。この構成例は、ネットワーク経由でＷｅｂサーバーからサーバー証明書・秘密鍵の複製をサーバー鍵保持部１２３に登録する、ネットワーク経由複製サーバー鍵登録部１２５を備えたものである。なお、図２の構成例の複製サーバー鍵登録部１２４の代わりに、ネットワーク経由複製サーバー鍵登録部１２５を備えてもよいし、図２の構成例の複製サーバー鍵登録部１２４に加えて、ネットワーク経由複製サーバー鍵登録部１２５を更に備えてもよい。
【００５６】
他方、図９に、ネットワーク経由複製サーバー鍵登録部１２５を備えたプロキシ１に対応するために、鍵取得リクエストを判定する複製鍵取得リクエスト判別部２２１とサーバー証明書・秘密鍵の複製が記載されたレスポンスを生成する複製鍵記載部２２２を備えたＷｅｂサーバー２０４を示す（なお、図９では、説明を簡略化するために、受信部及び送信部を含む通信部２１０以外の部分をまとめてサーバー処理部２２０として示している）。
【００５７】
図１０に、この場合の処理手順の一例を示す。
【００５８】
ネットワーク経由複製サーバー鍵登録部１２５は、例えばキーボード等の入力装置や設定ファイル等によって指定されたＷｅｂサーバー２０４とＳＳＬコネクションを確立するために、サーバー側ハンドシェイク部１３２に指令を出す。サーバー側ＳＳＬハンドシェイク部１３２は、サーバー側送信部１１４・受信部１１３を経由してＷｅｂサーバーとＳＳＬハンドシェイクプロトコルに従ってＳＳＬコネクションを確立する。このＳＳＬハンドシェイクによってＷｅｂサーバー２０４と交換された共通鍵ｋ０４は、サーバー側復号化部１４３、サーバー側暗号化部１４４に渡される。ＳＳＬコネクションが確立された後、ネットワーク経由複製サーバー鍵登録部１２５は、サーバー側暗号化部１４４によって暗号化された、複製鍵取得リクエストを、サーバー側送信部１１４に送信する。このリクエストは、ＨＴＴＰのプロトコルに従った書式であって、ＨＴＴＰヘッダーもしくはＨＴＴＰボディー部分に鍵取得リクエストであることが分かる記述があればどのようなものでもよい。例えば、図１１に示すようにＨＴＴＰヘッダーのＣｏｎｔｅｎｔ−Ｔｙｐｅに鍵取得要求であることを示すｔｅｘｔ／ｋｅｙ−ｅｘｃｈａｎｇｅ−ｒｅｑｕｅｓｔを明示する等の方法でもよい。
【００５９】
リクエストを受けたＷｅｂサーバー２０４は、複製鍵リクエスト判別部２２１によって複製鍵要求リクエストであることを判定すると、Ｗｅｂサーバー２０４上にあるサーバー証明書・秘密鍵の複製を取得し、複製鍵記載部２２２によってＨＴＴＰヘッダーもしくはＨＴＴＰボディーに複製サーバー証明書・秘密鍵ｋ０５を記載したレスポンスを生成する。このレスポンスはＨＴＴＰプロトコルに従った書式であって、ＨＴＴＰヘッダーもしくはＨＴＴＰボディー部分に複サーバー証明書・秘密鍵が記載されている。例えば、図１２に示すようなレスポンスでもよい。レスポンスは、共通鍵ｋ０４によって暗号化された後、Ｗｅｂサーバーから送信され、プロキシ１のサーバー側受信部１１３は、そのレスポンスを受信する。受信したレスポンスは、サーバー側復号化部１４３で共通鍵ｋ４によって復号化され、ネットワーク経由複製サーバー鍵登録部１２５に渡される。ネットワーク経由複製サーバー鍵登録部１２５は、レスポンスから複製サーバー証明書・秘密鍵ｋ０５を抽出し、複製サーバー鍵保持部１２３に登録する。もし、既に同名のサーバーが登録されている場合は、取得した複製サーバー証明書・秘密鍵ｋ０５を上書き登録する。
【００６０】
このように、プロキシ側にネットワーク経由複製サーバー鍵登録部１２５を備え、対象サーバー側に複製鍵取得リクエスト判別部２２１と複製鍵記載部２２２を備えることで、ネットワーク経由で対象サーバーのサーバー証明書・秘密鍵の複製をプロキシ１の複製鍵保持部１２３に登録することが可能となる。
【００６１】
これによって、新規Ｗｅｂサーバー導入時や、サーバー証明書の期限切れがきた場合の更新に手間を大幅に省くことが可能となる。
【００６２】
また、本実施形態のプロキシ１及び複数のＷｅｂサーバーによって、暗号化されたデータをプロキシ１上で復号化し、データ処理を施すことが可能なデータ提供システムを構築することが可能となる。
【００６３】
なお、以上の各機能は、ソフトウェアとして実現可能である。
【００６４】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【００６５】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
【００６６】
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
【００６７】
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【００６８】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【００６９】
【発明の効果】
本発明によれば、複数のサーバー装置を対象として、各サーバー装置と各クライアント装置との間でデータを暗号化してやり取りする場合に、該暗号化されたデータを復号化したものを用いたデータ処理を行うことが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るシステムの構成例を示す図
【図２】同実施形態に係るプロキシの構成例を示す図
【図３】同実施形態に係るプロキシを用いた場合のＳＳＬコネクションを説明するための概念図
【図４】同実施形態におけるＷｅｂブラウザ、プロキシ、Ｗｅｂサーバー間のデータの流れの一例を示す図
【図５】同実施形態における第１のＳＳＬコネクション及び第２のＳＳＬコネクションを確立する処理の流れの一例を示すフローチャート
【図６】同実施形態におけるプロキシの複製サーバー鍵保持部の内部構成例を示す図
【図７】同実施形態における第１のＳＳＬコネクション及び第２のＳＳＬコネクションが確立した後のプロキシ内のデータの流れの一例を示す図
【図８】同実施形態に係るプロキシの他の構成例を示す図
【図９】同実施形態に係るサーバーの構成例を示す図
【図１０】同実施形態におけるネットワーク経由で複製サーバー証明書・秘密鍵を登録する際の処理手順の一例を示すフローチャート
【図１１】同実施形態における鍵取得リクエストの一例を示す図
【図１２】同実施形態における鍵取得リクエストに対応するレスポンスの一例を示す図
【符号の説明】
１…プロキシ（情報転送装置）、２０１〜２０４…Ｗｅｂサーバー、３…ファイアーウォール、４…クライアント、４０１…Ｗｅｂブラウザ、５…イントラネット、６…ＬＡＮ、７…外部ネットワーク、１１０…通信部、１１１…クライアント側受信部、１１２…クライアント側送信部、１１３…サーバー側受信部、１１４…サーバー側送信部、１２０…サーバー情報管理部、１２１…サーバー名取得部、１２２…複製サーバー鍵取得部、１２３…複製サーバー鍵保持部、１２４…複製サーバー鍵登録部、１２５…ネットワーク経由複製サーバー鍵登録部、１３０…ＳＳＬコネクション確立部、１３１…クライアント側ＳＳＬハンドシェイク部、１３２…サーバー側ＳＳＬハンドシェイク部、１４０…暗号化・復号化部、１４１…クライアント側復号化部、１４２…クライアント側暗号化部、１４３…サーバー側復号化部、１４４…サーバー側暗号化部、１５０，１５１…データ処理部、２２１…複製鍵取得リクエスト判別部、２２２…複製鍵記載部

Claims (20)

1. クライアント装置から送信された、サーバー装置への接続要求メッセージを受信するための手段と、
   前記接続要求メッセージが受信された場合に、前記サーバー装置を代行して、前記クライアント装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するための第１のコネクション設定手段と、
   前記接続要求メッセージが受信された場合に、前記サーバー装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定するための第２のコネクション設定手段とを備えたことを特徴とするデータ転送装置。
2. 複数の前記サーバー装置のそれぞれについて、当該サーバー装置との間でデータを暗号化して転送するためのコネクションを設定する際に必要となる、当該サーバー装置に固有の情報を記憶するための記憶手段を更に備え、
   前記第１のコネクション設定手段は、前記記憶手段に記憶された、前記サーバー装置に固有の情報を用いて、前記クライアント装置との間で、前記第１のコネクションを設定し、
   前記第２のコネクション設定手段は、前記記憶手段に記憶された、前記サーバー装置に固有の情報を用いて、前記サーバー装置との間で、前記第２のコネクションを設定することを特徴とする請求項１に記載のデータ転送装置。
3. 前記サーバー装置に固有の情報は、当該サーバー装置の正当性を保証するためのサーバー証明書と、データを暗号化して転送するにあたって用いられる秘密鍵とを含むものであることを特徴とする請求項２に記載のデータ転送装置。
4. 前記第１のコネクション設定手段は、前記秘密鍵に基づく公開鍵暗号方式によって、前記第１のコネクションを転送するデータを暗号化するための第１の共通鍵を、前記クライアント装置との間で共有することを特徴とする請求項３に記載のデータ転送装置。
5. 前記第２のコネクション設定手段は、前記秘密鍵に基づく公開鍵暗号方式によって、前記第２のコネクションを転送するデータを暗号化するための第２の共通鍵を、前記サーバー装置との間で共有することを特徴とする請求項３または４に記載のデータ転送装置。
6. 前記記憶手段は、前記サーバー装置のサーバー名を識別子として、前記サーバー装置に固有の情報を記憶するものであり、
   前記データ転送装置は、前記クライアント装置から前記接続要求メッセージが受信された場合に、該接続要求メッセージに含まれるサーバー装置に関する情報に基づいて、前記サーバー装置のサーバー名を特定し、該特定したサーバー名に基づいて、前記記憶手段から該特定したサーバー名を持つサーバー装置に固有の情報を取得して、前記第１及び第２のコネクション設定手段に与えるための手段を更に備えたことを特徴とする請求項２ないし５のいずれか１項に記載のデータ転送装置。
7. 前記クライアント装置からの前記接続要求メッセージが受信された場合に、該接続要求メッセージに係る前記サーバー装置に固有の情報が前記記憶手段に記憶されていないときは、該クライアント装置と該サーバー装置との間のデータ転送については、前記第１及び第２のコネクションの設定をせずに、データのトンネリングを行うことを特徴とする請求項１ないし６のいずれか１項に記載のデータ転送装置。
8. 前記記憶手段に前記サーバー装置に固有の情報が未だ記憶されていないサーバー装置との間で、該サーバー装置に固有の情報を暗号化して転送するための第３のコネクションを設定した後に、該第３のコネクションを介して、該サーバー装置から該サーバー装置に固有の情報を受信するための手段と、
   受信した前記サーバー装置に固有の情報を前記記憶手段に登録するための手段とを更に備えたことを特徴とする請求項２ないし７のいずれか１項に記載のデータ転送装置。
9. 前記第１のコネクションを介して、前記クライアント装置から転送されてきた、暗号化されたリクエストメッセージを受信するための手段と、
   受信された前記暗号化されたリクエストメッセージを復号化するための手段と、
   復号化された前記リクエストメッセージに対して、所定のデータ処理を施すための第１の処理手段と、
   前記所定のデータ処理を施された前記リクエストメッセージを再度暗号化するための手段と、
   暗号化された前記リクエストメッセージを前記第２のコネクションを介して前記サーバー装置へ送信するための手段とを更に備えたことを特徴とする請求項１ないし８のいずれか１項に記載のデータ転送装置。
10. 前記第１の処理手段は、前記所定のデータ処理として、キャッシュ処理又は静的若しくは動的の圧縮処理を行うものであることを特徴とする請求項９に記載のデータ転送装置。
11. 前記第２のコネクションを介して、前記サーバー装置から転送されてきた、暗号化されたレスポンスメッセージを受信するための手段と、
    受信された前記暗号化されたレスポンスメッセージを復号化するための手段と、
    復号化された前記レスポンスメッセージに対して、所定のデータ処理を施すための第２の処理手段と、
    前記所定のデータ処理を施された前記レスポンスメッセージを再度暗号化するための手段と、
    暗号化された前記レスポンスメッセージを前記第１のコネクションを介して前記クライアント装置へ送信するための手段とを更に備えたことを特徴とする請求項９または１０に記載のデータ転送装置。
12. 前記第２の処理手段は、前記所定のデータ処理として、キャッシュ処理又は静的若しくは動的の圧縮処理を行うものであることを特徴とする請求項１１に記載のデータ転送装置。
13. 請求項１ないし１２のいずれか１項に記載のデータ転送装置と、複数のサーバー装置とを備えたことを特徴とする情報提供システム。
14. 請求項１ないし１２のいずれか１項に記載のデータ転送装置との間で、前記固有の情報を暗号化して転送するためのコネクションを設定した後に、該コネクションを介して該データ転送装置から前記固有の情報を要求するリクエストメッセージを受信した場合に、前記固有の情報を記述したレスポンスメッセージを該コネクションを介して該データ転送装置へ送信する手段を備えたことを特徴とするサーバー装置。
15. 前記データ転送装置と、複数の前記サーバー装置とを備えたことを特徴とする請求項１４に記載の情報提供システム。
16. 前記情報提供システムを、ファイアーウォールに守られた安全なイントラネット内に構築したことを特徴とする請求項１３または１５に記載の情報提供システム。
17. クライアント装置から送信された、サーバー装置への接続要求メッセージを受信するステップと、
    前記接続要求メッセージが受信された場合に、前記サーバー装置を代行して、前記クライアント装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するステップと、
    前記接続要求メッセージが受信された場合に、前記サーバー装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定するステップとを有することを特徴とするデータ転送方法。
18. 前記第１のコネクションを介して、前記クライアント装置から転送されてきた、暗号化されたリクエストメッセージを受信するステップと、
    受信された前記暗号化されたリクエストメッセージを復号化するステップと、
    復号化された前記リクエストメッセージに対して、所定のデータ処理を施すステップと、
    前記所定のデータ処理を施された前記リクエストメッセージを再度暗号化するステップと、
    暗号化された前記リクエストメッセージを前記第２のコネクションを介して前記サーバー装置へ送信するステップとを更に有することを特徴とする請求項１７に記載のデータ転送方法。
19. 前記第２のコネクションを介して、前記サーバー装置から転送されてきた、暗号化されたレスポンスメッセージを受信するステップと、
    受信された前記暗号化されたレスポンスメッセージを復号化するステップと、復号化された前記レスポンスメッセージに対して、所定のデータ処理を施すステップと、
    前記所定のデータ処理を施された前記レスポンスメッセージを再度暗号化するステップと、
    暗号化された前記レスポンスメッセージを前記第１のコネクションを介して前記クライアント装置へ送信するステップとを更に有することを特徴とする請求項１７または１８に記載のデータ転送方法。
20. コンピュータをデータ転送装置として機能させるためのプログラムであって、
    クライアント装置から送信された、サーバー装置への接続要求メッセージを受信するための機能と、
    前記接続要求メッセージが受信された場合に、前記サーバー装置を代行して、前記クライアント装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第１のコネクションを設定するための機能と、
    前記接続要求メッセージが受信された場合に、前記サーバー装置との間で、前記クライアント装置と前記サーバー装置との間で受け渡しされるデータを暗号化して転送するための第２のコネクションを設定するための機能とをコンピュータに実現させるためのプログラム。

Images