(57)【要約】【課題】【解決手段】ネットワーク・ベースのアプライアンスは、セッション・キャッシュが維持されることを必要とすることなく、セッション再開と共にＴＬＳ検査をもたらすメカニズムを含む。この目的で、インスペクタは、実質的にＴＬＳインスペクタの代わりに、セッション・コンテキストを維持することにＴＬＳクライアントを参加させるように構成される。動作中に、インスペクタが、セッション・チケットをキャッシングする代わりに、ＴＬＳサーバからセッション・チケットを最初に受け取るとき、インスペクタは、元のチケットと、セッション・キーを含むセッション・コンテキスト情報とを含む複合チケットを生成し、その複合チケットをクライアントに発行する。複合チケットは、セッション情報をセキュアにするためにインスペクタによって暗号化される。ＴＬＳクライアントが、ＴＬＳ接続を再開するために、複合セッション・チケットを与えるとき、インスペクタは、チケットを暗号化解除し、チケットからセッション・コンテキストを直接取り出す。次いで、インスペクタは、ＴＬＳセッションを再開するために元のセッション・チケットを使用する。【選択図】図６
2020522164.tif 000002
【特許請求の範囲】
【請求項１】
トランスポート・レイヤ・セキュリティ（ＴＬＳ）クライアントとＴＬＳサーバとの間に配置されＴＬＳセッション中にＴＬＳ検査機能を提供する、中間ノード内で実行可能な方法であって、
前記ＴＬＳサーバから元のセッション・チケットを受け取ると、新規セッション・チケットを生成することと、
前記新規セッション・チケットに暗号化関数を適用することと、
前記暗号化された新規セッション・チケットを前記ＴＬＳクライアントに出力することと、
前記ＴＬＳクライアントから前記暗号化された新規セッション・チケットを受け取ると、前記元のセッション・チケットおよびセッション・コンテキスト情報を復元するために前記暗号化された新規セッション・チケットを暗号化解除することと、
前記ＴＬＳセッションを再開するために前記復元された元のセッション・チケットおよび前記セッション・コンテキスト情報を使用することと
を含む、方法。
【請求項２】
前記新規セッション・チケットが、前記ＴＬＳセッションに関連する、前記元のセッション・チケットおよびセッション・コンテキスト情報に、変換関数を適用することによって生成される、請求項１に記載の方法。
【請求項３】
前記変換関数が、前記元のセッション・チケットと前記セッション・コンテキスト情報を連結する、請求項２に記載の方法。
【請求項４】
前記暗号化された新規セッション・チケットを、クライアント・ハロー内で前記ＴＬＳクライアントから受け取る、請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記ＴＬＳセッションが、前記クライアント・ハロー内の前記暗号化された新規セッション・チケットを、前記元のセッション・チケットと交換し、前記クライアント・ハローを前記ＴＬＳサーバに転送することによって少なくとも部分的に再開される、請求項４に記載の方法。
【請求項６】
前記セッション・コンテキスト情報を使用することが、セッション・キーを取得することを含む、請求項１ないし５のいずれかに記載の方法。
【請求項７】
前記元のセッション・チケットのペイロードを暗号化解除するために前記セッション・キーを使用することをさらに含む、請求項６に記載の方法。
【請求項８】
前記新規セッション・チケットが生成され、前記暗号化された新規セッション・チケットが、セッション・キャッシュ内の前記元のセッション・チケットをキャッシングする代わりに出力される、請求項１ないし７のいずれかに記載の方法。
【請求項９】
装置であって、
プロセッサと、
前記プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリであって、前記コンピュータ・プログラム命令が、
ＴＬＳサーバから元のセッション・チケットを受け取ると、新規セッション・チケットを生成することと、
前記新規セッション・チケットに暗号化関数を適用することと、
前記暗号化された新規セッション・チケットをＴＬＳクライアントに出力することと、
前記ＴＬＳクライアントから前記暗号化された新規セッション・チケットを受け取ると、前記元のセッション・チケットおよびセッション・コンテキスト情報を復元するために前記暗号化された新規セッション・チケットを暗号化解除することと、
ＴＬＳセッションを再開するために前記復元された元のセッション・チケットおよび前記セッション・コンテキスト情報を使用することと
を行うように構成されたプログラム・コードを含む、前記コンピュータ・メモリと
を含む、装置。
【請求項１０】
前記新規セッション・チケットが、前記ＴＬＳセッションに関連する、前記元のセッション・チケットおよびセッション・コンテキスト情報に、変換関数を適用することによって生成される、請求項９に記載の装置。
【請求項１１】
前記変換関数が、前記元のセッション・チケットと前記セッション・コンテキスト情報を連結する、請求項１０に記載の装置。
【請求項１２】
前記暗号化された新規セッション・チケットを、クライアント・ハロー内で前記ＴＬＳクライアントから受け取る、請求項９ないし１１のいずれかに記載の装置。
【請求項１３】
前記ＴＬＳセッションが、前記クライアント・ハロー内の前記暗号化された新規セッション・チケットを、前記元のセッション・チケットと交換し、前記クライアント・ハローを前記ＴＬＳサーバに転送することによって少なくとも部分的に再開される、請求項１２に記載の装置。
【請求項１４】
前記セッション・コンテキスト情報を使用することが、セッション・キーを取得することを含む、請求項９ないし１３のいずれかに記載の装置。
【請求項１５】
前記元のセッション・チケットのペイロードを暗号化解除するために前記セッション・キーを使用することをさらに含む、請求項１４に記載の装置。
【請求項１６】
前記新規セッション・チケットが生成され、前記暗号化された新規セッション・チケットが、セッション・キャッシュ内の前記元のセッション・チケットをキャッシングする代わりに出力される、請求項９ないし１５のいずれかに記載の装置。
【請求項１７】
トランスポート・レイヤ・セキュリティ（ＴＬＳ）セッション中のＴＬＳ検査機能のためのコンピュータ・プログラム製品であって、
処理回路によって可読で、請求項１ないし８のいずれかに記載の方法を実行するために前記処理回路による実行のための命令を記憶する、コンピュータ可読記憶媒体
を含む、コンピュータ・プログラム製品。
【請求項１８】
コンピュータ可読媒体上に記憶されデジタル・コンピュータの内部メモリ内にロード可能なコンピュータ・プログラムであって、請求項１ないし８のいずれかに記載の方法を実行するために、前記プログラムがコンピュータ上で実行されるとき、ソフトウェア・コード部分を含む、コンピュータ・プログラム。
【請求項１９】
トランスポート・レイヤ・セキュリティ（ＴＬＳ）クライアントとＴＬＳサーバとの間に配置された装置であって、
ハードウェア・プロセッサと、
コンピュータ・メモリであって、
前記ＴＬＳサーバからセッション・チケットを受け取ることと、それに応答して、（ａ）複合セッション・チケットを生成することと、（ｂ）前記セッション・チケットをキャッシングする代わりに前記複合セッション・チケットを前記ＴＬＳクライアントに出力することと、
前記ＴＬＳクライアントから前記複合セッション・チケットを受け取ることと、それに応答して、（ｃ）前記セッション・チケットを復元することと、（ｄ）前記ＴＬＳサーバによってセッションを再開するために前記復元されたセッション・チケットを使用することと
を行うようにキャッシュのないＴＬＳインスペクタ・メカニズムとして構成されたコンピュータ・プログラム命令を保持する前記コンピュータ・メモリと
を含む、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、ネットワークに接続されるアプライアンスに関する情報セキュリティに関する。
【背景技術】
【０００２】
セキュリティに対する脅威は、絶えず進化している。最先端のウェブ・アプリケーションの急速な発達およびファイル共有の増加に伴って、過去には無害と考えられてきた可能性があるアクティビティが、攻撃者に対する潜在的な穴になる可能性がある。マルウェア対策ソフトウェアおよびファイアウォールなどの従来のセキュリティ手段は、比較的容易にバイパスされるようになった。したがって、新たに発生する脅威に対する広範囲のセキュリティを提供するのを助けることができる、より進歩しかつ先を見越した、脅威からの保護が大いに必要となる。
【０００３】
ネットワークに接続される非表示デバイス（「アプライアンス」）が、多くのコンピューティング環境において至る所に存在する。たとえば、従来のミドルウェア・サービス指向アーキテクチャ（ＳＯＡ）機能を実行するために意図的に構築されたアプライアンスは、いくつかのコンピュータ環境にわたって普及している。ＳＯＡミドルウェア・アプライアンスは、一企業にわたる既存のＳＯＡインフラストラクチャを拡張しながら、ＸＭＬ／Ｗｅｂサービス展開を簡略化し、セキュアにするのを助け、または加速する可能性がある。ミドルウェア用ハードウェアおよび軽量ミドルウェア・スタックの利用は、従来のソフトウェア・ソリューションが受ける動作負担に対処することができる。加えて、アプライアンスのフォーム・ファクタは、ミドルウェアＳＯＡ機能を実装するためのセキュアな消耗パッケージングを提供する。これらのタイプのデバイスが提供する１つの具体的な利点は、バックエンド・システムの処理をオフロードすることである。この目的で、ネットワーク・セキュリティに関する、計算コストが高いプロセスを実行するために、そのようなミドルウェア・デバイスを使用することがよく知られている。たとえば、ネットワーク侵入防止システム（ＩＰＳ）アプライアンスは、内部のネットワーク、サーバ、エンドポイント、およびアプリケーションなどのビジネスに不可欠な資産を、悪意のある脅威から保護するために、一企業のネットワークへの侵入地点に位置するように設計される。
【０００４】
ネットワーク通信用のセキュア・ソケット・レイヤ（ＳＳＬ）またはトランスポート・レイヤ・セキュリティ（ＴＬＳ）あるいはその両方がベースの暗号化の使用は、一般に、ネットワーク内の脅威のトラフィックを識別し、それを軽減する能力を抑制する。現在、すべてのビジネス・ネットワーク・トラフィックの２／３以上は、ＳＳＬ／ＴＬＳを介して伝達されると推定されている。このことは、ネットワーク通信に依拠する組織が、通常、そのような脅威の影響を受けやすい可能性がある、その企業内のエンドポイントを（ネットワークから）保護することができないことを意味する。実際に、ＳＳＬ／ＴＬＳ通信の大部分は、サーバ認証のみを使用し、すなわち、サーバは、ＳＳＬ／ＴＬＳプロトコルを介してクライアントに対して認証されるが、クライアントは、サーバに対して認証されない。この認証の非対称性は、通信の暗号化解除およびそのコンテンツの検査を可能にするように、クライアントとサーバとの間にプロセスがそれ自体を差し挟む機会をもたらす。そのような「マン・イン・ザ・ミドル」（ＭＩＴＭ）プロセスは、悪意があるか、または、パケット検査（脅威検出用）などのもっともな理由のために使用される場合がある。
【０００５】
したがって、一方はクライアントからターゲット・サーバまで、他方はサーバから開始したクライアントまでの、２つの独立したＳＳＬ／ＴＬＳセッションを作成および管理するように構成することができる、クライアントとサーバとの間の透過的な（ＭＩＴＭ）プロキシを提供することが知られている。したがって、中間プロキシは、サーバにはクライアントに見え、クライアントには目的のサーバに見える。クライアントから開始された通信およびサーバから受け取った任意の応答は、理論的には、次に、ＳＳＬ／ＴＬＳインスペクタによる検査および後続の動作に利用可能である。
【０００６】
ＳＳＬ／ＴＬＳ接続のマン・イン・ザ・ミドル検査を実行するとき、ＴＬＳセッション再開のＳＳＬ／ＴＬＳインスペクタによるサポートは、重要な要件である。従来、よく知られているように、ＴＬＳサーバは、２つの異なる方法、すなわち、セッションＩＤ（ＲＦＣ４５０７）およびセッション・チケット（ＲＦＣ５０７７）の一方に従って、（ＭＩＴＭに関わらず）セッション再開をクライアントに提供する。セッションＩＤは、ＳＳＬ／ＴＬＳハンドシェークをスピードアップし、セッション再開を可能にするために発明された第１のメカニズムだった。セッションＩＤでは、セッション情報のすべては、サーバ側に記憶される。セッションＩＤによるセッション再開は、いくつかの欠点を有するが、真っ先に挙げられるものは、多数のキャッシュされたセッションが存在するとき、このセッション再開が、所与のセッションＩＤを検索するための時間および空間を費やす必要性による性能ボトルネックになることである。セッションＩＤの別の主要な欠点は、１つのセッションＩＤが、１つのサーバに対して機能することができるのみで、複数のセッション・キャッシュがサーバ全体にわたって同期されなければ、展開を拡大するのを極めて難しくすることである。セッションＩＤの欠点に対処するために、セッション・チケットが開発された。セッション・チケットは、ＴＬＳサーバが、セッションを再開し、クライアントごとのセッション状態を保持するのを避けることを可能にするメカニズムである。この目的で、ＴＬＳサーバは、セッション状態をカプセル化してチケットにし、それをクライアントに転送する。チケットは、サービス・プロバイダによって署名される。クライアントは、続いて、取得されたチケットを使用してセッションを再開することができる。サーバが後にチケットを受け取って、チケットがサービス・プロバイダによって署名されたと判定したとき、サーバは、チケットに記憶されたすべての設定を受け取る。セッション・チケットは、その拡張性およびサーバ側のより少ないリソースのオーバーヘッドのために、ウェブ・サーバの間で広く使用されている。
【０００７】
ＴＬＳ検査におけるセッション・チケットを（たとえば、透過的なＭＩＴＭプロキシによって）サポートするために、キャッシングは、チケットとセッション・キーとの間のマッピングを維持するために必要である。これは、暗号化メカニズムが、アプリケーション／サービスによって制御され、ＳＳＬ／ＴＬＳ仕様によって定義されないので、セッション・チケットを暗号化解除するための実用的な方法が存在しないからである。しかし、インスペクタ内にセッション・キャッシュを維持することは、セッション・キャッシュを分散させることの難しさによる不十分な拡張性、プロキシをキャッシュの不足に陥らせる可能性があるストレージおよびメモリの制約によるセッション・キャッシュ・サイズの制限、キャッシュ検索時間を複雑にし、セッション・チケットをマッピングするために実装することができるハッシュ・アルゴリズムのタイプを限定するＣＰＵバウンド、ならびにセッション・キャッシュ内のエントリを意図的に締め出し、それによって検査をバイパスする可能性がある攻撃者によるサービス拒否攻撃に対する脆弱性を含む、いくつかの欠点を有する。
【０００８】
セッション・チケット・サポートを提供しながらも、先行の手法においてこれらの欠点および関連の欠点を克服する、ＴＬＳインスペクタにおけるＴＬＳセッション再開が依然として提供されていない。
【０００９】
したがって、上述の問題に対処するための技術が必要である。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ＴＬＳ検査におけるキャッシュのないセッション・チケット・サポートのための方法、装置、プログラム、およびコンピュータ可読記憶媒体を提供することである。
【課題を解決するための手段】
【００１１】
第１の態様から見ると、本発明は、トランスポート・レイヤ・セキュリティ（ＴＬＳ）クライアントとＴＬＳサーバとの間に配置されＴＬＳセッション中にＴＬＳ検査機能を提供する、中間ノード（intermediary）内で実行可能な方法を提供し、本方法は、ＴＬＳサーバから元のセッション・チケットを受け取ると、新規セッション・チケットを生成することと、新規セッション・チケットに暗号化関数を適用することと、暗号化された新規セッション・チケットをＴＬＳクライアントに出力することと、ＴＬＳクライアントから暗号化された新規セッション・チケットを受け取ると、元のセッション・チケットおよびセッション・コンテキスト情報を復元するために暗号化された新規セッション・チケットを暗号化解除することと、ＴＬＳセッションを再開するために復元された元のセッション・チケットおよびセッション・コンテキスト情報を使用することとを含む。
【００１２】
さらなる態様から見ると、本発明は、装置を提供し、本装置は、プロセッサと、プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリであって、上記コンピュータ・プログラム命令が、ＴＬＳサーバから元のセッション・チケットを受け取ると、新規セッション・チケットを生成することと、新規セッション・チケットに暗号化関数を適用することと、暗号化された新規セッション・チケットをＴＬＳクライアントに出力することと、ＴＬＳクライアントから暗号化された新規セッション・チケットを受け取ると、元のセッション・チケットおよびセッション・コンテキスト情報を復元するために暗号化された新規セッション・チケットを暗号化解除することと、ＴＬＳセッションを再開するために復元された元のセッション・チケットおよびセッション・コンテキスト情報を使用することとを行うように構成されたプログラム・コードを含む、上記コンピュータ・メモリとを含む。
【００１３】
さらなる態様から見ると、本発明は、トランスポート・レイヤ・セキュリティ（ＴＬＳ）セッション中のＴＬＳ検査機能のためのコンピュータ・プログラム製品を提供し、本コンピュータ・プログラム製品は、処理回路によって可読で、本発明のステップを実行する方法を実行するために処理回路による実行のための命令を記憶する、コンピュータ可読記憶媒体を含む。
【００１４】
さらなる態様から見ると、本発明は、本発明のステップを実行するために、コンピュータ・プログラムがコンピュータ上で実行されるとき、ソフトウェア・コード部分を含む、コンピュータ可読媒体上に記憶されデジタル・コンピュータの内部メモリ内にロード可能なコンピュータ・プログラムを提供する。
【００１５】
さらなる態様から見ると、本発明は、トランスポート・レイヤ・セキュリティ（ＴＬＳ）クライアントとＴＬＳサーバとの間に配置された装置を提供し、本装置は、ハードウェア・プロセッサと、コンピュータ・メモリであって、ＴＬＳサーバからセッション・チケットを受け取ることと、それに応答して、（ａ）複合セッション・チケット（composite session ticket）を生成することと、（ｂ）セッション・チケットをキャッシングする代わりに複合セッション・チケットをＴＬＳクライアントに出力することと、ＴＬＳクライアントから複合セッション・チケットを受け取ることと、それに応答して、（ｃ）セッション・チケットを復元することと、（ｄ）ＴＬＳサーバによってセッションを再開するために復元されたセッション・チケットを使用することとを行うようにキャッシュのないＴＬＳインスペクタ・メカニズムとして構成されたコンピュータ・プログラム命令を保持する上記コンピュータ・メモリとを含む。
【００１６】
ネットワーク・ベースのアプライアンスは、セッション・キャッシュがインスペクタ内に維持されることを必要とすることなく、本アプライアンスがセッション再開と共にＴＬＳ検査をもたらすことを可能にするメカニズムを含む。この目的で、インスペクタは、セッション・キャッシュなしに構成され、したがって、セッション・チケット（ＴＬＳサーバから受け取った）とセッション・コンテキストとの間のマッピングを維持しなくなる。代わりに、インスペクタは、実質的にＴＬＳインスペクタの代わりに、セッション・コンテキストを維持することにＴＬＳクライアントを参加させるように構成される。動作中に、インスペクタが、セッション・チケットをキャッシングする代わりに、ＴＬＳサーバからセッション・チケットを最初に受け取るとき、インスペクタは、元のチケットと、１つまたは複数のセッション・キーを含むセッション・コンテキスト情報とを含む複合チケットを生成し、その複合チケットをクライアントに発行する。通常、２つのセッション・キー、すなわち、一方がクライアント側に、もう一方がサーバ側にある。複合チケット（または複合セッション・チケット）は、セッション情報をセキュアにするためにインスペクタによって暗号化されるのが好ましい。ＴＬＳクライアントが、ＴＬＳ接続を再開するために、複合セッション・チケットを（インスペクタに再び）与えるとき、インスペクタは、チケットを暗号化解除し、チケットからセッション・コンテキストを直接取り出す。次いで、インスペクタは、ＴＬＳサーバへのＴＬＳセッションを再開するために元のセッション・チケットを使用する。この手法は、ＴＬＳインスペクタにおける、任意のキャッシュ検索、またはローカル・セッション・キャッシュを維持する必要性さえも除去する。むしろ、実質的に、複合チケットは、セッション・チケット自体のためのキャッシュになる。
【００１７】
本開示の第１の態様を一般化し、本態様によれば、方法は、クライアントとサーバとの間に配置されＴＬＳ検査機能を提供する、中間ノード内で実行可能である。ＴＬＳサーバから元のセッション・チケットを受け取ると、セッション・キャッシュ内に元のセッション・チケットをキャッシングする代わりに、新規セッション・チケットが生成される。新規セッション・チケットは、元のセッション・チケットおよびセッション・コンテキスト情報（すなわち、セッション中に使用するためにネゴシエートされる暗号スイート、マスター・キーなど）に変換関数を適用することによって導き出された値を含む。変換関数は、様々であってよい。代表的な変換関数は、セッション・コンテキスト情報を元のセッション・チケットに連結する。次いで、セッション情報をセキュアにするために、暗号化関数が、新規セッション・チケット（本明細書では複合セッション・チケットと呼ばれることがある）に適用される。暗号化された変換済みセッション・チケットは、次いで、要求側のＴＬＳクライアントに配信される。後に、そのチケットをＴＬＳクライアントから再び受け取ったとき、そのチケットは、元のセッション・チケットおよびセッション・コンテキスト情報を復元するために暗号化解除される。復元された情報を使用すれば、ＴＬＳセッションは、次いで、ＴＬＳサーバによって再開される。
【００１８】
本開示の第２の態様によれば、装置は、トランスポート・レイヤ・セキュリティ（ＴＬＳ）セッション中にＴＬＳ検査機能を提供するために、ＴＬＳクライアントとＴＬＳサーバとの間に配置される。本装置は、１つまたは複数のハードウェア・プロセッサの組と、上述した方法ステップなどの動作の組を実行するためにハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリとを含む。
【００１９】
本開示の第３の態様によれば、データ処理システムにおいて使用するための非一過性のコンピュータ可読記憶媒体内のコンピュータ・プログラム製品について説明される。データ処理システムは、トランスポート・レイヤ・セキュリティ（ＴＬＳ）セッション中にＴＬＳ検査機能を提供するために、ＴＬＳクライアントとＴＬＳサーバとの間に配置される。コンピュータ・プログラム製品は、データ処理システムにおいて実行され上述した方法ステップなどの動作を実行するように構成された、コンピュータ・プログラム命令を保持する。
【００２０】
上記は、開示された主題とより関連のある特徴のいくつかの概要を述べた。これらの特徴は、単なる例であると解釈されるべきである。多くの他の有利な結果は、開示された主題を様々な方式で適用することによって、または説明される主題を修正することによって達成することができる。
【００２１】
主題およびその利点のより完全な理解のために、次に、添付の図面と併せて行われる以下の説明に参照がなされる。
【図面の簡単な説明】
【００２２】
【図１】例示的な実施形態の例示的な態様が実装される場合がある、分散型データ処理環境の例示的なブロック図である。
【図２】例示的な実施形態の例示的な態様が実装される場合がある、データ処理システムの例示的なブロック図である。
【図３】開示された主題が実装される場合がある、例示的なネットワーク・ベースのセキュアなアプライアンスを示す図である。
【図４】従来のＳＳＬ／ＴＬＳ通信が、セキュアなトラフィックの検査を容易にするためにマン・イン・ザ・ミドル・アプライアンスにおいて、どのように処理されるかを示す図である。
【図５】セッション・キャッシュを含む、ＴＬＳインスペクタを使用したＴＬＳセッション再開を示す図である。
【図６】ＴＬＳインスペクタがキャッシュのないセッション・チケット・サポートを提供する、本開示の主題による、ＴＬＳセッション再開を示す図である。
【発明を実施するための形態】
【００２３】
次に図面を参照すると、特に図１および図２を参照すると、本開示の例示的な実施形態が実装される場合がある、データ処理環境の例示的な図が提供される。図１および図２は、例にすぎず、開示された主題の態様または実施形態が実装される場合がある、環境に関する任意の限定を主張または暗示するものではないことを諒解されたい。図示された環境に対する多くの修正が、本発明の範囲から逸脱することなく、なされてもよい。
【００２４】
クライアント−サーバ技術
次に図面を参照すると、図１は、例示的な実施形態の態様が実装される場合がある、例示的な分散型データ処理システムの図的記述を示す。分散型データ処理システム１００は、例示的な実施形態の態様が実装される場合がある、コンピュータのネットワークを含んでよい。分散型データ処理システム１００は、分散型データ処理システム１００内に共に接続された様々なデバイスおよびコンピュータ間の通信リンクを提供するために使用される媒体である、少なくとも１つのネットワーク１０２を含む。ネットワーク１０２は、有線通信リンク、無線通信リンク、または光ファイバ・ケーブルなどの接続を含む場合がある。
【００２５】
図示した例では、サーバ１０４およびサーバ１０６が、ストレージ・ユニット１０８と共にネットワーク１０２に接続される。加えて、クライアント１１０、１１２、および１１４も、ネットワーク１０２に接続される。これらのクライアント１１０、１１２、および１１４は、たとえば、パーソナル・コンピュータ、ネットワーク・コンピュータなどであってよい。図示した例では、サーバ１０４は、起動ファイル、オペレーティング・システム画像、およびアプリケーションなどのデータを、クライアント１１０、１１２、および１１４に提供する。クライアント１１０、１１２、および１１４は、図示した例では、サーバ１０４に対するクライアントである。分散型データ処理システム１００は、図示されていない、追加のサーバ、クライアント、および他のデバイスを含んでよい。
【００２６】
図示した例では、分散型データ処理システム１００は、互いに通信するためのプロトコルの通信制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）スイートを使用するネットワークおよびゲートウェイのワールドワイド・コレクションを表すネットワーク１０２を有するインターネットである。データおよびメッセージを転送する、何千もの商用、行政用、教育用、および他のコンピュータ・システムから成る、メジャー・ノードまたはホスト・コンピュータ間の高速データ通信ラインのバックボーンは、インターネットの中心にある。当然、分散型データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）などの、いくつかの異なるタイプのネットワークを含むように実装されてもよい。上述のように、図１は、例として意図され、開示された主題の様々な実施形態のアーキテクチャ面の限定として意図されず、したがって、図１に示した具体的な要素は、本発明の例示的な実施形態が実装される場合がある、環境に関する限定と見なされるべきでない。
【００２７】
次に図２を参照すると、例示的な実施形態の態様が実装される場合がある、例示的なデータ処理システムのブロック図が示される。データ処理システム２００は、本開示の例示的な実施形態のためにプロセスを実装するコンピュータ使用可能コードまたは命令が配置される場合がある、図１のクライアント１１０などのコンピュータの一例である。
【００２８】
次に図２を参照すると、例示的な実施形態が実装される場合がある、データ処理システムのブロック図が示される。データ処理システム２００は、例示的な実施形態のためにプロセスを実装するコンピュータ使用可能プログラム・コードまたは命令が配置される場合がある、図１のサーバ１０４またはクライアント１１０などのコンピュータの一例である。この例示的な例では、データ処理システム２００は、プロセッサ・ユニット２０４、メモリ２０６、不揮発性記憶装置２０８、通信ユニット２１０、入力／出力（Ｉ／Ｏ）ユニット２１２、およびディスプレイ２１４の間の通信を提供する、通信構造２０２を含む。
【００２９】
プロセッサ・ユニット２０４は、メモリ２０６内にロードされる場合があるソフトウェアの命令を実行するように機能する。プロセッサ・ユニット２０４は、具体的な実装形態に応じて、１つまたは複数のプロセッサの組であるか、または、マルチ・プロセッサ・コアであってよい。さらに、プロセッサ・ユニット２０４は、メイン・プロセッサが単一チップ上に２次プロセッサと共に存在する、１つまたは複数の異種のプロセッサ・システムを使用して実装される場合がある。別の例示的な例として、プロセッサ・ユニット２０４は、同じタイプのマルチ・プロセッサを含む対称型マルチ・プロセッサ（ＳＭＰ）システムであってよい。
【００３０】
メモリ２０６および不揮発性記憶装置２０８は、記憶デバイスの例である。記憶デバイスは、一時ベースまたは不揮発性ベースあるいはその両方に関する情報を記憶することができるハードウェアの任意の部分である。メモリ２０６は、これらの例では、たとえば、ランダム・アクセス・メモリまたは任意の他の適切な揮発性または不揮発性の記憶デバイスであってよい。不揮発性記憶装置２０８は、具体的な実装形態に応じて様々な形態をとってよい。たとえば、不揮発性記憶装置２０８は、１つまたは複数の構成要素またはデバイスを含んでよい。たとえば、不揮発性記憶装置２０８は、ハード・ドライブ、フラッシュ・メモリ、書換可能光ディスク、書換可能磁気テープ、または上記のいくつかの組合せであってよい。不揮発性記憶装置２０８によって使用される媒体は、取外し可能であってもよい。たとえば、取外し可能なハード・ドライブが、不揮発性記憶装置２０８のために使用されてよい。
【００３１】
通信ユニット２１０は、これらの例では、他のデータ処理システムまたはデバイスによって通信を提供する。これらの例では、通信ユニット２１０は、ネットワーク・インターフェース・カードである。通信ユニット２１０は、物理的な通信リンクまたは無線通信リンクのいずれかあるいはその両方の使用によって通信を提供する場合がある。
【００３２】
入力／出力ユニット２１２は、データ処理システム２００に接続される場合がある、他のデバイスによってデータの入力および出力を可能にする。たとえば、入力／出力ユニット２１２は、キーボードおよびマウスによってユーザ入力のための接続を提供してよい。さらに、入力／出力ユニット２１２は、プリンタに出力を送る場合がある。ディスプレイ２１４は、ユーザに情報を表示するためのメカニズムを提供する。
【００３３】
オペレーティング・システムおよびアプリケーションまたはプログラム用の命令は、不揮発性記憶装置２０８上に配置される。これらの命令は、プロセッサ・ユニット２０４による実行のためにメモリ２０６内にロードされる場合がある。様々な実施形態のプロセスは、メモリ２０６などのメモリ内に配置される場合がある、コンピュータ実装される命令を使用してプロセッサ・ユニット２０４によって実行される場合がある。これらの命令は、プロセッサ・ユニット２０４内のプロセッサによって読まれ実行される場合がある、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれる。様々な実施形態におけるプログラム・コードは、メモリ２０６または不揮発性記憶装置２０８などの、様々な物理的または有形のコンピュータ可読媒体上で具現化されてよい。
【００３４】
プログラム・コード２１６は、選択的に取外し可能であるコンピュータ可読媒体２１８上に関数形式で配置され、プロセッサ・ユニット２０４による実行のためにデータ処理システム２００上にロードされるか、またはデータ処理システム２００に転送されてよい。プログラム・コード２１６およびコンピュータ可読媒体２１８は、これらの例では、コンピュータ・プログラム製品２２０を形成する。一例では、コンピュータ可読媒体２１８は、不揮発性記憶装置２０８の一部であるハード・ドライブなどの記憶デバイス上に転送するための不揮発性記憶装置２０８の一部である、あるドライブまたは他のデバイス内に挿入または配置される、たとえば光ディスクまたは磁気ディスクなどの有形の形態のものであってよい。有形の形態では、コンピュータ可読媒体２１８は、データ処理システム２００に接続される、ハード・ドライブ、サム・ドライブ、またはフラッシュ・メモリなどの不揮発性記憶装置の形態をとってもよい。コンピュータ可読媒体２１８の有形の形態は、コンピュータ記録可能記憶媒体とも呼ばれる。場合によっては、コンピュータ記録可能媒体２１８は、取外し可能でない場合がある。
【００３５】
代替として、プログラム・コード２１６は、通信ユニット２１０への通信リンクまたは入力／出力ユニット２１２への接続あるいはその両方を通して、コンピュータ可読媒体２１８からデータ処理システム２００に転送されてよい。通信リンクまたは接続あるいはその両方は、例示的な例では、物理的または無線であってよい。コンピュータ可読媒体は、プログラム・コードを含む、通信リンクまたは無線伝送などの無形の媒体の形態をとってもよい。データ処理システム２００用として説明した様々な構成要素は、様々な実施形態が実装される場合がある方式に、アーキテクチャ面の限定を与えることを意味すべきでない。様々な例示的な実施形態は、データ処理システム２００用として説明したものに加えて、またはそれらの代わりに、複数の構成要素を含むデータ処理システム内に実装されてよい。図２に示した他の構成要素は、図示した例示的な例と異なる可能性がある。一例として、データ処理システム２００内の記憶デバイスは、データを記憶する場合がある任意のハードウェア装置である。メモリ２０６、不揮発性記憶装置２０８、およびコンピュータ可読媒体２１８は、有形の形態における記憶デバイスの例である。
【００３６】
別の例では、バス・システムは、通信構造２０２を実装するために使用される場合があり、システム・バスまたは入力／出力バスなどの、１つまたは複数のバスから構成される場合がある。当然、バス・システムは、バス・システムに取り付けられた様々な構成要素またはデバイス間のデータの転送を提供する任意の適切なタイプのアーキテクチャを使用して実装されてよい。加えて、通信ユニットは、モデムまたはネットワーク・アダプタなどの、データを伝送および受信するのに使用される１つまたは複数のデバイスを含んでよい。さらに、メモリは、たとえば、通信構造２０２内に存在する場合がある、インターフェースおよびメモリ・コントローラ・ハブに見いだされるメモリ２０６またはキャッシュであってよい。
【００３７】
本発明の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋、Ｃ＃、Ｏｂｊｅｃｔｉｖｅ−Ｃなど、および従来の手続き型プログラミング言語などの、オブジェクト指向プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組合せで書かれてよい。プログラム・コードは、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、独立型ソフトウェア・パッケージとして、ユーザのコンピュータ上で部分的にかつリモート・コンピュータ上で部分的に、またはリモート・コンピュータもしくはサーバ上で完全に実行されてよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意のタイプのネットワークを通してユーザのコンピュータに接続される場合があり、あるいは、（たとえば、インターネット・サービス・プロバイダを使用してインターネットを通して）外部のコンピュータへの接続がなされる場合がある。Ｊａｖａ（Ｒ）およびすべてのＪａｖａ（Ｒ）ベースの商標およびロゴマークは、Ｏｒａｃｌｅ（Ｒ）またはその関連会社あるいはその両方の商標または登録商標である。
【００３８】
当業者は、図１および図２のハードウェアが、実装形態に応じて変化する場合があることを諒解されよう。フラッシュ・メモリ、均等な不揮発性メモリ、または光ディスク・ドライブなどの他の内部ハードウェアまたは周辺デバイスは、図１および図２に示したハードウェアに加えて、またはその代わりに使用されてよい。また、例示的な実施形態のプロセスは、開示された主題の範囲から逸脱することなく、上述したＳＭＰシステム以外のマルチプロセッサ・データ処理システムに適用される場合がある。
【００３９】
わかるように、本明細書に説明する技法は、クライアント・マシンが、１つまたは複数のマシンの組において実行されるインターネット・アクセス可能ウェブ・ベースのポータルと通信する、図１に示した標準的なクライアント−サーバの枠組みと共に動作する場合がある。エンド・ユーザは、ポータルにアクセスしポータルと情報交換することができるインターネット接続可能デバイス（たとえば、デスクトップ・コンピュータ、ノートブック・コンピュータ、インターネット対応モバイル・デバイスなど）を操作する。通常、各クライアントまたはサーバ・マシンは、ハードウェアおよびソフトウェアを含む、図２に示したデータ処理システムであり、これらのエンティティは、インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、または任意の他の通信媒体もしくはリンクなどのネットワークを介して互いに通信する。データ処理システムは、通常、１つまたは複数のプロセッサ、オペレーティング・システム、１つまたは複数のアプリケーション、および１つまたは複数のユーティリティを含む。データ処理システム上のアプリケーションは、特に、限定はされないが、ＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのサポートを含む、ウェブ・サービスのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの規格を開発および維持するのに関与している、ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手可能であり、さらに、ＨＴＴＰおよびＸＭＬに関する情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）から入手可能である。これらの規格との親和性が仮定される。
【００４０】
さらに背景として、セキュア・ソケット・レイヤ／トランスポート・レイヤ・セキュリティ（ＳＳＬ／ＴＬＳ）が、インターネットなどのネットワークを介して通信をセキュアにするのに使用される、よく知られている暗号プロトコルである。ＳＳＬ／ＴＬＳなどの暗号プロトコルは、ＲＳＡ（Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ、およびＡｄｅｌｍａｎ）暗号化アルゴリズムなどの公開キー暗号システムにしばしば基づく。従来のＲＳＡベースのＳＳＬセッションでは、接続の両側が、セッションの残りのためにパラメータを生成するのに使用される、「プリ・マスター・シークレット」（ＰＭＳ）について合意する。通常、両側は、平文の実際の値を交換することなくプリ・マスター・シークレットを構築するためのＲＳＡ非対称暗号化を使用する。動作中、ＳＳＬクライアントは、プリ・マスター・シークレットを生成し、ＳＳＬサーバの公開されているＲＳＡキーによって、プリ・マスター・シークレットを暗号化する。ＳＳＬクライアントは、暗号化されたプリ・マスター・シークレット（ｅＰＭＳ）を生成し、次いで、ｅＰＭＳは、ＳＳＬサーバに提供される。ＳＳＬサーバは、プライベート復号化キーを有し、プライベート復号化キーは、次いで、暗号化されたプリ・マスター・シークレットを暗号化解除するために使用される。この時点において、クライアントとサーバのどちらも、元のプリ・マスター・シークレットを有し、実際の暗号化およびセキュアなデータ交換に使用される対称キーを生成するために元のプリ・マスター・シークレットを使用することができる。
【００４１】
ウェブ上の暗号化されたトラフィックは、信頼の連鎖によって起こる。各ウェブ・サーバは、ウェブ・サーバが、それらが名乗るものであることを示すために、各クライアント（通常、ウェブ・ブラウザ）に与えられる証明書を有する。ウェブ・サーバは、しばしば、ウェブ・サーバの正当性を保証することができる局（認証局、すなわちＣＡ）から、これらの証明書を得る。サーバの証明書は、証明書が取得された局（「発行者」）を示す。ウェブ・ブラウザは、通常、それらが信頼する発行者のリストを有する。ウェブ・ブラウザがウェブ・サーバから証明書を与えられたとき、ブラウザは、発行者をチェックし、発行者をその信頼されるリストとマッチングする。マッチすることがわかれば、接続が続き、マッチすることがわからなければ、ブラウザは、通常、警告を与え、接続を拒絶する場合がある。ＣＡは、それが信頼されていること以外の特別なエンティティである必要はない。どんなエンティティも、証明書を信頼させ、または証明書に署名するためにそれ自体を設定することができる。証明書は、それ自体を証明することができ、これは、自己署名証明書と呼ばれる。ＳＳＬ／ＴＬＳを使用してクライアントと相互運用するために、クライアントが暗黙的に信頼する証明書を作成することが必要である。ネットワーク・アプライアンス（以下に説明する）に関して、アドミニストレータが、証明書に署名するためにアプライアンスを信頼するように企業クライアントを構成することができることが仮定される。その際、実質的に、アプライアンスの発行者は、信頼される発行者のブラウザのリスト上にある。
【００４２】
ネットワークに接続されたセキュアなアプライアンス
ネットワーク・アプライアンスは、通常、ラック・マウント式のデバイスである。このデバイスは、アプライアンスが機密情報のセキュアなボールトとして機能することを可能にする物理的なセキュリティを含む。通常、本アプライアンスは、製造され、ソフトウェアを予めロードされ、次いで、企業もしくは他のネットワーク動作環境内で、またはそれらに関連して展開され、代替として、ボックスは、局所的に配置され、次いで、たとえば、プライベートまたは業務用のクラウド・コンピューティング環境内でセキュアに展開および管理することができる、標準のまたはカスタマイズされたミドルウェア仮想画像をプロビジョニングされる場合がある。本アプライアンスは、場合によりハード・ディスク上でデータを暗号化するためのハードウェアおよびファームウェアの暗号サポートを含む場合がある。管理するユーザを含むユーザは、物理的ディスク上のどんなデータにもアクセスすることができない。特に、オペレーティング・システム（たとえば、Ｌｉｎｕｘ（Ｒ））は、ルート・アカウントをロックダウンし、コマンド・シェルを提供せず、ユーザは、ファイル・システムへのアクセスができないことが好ましい。通常、アプライアンスは、表示デバイス、ＣＤもしくは他の光デバイス、または任意のＵＳＢ、ファイヤワイヤもしくはデバイスを接続することができる他のポートを含まない。アプライアンスは、限られたアクセス性の密閉されたセキュアな環境になり、その際、認証および認可された個体だけになるように設計される。Ｌｉｎｕｘ（Ｒ）は、米国、他の国、またはその両方においてＬｉｎｕｓ  Ｔｏｒｖａｌｄｓの登録商標である。
【００４３】
図３を参照すると、代表的な動作環境は、ネットワーク３０２に接続する物理的アプライアンス３００を含む。本アプライアンスは、図２に関して上述したデータ処理システムを使用して実装される場合があり、図１に示したサーバ（またはクライアント）の１つを表す場合がある。通常、アプライアンス３００は、Ｗｅｂ２．０ベースのユーザ・インターフェース（ＵＩ）、コマンド・ライン・インターフェース（ＣＬＩ）、およびＲＥＳＴベースのアプリケーション・プログラミング・インターフェース（ＡＰＩ）を含む。この例では、アプライアンスは、オペレーティング・システム３０４、アプリケーション・サーバ３０６、ＨＴＴＰサーバ３０８、および他のアプリケーション・プログラム３１０を含む画像をプロビジョニングされた。追加のソフトウェア・ソリューション（図示せず）が、画像内に含まれる場合がある。これらのソフトウェア要素は、他のデータ（たとえば、テンプレート、スクリプト、ファイルなど）を含む場合があるアプライアンス上に予めロードされる場合がある。具体的なソフトウェア構成は、当然、アプライアンスから作成される使用法に依存する。本アプライアンスは、複数の記憶デバイスの１つ（たとえば、ディスク３１５）を含む。記憶デバイスのタイプおよび数は、様々であってよい。
【００４４】
セキュアなネットワーク通信のインターセプション、暗号化解除、および検査
さらなる背景として、図４は、既知の技法による、セキュアなネットワーク通信をインターセプトし、暗号化解除し、検査するための既知のマン・イン・ザ・ミドル（ＭＩＴＭ）デバイス４００の基本動作を示す。このデバイスは、上述し図３に示したセキュアなネットワーク・アプライアンス内に実装される。より一般的には、このデバイスは、図１に示したコンピューティング・システムである。
【００４５】
図示したように、デバイス４００は、クライアント４０２とサーバ４０４との間に接続される。クライアントおよびサーバは、ＳＳＬまたはＴＬＳを使用して通信をセキュアにするようにプロビジョニングされる。ＳＳＬ／ＴＬＳとの親和性が仮定される。この実施形態では、デバイス４００は、２つの独立したＳＳＬ／ＴＬＳセッション、すなわち、一方はターゲット・サーバ４０４までのクライアント・プロセスＸＳＳ４０６、他方は開始したクライアント４０２までのサーバ・プロセスＸＣＳ４０８を作成および管理することによって、クライアント４０２とサーバ４０４との間の透過的な（またはマン・イン・ザ・ミドルの）プロキシを提供する。ＸＳＳおよびＸＣＳの構成要素は、本明細書ではＳＳＬインスタンスと呼ばれることがあり、ＳＳＬインスタンスは、通常、ＳＳＬセッションを作り出すコードの一部分である。ＳＳＬセッション（またはセッション・コンテキスト）は、２つのエンドポイント間で起こる通信自体である。したがって、中間プロキシ４００は、サーバ４０４にはクライアントに見え、クライアント４０２には目的のサーバに見える。クライアント４０２から開始された通信、およびサーバ４０４から受け取った任意の応答は、次いで、検査（または書換えなどの他の処理）および後続の動作に利用可能である。この目的で、デバイス４００は、ネットワークの脅威を識別し場合によりそれを軽減するためのパケット検査機能を提供する、プロトコル分析モジュール（たとえば、ＩＢＭ（Ｒ）  Ｓｅｃｕｒｉｔｙ  Ｎｅｔｗｏｒｋ  Ｐｒｏｔｅｃｔｉｏｎ  ＰＡＭ）を含む場合がある。このモジュール（または、サポートされる場合がある他のパケット検査アプライアンス）の具体的な詳細は、本開示の態様ではない。
【００４６】
動作中、図４でわかるように、最初のＴＣＰハンドシェーク（図示せず）に続いて、クライアント４０２は、サーバに対するＳＳＬ／ＴＬＳハンドシェークを開始するために、ＳＳＬ／ＴＬＳセッション初期要求メッセージ（以下、「クライアント・ハロー」と呼ばれる）を生成する。これがステップ１である。プロキシは、この接続をインターセプトして、この接続をクライアントに面したサーバ構成要素ＸＣＳ４０８に導く。ステップ２において、ＸＣＳ構成要素は、クライアント・ハローを読み、データを解釈し、通常、サーバ・ハロー・メッセージ、証明書、およびサーバ完了メッセージと共にクライアント４０２に応答する。ステップ３では、最新のＳＳＬ接続が構成され、アプライアンス内に設定される。これは、ＸＳＳによって開始されたサーバに面した接続である。ＸＳＳは、次いで、新規のクライアント・ハロー（ステップ１のクライアント・ハローと区別するためにクライアント・ハロー２と呼ばれる）を生成し、（新規の）クライアント・ハローをサーバに送る。ステップ４では、サーバ４０４は、新規のクライアント・ハローを読み、サーバ・ハロー２、証明書２、およびサーバ完了２と共に応答する。これらのメッセージは、さらにまた、ステップ２におけるクライアントまでのＸＣＳによって発行されたメッセージとは異なる。その結果、一方はクライアント４０２とＸＣＳ４０８との間、他方はＸＳＳ４０６とサーバ４０４との間の２つの異なる接続が存在する。この時点において、接続が検査されることが望まれる（クライアント−サーバ）接続でないと（たとえば、ＰＡＭまたは他のアプリケーションにおける）ＭＩＴＭ処理が判定した場合、このシステムは、（おそらく結果を無視して）この接続を検査し続けるか、またはその接続を完全に停止しなければならない。この判定は、サーバから受け取った証明書（上記の証明書２）内の情報に対するポリシー・ベースのルール・マッチングを実行することなどの、任意の便利な方式に基づく場合がある。
【００４７】
ＴＬＳ検査におけるキャッシュのないセッション・チケット・サポート
上記の背景として、次に、本開示のＴＬＳ検査におけるキャッシュのないセッション・チケット・サポートについて説明する。インターネットＲＦＣ５０７７によるＴＬＳセッション・チケットとの親和性が仮定される。技法が実装される場合がある代表的な市販の製品は、ＩＢＭ（Ｒ）  ＱＲａｄａｒ（Ｒ）  Ｎｅｔｗｏｒｋ  Ｓｅｃｕｒｉｔｙ（ＸＧＳ）（以前は、ＩＢＭ（Ｒ）  Ｓｅｃｕｒｉｔｙ  Ｎｅｔｗｏｒｋ  Ｐｒｏｔｅｃｔｉｏｎ（ＸＧＳ）として知られていた）、次世代侵入防止システム（ＩＰＳ）である。当然、この市販の製品の識別情報は、この手法がいずれの中間のデバイス、アプライアンス、製品、またはシステムにおいて実行される場合があるので、限定を目的としていない。ＩＢＭ（Ｒ）およびＱＲａｄａｒ（Ｒ）は、世界中の多くの管轄区域で登録されたＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅ  Ｃｏｒｐｏｒａｔｉｏｎの商標である。
【００４８】
上述したように、本開示によれば、説明したネットワーク・ベースのアプライアンスは、セッション・キャッシュがインスペクタ内に維持されることを必要とすることなく、本アプライアンスがセッション再開と共にＴＬＳ検査をもたらすことを可能にするメカニズムを含む。この目的で、インスペクタは、セッション・キャッシュなしに（または、代替として、使用されないキャッシュと共に）構成され、したがって、セッション・チケット（ＴＬＳサーバから受け取った）とセッション・コンテキストとの間のマッピングを維持しなくなる。代わりに、インスペクタは、実質的にＴＬＳインスペクタの代わりに、セッション・コンテキストを維持することにＴＬＳクライアントを参加させるように構成される。動作中に、インスペクタが、セッション・チケットをキャッシングする代わりに、ＴＬＳサーバからセッション・チケットを最初に受け取るとき、インスペクタは、元のチケットと、セッション・キーを含むセッション・コンテキスト情報とを含む複合チケットを生成し、その複合チケットをクライアントに発行する。複合チケット（または複合セッション・チケット）は、セッション情報をセキュアにするためにインスペクタによって暗号化されるのが好ましい。ＴＬＳクライアントが、ＴＬＳ接続を再開するために、複合セッション・チケットを（インスペクタに再び）与えるとき、インスペクタは、チケットを暗号化解除し、チケットからセッション・コンテキストを直接取り出す。次いで、インスペクタは、ＴＬＳセッションを再開するために元のセッション・チケットを使用する。この手法は、ＴＬＳインスペクタにおける、任意のキャッシュ検索、またはローカル・セッション・キャッシュを維持する必要性さえも除去する。むしろ、実質的に、複合チケットは、セッション・チケット自体のためのキャッシュになる。
【００４９】
よく知られているように、本アプライアンスは、たとえば、サーバ証明書またはその他に対するルール・マッチングを行うと、ＭＩＴＭプロセス（プロキシ・ベースまたはその他）が、（検査なしに）元の接続を再開し、元のエンドポイントに再接続するのを可能にするためのメカニズムを含むことが仮定される。ＴＬＳサポートにおけるセッション・チケットは、この目的のために使用される。
【００５０】
図５は、ＴＬＳにおける従来のセッション・チケットを示すフロー図、すなわち、セッション・キャッシュを含むインスペクタ５００を有するフロー図を示す。標準的なＴＬＳハンドシェークのセマンティクスとの親和性が仮定される。図示したように、図５のフロー図は、ＴＬＳクライアント５０２とＴＬＳサーバ５０４との間の中間に配置されたインスペクタを示す。従来のＴＬＳハンドシェークのフローでは、クライアント５０２は、サーバ５０４にクライアント・ハローを発行する。これがステップ５０６である。ステップ５０８では、サーバ５０４は、様々なメッセージ、すなわち、サーバ・ハロー、証明書、サーバ・キー交換、およびサーバ・ハロー完了と共に応答する。セッション・コンテキスト情報（暗号スイート、マスター・キーなど）が、ステップ５１０においてインスペクタ５００によって記憶される。ステップ５１２では、クライアント５０２は、サーバに、様々なメッセージ、すなわち、クライアント・キー交換、随意的な暗号仕様変更、および終了を返す。サーバ５０４は、次いで、メッセージの別の組、すなわち、新規セッション・チケット、暗号仕様変更メッセージ（クライアントによって送られていた場合）に対する任意の応答、および終了と共に応答する。これは、最初のＴＬＳハンドシェークを完了させる。ステップ５１６では、インスペクタ５００は、そのローカル・キャッシュ内に新規チケットを記憶する。ステップ５１８に示したように、アプリケーション・データが、使用の際に、クライアント５０２とサーバ５０４との間を流れる。インスペクタ５００は、１つまたは複数のインスペクタ機能を実行するために、ステップ５２０に示したように、ペイロードを暗号化解除するのにチケット内のセッション情報を使用する。インスペクタはまた、クライアントに再びセッション・チケットを渡す。
【００５１】
インスペクタによる１つまたは複数の動作がセッションに割り込み、したがって、セッション再開を実行するためのインスペクタの機能を要求する。この目的で、ステップ５２２に示したように、クライアントが別のクライアント・ハローを発行し、この時にセッション・チケットを渡す。ステップ５２４では、インスペクタは、そのローカル・キャッシュ内のセッション・チケットの検索を実行する。チケットがマッチした場合、インスペクタ５００は、サーバに新規のクライアント・ハローを発行し、セッション・チケットを渡すことが仮定される。これがステップ５２６である。ステップ５２８では、サーバ５０４は、様々なメッセージ、すなわち、サーバ・ハロー、証明書、随意的な暗号仕様変更、および終了と共に応答する。ステップ５３０では、クライアント５０２は、次いで、メッセージの組、すなわち、暗号仕様変更メッセージ（サーバによって送られていた場合）に対する任意の応答、および終了と共に応答する。これは、セッション再開に必要な後続のＴＬＳハンドシェークを完了させる。ステップ５３２では、インスペクタ５００は、そのキャッシュから（ステップ５１０において記憶された）１つまたは複数のセッション・キーを取得する。通常、セッション（クライアント／インスペクタ間、およびインスペクタ／サーバ間）ごとに１つの、合計２つのセッション・キーが存在する。次いで、クライアントとサーバとの間で、アプリケーション・データが渡される（ステップ５３２）ので、インスペクタは、必要に応じて、ペイロードを暗号化解除するためにセッション・キーを使用する。これがステップ５３４である。
【００５２】
図６は、図５と同様であるが、この図面は、本開示の技法による、従来のセッション・キャッシング手法に対する変更を示す。説明してきたように、修正された技法は、ＴＬＳ検査において「キャッシュのない」セッション・チケット・サポートを提供する。この目的で、インスペクタは、セッション・チケット（ＴＬＳサーバから受け取った）とセッション・コンテキストとの間のマッピングを維持しなくなるように構成される。代わりに、インスペクタは、実質的にＴＬＳインスペクタの代わりに、セッション・コンテキストを維持することにＴＬＳクライアントを参加させるように構成される。この手法は、ＴＬＳインスペクタにおける、任意のキャッシュ検索、またはローカル・セッション・キャッシュを維持する必要性さえも除去する。むしろ、実質的に、インスペクタとクライアントとの間の情報交換は、インスペクタがそれ自体のセッション・キャッシュから要求側のクライアントにキャッシングをオフロードする方法を提供し、要求側のクライアントが、（変更された形式であっても）結局セッション・チケットを記憶する。実質的に、クライアントは、セッション・チケット自体のキャッシュになる。
【００５３】
動作中に、インスペクタが、セッション・チケットをキャッシングする代わりに、ＴＬＳサーバからセッション・チケットを最初に受け取るとき、インスペクタは、元のチケットと、セッション・キーを含むセッション・コンテキスト情報とを含む複合チケットを生成し、その複合チケットをクライアントに発行する。複合チケット（または複合セッション・チケット）は、セッション情報をセキュアにするためにインスペクタによって暗号化されるのが好ましい。ＴＬＳクライアントが、ＴＬＳ接続を再開するために、複合セッション・チケットを（インスペクタに再び）与えるとき、インスペクタは、チケットを暗号化解除し、チケットからセッション・コンテキストを直接取り出す。次いで、インスペクタは、ＴＬＳサーバへのＴＬＳセッションを再開するために元のセッション・チケットを使用する。
【００５４】
キャッシュのないセッション・チケット・サポートは、図６に示される。もう一度、インスペクタ６００は、ＴＬＳクライアント６０２とＴＬＳサーバ６０４との間の中間に配置されるように示される。図５とは異なり、インスペクタ６００は、セッション・キャッシュを含む必要がない。従来のＴＬＳハンドシェークのフローと同様に、クライアント６０２は、サーバ６０４にクライアント・ハローを発行する。これがステップ６０６である。ステップ６０８では、サーバ４０４は、様々なメッセージ、すなわち、サーバ・ハロー、証明書、サーバ・キー交換、およびサーバ・ハロー完了と共に応答する。もう一度、セッション・コンテキスト情報（暗号スイート、マスター・キーなど）が、ステップ６１０においてインスペクタ６００によって記憶される。ステップ６１２では、クライアント６０２は、様々なメッセージ、すなわち、クライアント・キー交換、随意的な暗号仕様変更、および終了を返す。しかし、この時、これらのメッセージは、（図５と同様に）サーバに渡される代わりに、インスペクタによってインターセプトされる。ステップ６１４では、サーバ６０４は、新規セッション・チケット・メッセージ、随意的な暗号仕様変更メッセージ、および終了メッセージを提供する。新規セッション・チケットは、元のセッション・チケットを含む。ステップ６１６では、（図５のステップ５１６と同様に）サーバ６０４によって提供された元のセッション・チケットを記憶する代わりに、インスペクタ６００は、［Ａ］と呼ばれる新規セッション・チケットを生成する。新規セッション・チケットを生成するための好ましい技法のさらなる詳細は、以下に説明する。次いで、インスペクタ６００は、クライアント６０２に、メッセージの組、すなわち、新規セッション・チケット［Ａ］、随意的な暗号仕様変更、および終了を出力する。これがステップ６１８である。新規セッション・チケット［Ａ］メッセージは、新規セッション・チケット［Ａ］を含む。ステップ６２０では、アプリケーション・データが、クライアント６０２とサーバ６０４との間を流れる。インスペクタ６００は、１つまたは複数のインスペクタ機能を実行するために、ステップ６２２に示したように、ペイロードを暗号化解除するのにチケット内のセッション情報を使用する。
【００５５】
上述のように、インスペクタによる１つまたは複数の動作がセッションに割り込み、したがって、セッション再開を実行するためのインスペクタ６００の機能を要求する。この目的で、ステップ６２４に示したように、クライアントが別のクライアント・ハローを発行し、この時にインスペクタに再び新規セッション・チケット［Ａ］を渡すことが仮定される。ステップ６２６では、インスペクタ６００は、元のセッション・チケット（［Ｂ］と呼ばれる）を復元しセッション情報を復元するために新規セッション・チケット［Ａ］を暗号化解除する。ステップ６２８では、インスペクタ６００は、クライアント・ハローにおいてチケット［Ａ］をチケット［Ｂ］と交換し、ステップ６３０では、インスペクタ６００は、サーバ６０４にクライアント・ハロー（セッション・チケット［Ｂ］を有する）を送る。ステップ６３２では、サーバ６０４は、様々なメッセージ、すなわち、サーバ・ハロー、証明書、暗号仕様変更、および終了と共に応答する。ステップ６３４では、クライアント６０２は、次いで、メッセージの組、すなわち、暗号仕様変更および終了と共に応答する。これは、セッション再開に必要な後続のＴＬＳハンドシェークを完了させる。ステップ６３６では、インスペクタ６００は、ステップ６２６においてチケット［Ａ］から抽出されたセッション情報から、セッション・キーを取得する。次いで、クライアントとサーバとの間で、アプリケーション・データが渡される（ステップ６３８）ので、インスペクタ６００は、必要に応じて、ペイロードを暗号化解除するためにセッション・キーを使用する。これがステップ６４０である。
【００５６】
要約すると、図５のステップ５１４、５１６、および５２４を図６のステップ６１６、６１８、および６２６と比較することによってわかるように、本明細書の手法は、インスペクタ自体においてセッション・チケットをキャッシングすることを除去する。むしろ、インスペクタが、セッション・チケットをキャッシングする代わりに、ＴＬＳサーバからセッション・チケットを最初に受け取るとき、インスペクタは、元のチケットと、セッション・キーを含むセッション・コンテキスト情報とを含む複合チケットを生成し、その複合チケットをクライアントに発行する。複合チケット（または複合セッション・チケット）は、セッション情報をセキュアにするためにインスペクタによって暗号化されるのが好ましい。ＴＬＳクライアントが、ＴＬＳ接続を再開するために、複合セッション・チケットを（インスペクタに再び）与えるとき、インスペクタは、チケットを暗号化解除し、チケットからセッション・コンテキストを直接取り出す。次いで、インスペクタは、ＴＬＳサーバへのＴＬＳセッションを再開するために元のセッション・チケットを使用する。
【００５７】
以下は、新規セッション・チケットを生成するための好ましい技法について説明する。これが図６のステップ６１６である。新規セッション・チケットが次のように生成されるのが好ましい。暗号化（変換（元のセッション・チケット、セッション情報）、暗号化キー）。ここで、セッション情報は暗号スイート、マスター・キーなどの暗号情報を含む。この変換は、識別されたデータ、すなわち、元のセッション・チケット、セッション情報を互いに組み合わせる任意の方法または計算であり、暗号化は、新規セッション・チケットを保護することができる任意の暗号化アルゴリズムを表す。通常の変換は、連結演算である場合があるが、より複雑な計算方法が変換に適用される場合があるので、これは、限定ではない。当然、変換は、元のデータを復元することができるように、関連の逆変換を有しなければならない。暗号化ラッパーでは、通常のソリューションは、新規セッション・チケットを後にクライアントから受け取ったとき、暗号化キーが、暗号化解除に使用される関連のプライベート・キーまたはシークレット・キーを有する公開キーとなるように、公開キー暗号化を利用する場合がある。したがって、上述したように、新規セッション・チケットは、ＴＬＳセッションに関連する、元のセッション・チケットおよびセッション・コンテキスト情報に、変換関数を最初に適用することによって生成され、次に、暗号化関数が変換の結果に適用される。変換を適用した結果は、本明細書では、「複合」セッション・チケットまたは新規セッション・チケットと呼ばれることがある。インスペクタは、クライアントに、暗号化された新規セッション・チケットを出力する。
【００５８】
インスペクタが後続のクライアント・ハローにおいてクライアントから暗号化された新規セッション・チケットを受け取ったとき、元のセッション・チケット、セッション情報を取得（復元）するために、インスペクタがチケットを暗号化解除し、次いで、クライアント・ハローを元のセッション・チケットと交換することによって、セッションが再開される。上述のように、インスペクタにおいて維持される公開キーの対のプライベート・キーを使用することによって、暗号化解除が実行されることが好ましい。２つの暗号化解除動作、すなわち、Ｇｅｔ＿Ｔｉｃｋｅｔ（暗号化解除（新規セッション・チケット））およびＧｅｔ＿ＳｅｓｓｉｏｎＩｎｆｏ（暗号化解除（新規セッション・チケット））が存在するのが好ましい。暗号化解除が成功すれば、暗号化解除されたペイロードは、元のセッション・チケットおよびセッション情報を含むはずである。Ｇｅｔ＿Ｔｉｃｋｅｔ機能は、元のセッション・チケットを取得／復元し、Ｇｅｔ＿ＳｅｓｓｉｏｎＩｎｆｏは、ペイロードを暗号化解除するのに必要なマスターＴＬＳキーなどのセッション情報を取得する。
【００５９】
上述の手法は、多くの利点を提供する。ＴＬＳセッション・チケット・サポートを提供する現行のＴＬＳインスペクタ・マシンは、説明した手法によって克服される、いくつかの欠点を有する。最初に、インスペクタ内にセッション・キャッシュを維持する必要性がない。その結果、この手法の既知の欠点（不十分な拡張性、処理およびメモリの非効率性、サービス拒否（ＤｏＳ）悪用の可能性）が克服される。この手法は、計算効率の良い方式で追加の機能を容易に実施することができるので、実施するのが簡単である。この手法は、極めて信頼性が高く、セキュアである。セッション・チケット自体のキャッシングをオフロードすることによって、この手法は、インスペクタ・メカニズムのより十分な性能を提供し、それによって、中間ノードの動作全体を向上させる。
【００６０】
本明細書の技法は、ＴＬＳサポート・インフラストラクチャの拡張も容易にする。したがって、たとえば、複数のインスペクタが実装されるとき、変換関数が、好ましくは前もって、インスペクタ全体にわたって（たとえば、複合チケットを暗号化解除するのに必要なキーを共有することによって）同期される限り、すべてのインスペクタは、複合セッション・チケットを理解し、次いで、検査を再開することができる。
【００６１】
これらの技法は、プロキシのコンテキストで説明してきたが、このことは、限定ではない。要約すれば、本明細書に説明した処理は、クライアントとサーバとの間に配置された任意の中間ノードにおいて実行されてよい。そのような一実施形態では、中間ノードは、透過的なインライン・コンテンツの検査および修正を提供する。クライアントおよびサーバは、コンピューティング・エンティティ（エンドポイント）である。中間ノードは、物理的デバイス、仮想デバイス、またはそのいくつかの組合せとして構成されてよい。中間ノードは、上述した方式でセキュリティ検査を実行することができるように、限定はされないが、暗号化された（ＳＳＬ／ＴＬＳ）セッションの暗号化解除を含む、いくつかの異なる用途に使用することができる。
【００６２】
好ましい動作環境および使用の事例（セキュアなアプライアンス）について説明してきたが、本明細書の技法は、コンピューティング・システムもしくはデバイスから、またはそれらに、あるいはそれらとの間で、ネットワーク・トラフィックをインターセプト、暗号化解除、検査、または修正する（書き換える）、あるいはその組合せを行うことが望まれる、任意の他の動作環境において使用されてよい。
【００６３】
説明してきたように、上述した機能は、プロセッサによって実行されるソフトウェア・ベースの機能などの独立型の手法として実装されるか、または、あるサービス（ＳＯＡＰ／ＸＭＬインターフェースを介したウェブ・サービスを含む）として入手可能である場合がある。本明細書に説明した具体的なハードウェアおよびソフトウェアの実装形態の詳細は、例示のためだけにあり、説明した主題の範囲を限定するものではない。
【００６４】
より一般的には、開示された主題のコンテキスト内のコンピューティング・デバイスは各々、ハードウェアおよびソフトウェアを含むデータ処理システム（図２に示した）であり、これらのエンティティは、インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、または任意の他の通信媒体もしくはリンクなどのネットワークを介して互いに通信する。データ処理システム上のアプリケーションは、限定はされないが、特に、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのサポートを含む、ウェブおよび他の既知のサービスおよびプロトコルのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの規格を開発および維持するのに関与している、ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手可能であり、さらに、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＸＭＬに関する情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）から入手可能である。これらの既知の規格およびプロトコルとの親和性が仮定される。
【００６５】
本明細書に説明した技法は、様々なクライアント側のアーキテクチャ（たとえば、ファイアウォール、ＮＡＴデバイス）において、またはそれに関連して、および、簡単なｎ層アーキテクチャ、ウェブ・ポータル、連合システムなどを含む、様々なサーバ側のアーキテクチャにおいて、またはそれに関連して、実装される場合がある。本明細書の技法は、緩く結合されたサーバ（「クラウド」ベースを含む）環境において実践されてよい。
【００６６】
さらにより一般的には、本明細書に説明した主題は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェア要素とソフトウェア要素の両方を含む実施形態の形態をとることができる。好ましい実施形態では、信頼されるプラットフォーム・モジュール機能は、限定はされないが、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むソフトウェア内に実装される。さらに、ダウンロードおよび削除のインターフェースおよび機能は、コンピュータまたは任意の命令実行システムによって、またはそれらに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態をとることができる。この説明のために、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、またはそれらに関連して、使用するためのプログラムを含むか、または記憶することができる任意の装置とすることができる。この媒体は、電子的、磁気的、光学的、電磁的、赤外線の、または半導体のシステム（または装置、またはデバイス）とすることができる。コンピュータ可読媒体の例は、半導体メモリまたは固体メモリ、磁気テープ、取外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、剛性のある磁気ディスク、および光ディスクを含む。光ディスクの現行の例は、コンパクト・ディスク−リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−読取り／書込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。コンピュータ可読媒体は、有形の非一過性の製品である。
【００６７】
コンピュータ・プログラム製品は、説明した機能の１つまたは複数を実施するためのプログラム命令（またはプログラム・コード）を有する製品であってよい。これらの命令またはコードは、ネットワークを介して遠隔のデータ処理システムからダウンロードされた後、データ処理システム内の非一過性のコンピュータ可読記憶媒体内に記憶されてよい。あるいは、これらの命令またはコードは、サーバ・データ処理システム内のコンピュータ可読記憶媒体内に記憶され、遠隔のシステム内のコンピュータ可読記憶媒体内で使用するための遠隔のデータ処理システムにネットワークを介してダウンロードされるように構成されてよい。
【００６８】
代表的な実施形態では、インターフェースおよびユーティリティは、専用コンピューティング・プラットフォーム内に、好ましくは、１つまたは複数のプロセッサによって実行されるソフトウェア内に実装される。ソフトウェアは、１つまたは複数のプロセッサに関連する、１つもしくは複数のデータ・ストアまたはメモリ内に維持され、ソフトウェアは、１つまたは複数のコンピュータ・プログラムとして実装される場合がある。集合的に、この専用ハードウェアおよびソフトウェアは、上述した機能を含む。
【００６９】
上記は、本発明のいくつかの実施形態によって実行される動作の具体的な順序について説明してきたが、そのような順序は、代替の実施形態が、異なる順序で動作を実行し、いくつかの動作を組み合わせ、いくつかの動作を重ね合わせることなどを行う場合があるので、例示であることを理解されたい。明細書における所与の実施形態への参照は、説明した実施形態が、特定の特徴、構造、または特性を含む場合があるが、すべての実施形態が、特定の特徴、構造、または特性を含む必要がない場合があることを示す。
【００７０】
最後に、本システムの所与の構成要素について別個に説明してきたが、当業者は、機能のいくつかが、所与の命令、プログラム・シーケンス、コード部分などにおいて組み合わされるか、または共有される場合があることを諒解されよう。
【００７１】
本アプライアンスは、どんな特定のタイプにも限定されない。上述の動作は、同様に、マシンの物理的構成に関わらず、それ自体が任意のマシンからのデータをインターセプト、暗号化解除、検査、修正、書換え、および再暗号化を行うために使用される任意の既知の技法またはメカニズムに関連して使用される場合がある。
【００７２】
本明細書の技法は、概略的には、技術または技術分野に対する上述の改良、および上述した、ネットワークに接続されるセキュアなアプライアンスに対する特定の技術的な改良をもたらす。
【００７３】
セッション・キャッシュのないＴＬＳインスペクタを提供する概念（本技法の「キャッシュのない」性質）は、ＴＬＳインスペクタが、通常の構成であるが、そのようなキャッシュなしに物理的に構成されることを必ずしも必要としない。利用されないか、またはそれ以外にバイパスされたセッション・キャッシュを有するＴＬＳインスペクタは、以下に特許請求される、開示された主題の範囲内にある。したがって、本明細書に使用される「キャッシュのない」は、セッション・キャッシュが削除されるか、または存在しても利用されないことを意味する。
【図１】
2020522164.tif 000003
【図２】
2020522164.tif 000004
【図３】
2020522164.tif 000005
【図４】
2020522164.tif 000006
【図５】
2020522164.tif 000007
【図６】
2020522164.tif 000008
【国際調査報告】
2020522164.tif 000009
2020522164.tif 000010