(57)【要約】  （例えばサービス・プロバイダにより運営される）インターネット・インフラストラクチャを成す配信プラットフォームが、ＳＳＬプロトコルの機能強化として、暗号化されたプリ・マスタ・シークレット（ｅＰＭＳ）の復号化を外部サーバに肩代わりさせる、ＲＳＡプロキシ「サービス」を提供する。このサービスを利用することにより、ｅＰＭＳを「ローカルに」復号化する代わりに、ＳＳＬサーバは、ｅＰＭＳをＲＳＡプロキシ・サーバ・コンポーネントにプロキシし（転送し）、復号化されたプリ・マスタ・シークレットを応答として受信する。このようにすれば、復号鍵をＳＳＬサーバと関連付けて記憶する必要がない。【選択図】  図４
2015505994.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと、
前記プロセッサにより実行されるように適合しているプログラム・コードを保持するコンピュータ・メモリと、
を備えた装置であって、
前記プログラム・コードは、プロキシ・サーバのクライアント・コンポーネントとして構成され、
前記プロキシ・サーバの遠隔のサーバ・コンポーネントとのセキュアな接続を確立するためのコードと、
クライアントから受信した、新たなＳＳＬハンドシェイク・リクエストと関連付けて暗号化されたプリ・マスタ・シークレットを、前記セキュアな接続を介して前記プロキシ・サーバの前記遠隔のサーバ・コンポーネントへ転送するためのコードとを含み、前記暗号化されたプリ・マスタ・シークレットは前記プロキシ・サーバの前記遠隔のサーバ・コンポーネントで保持され、他の態様では前記クライアント・コンポーネントにはアクセス不可能である復号鍵を用いて復号化されるように適合されており、
さらに、前記プロキシ・サーバの前記遠隔のサーバ・コンポーネントから、前記セキュアな接続を介して、前記プロキシ・サーバの前記遠隔のサーバ・コンポーネントで保持されている前記復号鍵により復号化されたプリ・マスタ・シークレットを受信するためのコードを備える
ことを特徴とする装置。
【請求項２】
前記復号化されたプリ・マスタ・シークレットを使用してマスタ・シークレットを生成するためのコードをさらに含むことを特徴とする、請求項１に記載の装置。
【請求項３】
前記クライアントと前記装置との間の通信を確保するべく使用されるように、前記マスタ・シークレットを前記クライアントへ返すためのコードをさらに含むことを特徴とする、請求項２に記載の装置。
【請求項４】
前記プリ・マスタ・シークレットは非対称ＲＳＡ暗号化を使用して確立されることを特徴とする、請求項１に記載の装置。
【請求項５】
クライアントで生成された暗号化されたシークレット・データ値を含むハンドシェイク・リクエストを受信するステップと、
前記暗号化されたシークレット・データ値を、セキュアな接続を介して、復号鍵を前記暗号化されたシークレット・データ値に適用して前記シークレット・データ値を回復し得るコンピューティング・エンティティへとプロキシするステップと、
前記コンピュータティング・エンティティから、前記セキュアな接続を介して、前記シークレット・データ値を受信するステップと、
前記シークレット・データ値を使用して、前記クライアントに戻る接続を暗号化するために使用される鍵を生成するステップと、
を備えることを特徴とする、通信を確保するための方法。
【請求項６】
ハードウェア上で実行されるＲＳＡプロキシ・サーバ・ソフトウェア・プログラムを含む、第１のネットワーク・アクセス可能な場所にある少なくとも１つのマシーンと、
ハードウェア上で実行されるＲＳＡプロキシ・クライアント・ソフトウェア・プログラムを含む、第２のネットワーク・アクセス可能な場所にある少なくとも１つのマシーンと、
を備えたシステムであって、
前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラム及び前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムはそれぞれ、両者間のセキュアな接続を確立し維持するためのコードを含み、
前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムは、クライアントから受信した、新たなＳＳＬハンドシェイク・リクエストと関連付けて暗号化されたプリ・マスタ・シークレットを、前記セキュアな接続を介して前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムへ転送するように適合されており、
前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムは、前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムから転送された前記暗号化されたプリ・マスタ・シークレットを受信し、前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムで保持され、他の態様では前記クライアント・コンポーネントにはアクセス不可能である復号鍵を用いて前記暗号化されたプリ・マスタ・シークレットを復号化するように適合されており、
前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムはさらに、復号化されたプリ・マスタ・シークレットを、前記セキュアな接続を介して、前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムに返すように適合されており、
前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムは、前記復号化されたプリ・マスタ・シークレットを受信し、それを使用して対称鍵を生成することにより、前記新たなＳＳＬハンドシェイクを完了することを特徴とするシステム。
【請求項７】
前記第１のネットワーク・アクセス可能な場所はエンティティと関連付けられたデータ・センタであり、前記第２のネットワーク・アクセス可能な場所は前記第１のネットワーク・アクセス可能な場所から離れた物理的な場所であることを特徴とする、請求項６に記載のシステム。
【請求項８】
前記データ・センタと前記物理的な場所の間では、前記データ・センタの方がより高い安全度を有することを特徴とする、請求項７に記載のシステム。
【請求項９】
前記ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムは、少なくとも前記ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムからの暗号化されたプリ・マスタ・シークレットを記憶するデータ・ストアと関連付けられていることを特徴とする、請求項６に記載のシステム。
【請求項１０】
前記データ・ストアは暗号化されたプリ・マスタ・シークレットのキャッシュであることを特徴とする、請求項９に記載のシステム。
【請求項１１】
前記ＲＳＡプロキシ・サーバ・ソフトウェアは、暗号化されたプリ・マスタ・シークレットを受信し、前記受信した暗号化されたプリ・マスタ・シークレットのハッシュを生成し、前記ハッシュを前記キャッシュのインデックスとして使用することにより、前記暗号化されたプリ・マスタ・シークレットが前記キャッシュ中に存在するか否かを判断することを特徴とする、請求項１０に記載のシステム。
【請求項１２】
プロセッサと、
前記プロセッサにより実行されるように適合されているプログラム・コードを保持するコンピュータ・メモリと、
を備えた装置であって、
前記プログラム・コードは、
プロキシ・サーバのクライアント・コンポーネントとのセキュアな接続を確立するためのコードと、
前記プロキシ・サーバの前記クライアント・コンポーネントにてクライアントから受信した、新たなＳＳＬハンドシェイク・リクエストと関連付けて暗号化されたプリ・マスタ・シークレットを、前記セキュアな接続を介して前記プロキシ・サーバの前記クライアント・コンポーネントから受信するためのコードと、
前記暗号化されたプリ・マスタ・シークレットを、他の態様では前記クライアント・コンポーネントにはアクセス不可能である復号鍵を用いて復号化するためのコードと、
復号化されたプリ・マスタ・シークレットを、前記セキュアな接続を介して、前記プロキシ・サーバの前記クライアント・コンポーネントに返すためのコードと、
を備えることを特徴とする装置。
【請求項１３】
少なくとも前記プロキシ・サーバの前記クライアント・コンポーネントからの暗号化されたプリ・マスタ・シークレットを記憶するデータ・ストアをさらに備えることを特徴とする、請求項１２に記載の装置。
【請求項１４】
前記データ・ストアが暗号化されたプリ・マスタ・シークレットのキャッシュであることを特徴とする、請求項１３に記載の装置。
【請求項１５】
前記プログラム・コードは、暗号化されたプリ・マスタ・シークレットを受信し、前記受信した暗号化されたプリ・マスタ・シークレットのハッシュを生成し、前記ハッシュを前記キャッシュのインデックスとして使用することにより、前記暗号化されたプリ・マスタ・シークレットが前記キャッシュ中に存在するか否かを判断することを特徴とする、請求項１４に記載の装置。
【請求項１６】
前記プリ・マスタ・シークレットは非対称ＲＳＡ暗号化を使用して確立されることを特徴とする、請求項１２に記載の装置。
【請求項１７】
前記セキュアな接続が相互認証されたＳＳＬ接続であることを特徴とする、請求項１に記載の装置。
【請求項１８】
前記セキュアな接続が相互認証されたＳＳＬ接続であることを特徴とする、請求項５に記載の方法。
【請求項１９】
前記セキュアな接続が相互認証ＳＳＬされた接続であることを特徴とする、請求項６に記載のシステム。
【請求項２０】
前記セキュアな接続が相互認証ＳＳＬされた接続であることを特徴とする、請求項１２に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は２０１１年１２月１６日付け米国出願第６１／５５４，５７１号に基づき、同出願に関する優先権を主張する。
【０００２】
本願は一般に、ＳＳＬなどの暗号プロトコルを用いたセキュアなネットワーク・ベースの通信に関する。
【背景技術】
【０００３】
分散コンピュータ・システムは周知である。このような分散コンピュータ・システムの一例として、サービス・プロバイダによって運営及び管理される「コンテンツ配信ネットワーク」又は「ＣＤＮ」がある。サービス・プロバイダは一般に、サービス・プロバイダのインフラストラクチャを使用する第三者（カスタマ）に代わってコンテンツ配信サービスを提供する。この種の分散システムは一般に、コンテンツ配信、ウェブ・アプリケーション高速化、又はアウトソースド・オリジン・サイト・インフラストラクチャのサポートのような種々のサービスを容易にするよう設計されたソフトウェア、システム、プロトコル及び技術を含め、単一の又は複数のネットワークによってリンクされた自律的コンピュータの集合を意味する。ＣＤＮサービス・プロバイダは多くの場合、カスタマ・ポータルでプロビジョニングされた後ネットワークに配備される（ウェブ・サイトなどの）ディジタル・プロパティを介して、サービス配信を行う。ディジタル・プロパティは、典型的には１つ以上のエッジ構成に結びつけられており、このエッジ構成によりサービス・プロバイダはトラフィックに対処し、カスタマに請求を行うことができる。
【０００４】
セキュア・ソケット・レイヤ（ＳＳＬ：Secure SocketsLayer）は、インターネットのようなネットワークを介した通信の安全を確保するために用いられる周知の暗号プロトコルである。ＳＳＬのような暗号プロトコルは多くの場合、ＲＳＡ（Rivest, Shamir and Adelman）暗号化アルゴリズムなどの公開鍵暗号システムをベースとしている。従来のＲＳＡベースのＳＳＬセッションの場合、接続の両側が「プリ・マスタ・シークレット」（ＰＭＳ）を取り決め、これを用いてセッションの残りのためのパラメータを生成する。典型的には、この両側は、ＲＳＡ非対称暗号化を使用することにより、実際の数値をプレーンテキストで交換することなくプリ・マスタ・シークレットを確立する。動作時には、ＳＳＬクライアントがプリ・マスタ・シークレットを生成し、ＳＳＬサーバの公開されたＲＳＡ鍵で暗号化する。このようにして暗号化されたプリ・マスタ・シークレット（ｅＰＭＳ）を生成し、次いで、これをＳＳＬサーバに提供する。ＳＳＬサーバは秘密復号鍵を有しており、これを用いて暗号化されたプリ・マスタ・シークレットを復号化する。この時点でクライアント及びサーバはいずれもオリジナルのプリ・マスタ・シークレットを有しており、これを用いることによって、実際の暗号化されたセキュアなデータ交換に用いる対称鍵を生成することができる。
【０００５】
暗号化されたプリ・マスタ・シークレットの復号化は、ＳＳＬ接続において秘密鍵が必要とされる唯一の場面である。この復号化は、いわゆるＳＳＬ終了ポイントで発生する。多くの場合、ＳＳＬ終了ポイントはセキュアでないので、当該鍵を記憶及び使用することは、セキュリティ上の重大なリスクである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第７，１１１，０５７号
【特許文献２】米国特許第７，４７２，１７８号
【特許文献３】米国特許第７，３７６，７１６号
【特許文献４】米国特許出願公開第２００４００９３４１９号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
（例えばサービス・プロバイダにより運営される）インターネット・インフラストラクチャを成す配信プラットフォームが、ＳＳＬプロトコルの機能強化として、暗号化されたプリ・マスタ・シークレット（ｅＰＭＳ）の復号化を外部サーバに肩代わりさせる、ＲＳＡプロキシ「サービス」を提供する。このサービスを利用することにより、ｅＰＭＳを「ローカルに」復号化する代わりに、ＳＳＬサーバは、ｅＰＭＳをＲＳＡプロキシ・サーバ・コンポーネントにプロキシし（転送し）、復号化されたプリ・マスタ・シークレットを応答として受信する。このようにすれば、復号鍵をＳＳＬサーバと関連付けて記憶する必要がない。
【０００８】
一システム実施形態においては、第１のネットワーク・アクセス可能な場所にある少なくとも１つのマシーンがＲＳＡプロキシ・サーバ・ソフトウェア・プログラムを含み、第２のネットワーク・アクセス可能な場所にある少なくとも１つのマシーンがＲＳＡプロキシ・クライアント・ソフトウェア・プログラムを含む。ＲＳＡプロキシ・サーバ・ソフトウェア・プログラム及びＲＳＡプロキシ・クライアント・ソフトウェア・プログラムはそれぞれ、両者の間にセキュアな（例えば相互認証されたＳＳＬ）接続を確立し維持するためのコードを含む。ＲＳＡプロキシ・クライアント・ソフトウェアは、典型的には（ＯｐｅｎＳＳＬなどの）ＳＳＬサーバ・コンポーネントと連携して実行される。しかしながら、本開示によれば、ＳＳＬ復号鍵はＲＳＡプロキシ・クライアント・ソフトウェアにはアクセス不可能である。それどころか、暗号化されたプリ・マスタ・シークレットの復号化は、ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムに肩代わりされる。動作時には、ＲＳＡプロキシ・クライアント・ソフトウェア・プログラムは、エンドユーザ・クライアント・プログラム（例えばＳＳＬ対応のウェブ・ブラウザ、ネイティブ・モバイル・アプリケーション等）からの（ＲＳＡプロキシ・クライアントにて）受信した新たなＳＳＬハンドシェイク・リクエストと関連付けられた、暗号化されたプリ・マスタ・シークレットを受信し、これを相互認証されたＳＳＬ接続を介してＲＳＡプロキシ・サーバ・ソフトウェア・プログラムに転送する。ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムは、ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムで保持され、他の態様では前記クライアント・コンポーネントにはアクセス不可能である復号鍵を用いて、暗号化されたプリ・マスタ・シークレットを復号化する。次いで、ＲＳＡプロキシ・サーバ・ソフトウェア・プログラムは、復号化されたプリ・マスタ・シークレットを、相互認証されたＳＳＬ接続を介してＲＳＡプロキシ・クライアント・ソフトウェア・プログラムに返す。この時点で、エンドユーザ・クライアント・プログラムとＳＳＬサーバ・コンポーネントは、いずれもプリ・マスタ・シークレットを保有している（そして、それを用いて両者間の接続を暗号化するのに用いる対称鍵を生成することができる）。
【０００９】
限定する意図はないが、第１のネットワーク・アクセス可能な場所はエンティティと関連付けられたデータ・センタであり、第２のネットワーク・アクセス可能な場所は当該第１のネットワーク・アクセス可能な場所から離れた物理的な場所である。２つの場所の間では、（ＲＳＡプロキシ・サーバ・コンポーネントが実行される）データ・センタの方がよりセキュアである。
【００１０】
以上、本発明の比較的核心的な特性のいくつかを概説した。これらの特性は単に例示のためのものとして解釈されるべきである。開示した本発明を異なる方法で適用することによって、又は本発明を以下に記載するように変更することによって、他の多くの有益な結果を達成することができる。
【００１１】
本発明及びその利点をさらに完全に理解するため、ここで添付図面と関連付けて以下の記載を参照する。
【図面の簡単な説明】
【００１２】
【図１】コンテンツ配信ネットワーク（ＣＤＮ）として構成された既知の分散コンピュータ・システムを説明するブロック図である。
【図２】代表的なＣＤＮエッジ・マシーンの構成を示す。
【図３】一実施形態において本開示が実行され得る、ファイアウォールの背後のネットワーク構成を図示する図である。
【図４】本開示のＲＳＡプロキシ技術を説明する図である。
【発明を実施するための形態】
【００１３】
図１は既知の分散コンピュータ・システムを図示しており、このシステムを（後述のように）本明細書に記載の技術により拡張することによって、最も普及しているランタイム環境に対して、また、固定回線とモバイル環境の両方の最新の機器に対して、ブロードキャスト・オーディエンスの規模でＨＤ映像をオンライン配信することのできる、単一のＨＴＴＰベース・プラットフォームを提供する。
【００１４】
図１に示すような既知のシステムにおいて、分散コンピュータ・システム１００をＣＤＮとして構成し、インターネットに一連のマシーン１０２ａ〜１０２ｎが分散していると想定する。多くの場合、マシーンの多くはインターネットのエッジの近傍に、すなわちエンドユーザ・アクセス・ネットワークに又はそれに隣接して配置されたサーバである。ネットワーク・オペレーションズ・コマンド・センタ（ＮＯＣＣ）１０４は、システム中の種々のマシーンの動作を管理する。第三者のサイト、例えばウェブ・サイト１０６は、コンテンツ（例えば、ＨＴＭＬ、埋め込まれたページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロード等）の配信を分散コンピュータ・システム１００に、特に「エッジ」サーバに肩代わりさせる。多くの場合、コンテンツ・プロバイダは、所与のコンテンツ・プロバイダ・ドメイン又はサブ・ドメインを（例えばＤＮＳ  ＣＮＡＭＥによって）サービス・プロバイダの権限あるドメイン・ネーム・サービスにより管理されるドメインにエイリアシング処理することによってそのコンテンツ配信を肩代わりさせる。このようなコンテンツを希望するエンドユーザを分散コンピュータ・システムに差し向けることによって、より確実にかつ効率的にコンテンツを得ることができる。詳しくは図示しないが、分散コンピュータ・システムはその他のインフラストラクチャ、例えばエッジ・サーバから使用及び他のデータを収集し、そのデータを１つの領域又は一連の領域を通して集約し、これを他のバックエンド・システム１１０，１１２，１１４，及び１１６に通すことによって、モニタリング、ロギング、警告、請求書作成、管理その他の運用管理機能を容易にすることができる分散データ収集システム１０８も含むことができる。分散ネットワーク・エージェント１１８は、ネットワーク及びサーバ負荷をモニターして、ネットワーク、トラフィック、及び負荷データを、ＣＤＮの管理下にあるコンテンツ・ドメインに対して権限を持つＤＮＳクエリ処理機構１１５に提供する。分散データ伝送機構１２０を利用することによって、制御情報（例えばコンテンツを管理し、負荷平衡を容易にする等を目的とするメタデータ）をエッジ・サーバに配分することができる。
【００１５】
図２に示すように、所与のマシーン２００は、１つ以上のアプリケーション２０６ａ〜２０６ｎをサポートするオペレーティング・システム・カーネル（Linux又は変形等）２０４を動作させるコモディティ・ハードウェア（例えばIntel Pentiumプロセッサ）２０２を含む。コンテンツ配信サービスを容易にするため、例えば所与のマシーンは典型的に、ＨＴＴＰプロキシ２０７（「グローバルホスト」又は「ゴースト」プロセスと称されることもある）、ネームサーバ２０８、ローカル・モニタリング・プロセス２１０、分散データ収集プロセス２１２等の一連のアプリケーションを実行する。ストリーミング・メディアでは、マシーンは通常、サポートされるメディア・フォーマットの要件に応じて、Windows Media Server（ＷＭＳ）又はフラッシュ・サーバ等の１つ以上のメディア・サーバを含む。
【００１６】
ＣＤＮエッジ・サーバは、好ましくは構成システムを利用するエッジ・サーバに配分されている構成ファイルを利用して、好ましくはドメイン特化型、カスタマ特化型の１つ以上の広範なコンテンツ配信特性を提供するように構成されている。所与の構成ファイルは、ＸＭＬをベースとし、１つ以上の高度のコンテンツ処理特性を容易にする一連のコンテンツ処理規則及び命令を含むことが好ましい。構成ファイルは、データ伝送機構を介してＣＤＮエッジ・サーバに配信することができる。米国特許第７，１１１，０５７号は、エッジ・サーバ・コンテンツ制御情報を配信及び管理するための有用なインフラストラクチャを説明しており、これ等のエッジ・サーバ制御情報は、ＣＤＮサービス・プロバイダ自体、又は（エクストラネット等を介して）オリジン・サーバを運用するコンテンツ・プロバイダ・カスタマによってプロビジョニングすることができる。
【００１７】
ＣＤＮは、米国特許第７，４７２，１７８号に記載されたもののような記憶サブシステムを含むことができる。この開示内容は引用により本願に含まれるものとする。
【００１８】
ＣＤＮは、カスタマ・コンテンツの中間キャッシングを提供するためにサーバ・キャッシュ階層を運用することができる。このようなキャッシュ階層サブシステムの一例が米国特許第７，３７６，７１６号に記載されている。この開示内容は引用により本願に含まれるものとする。
【００１９】
ＣＤＮは、米国特許出願公開第２００４００９３４１９号に記載されたように、クライアント・ブラウザ、エッジ・サーバ、及びカスタマ・オリジン・サーバ間でセキュアなコンテンツ配信を提供することができる。これに記載されたセキュアなコンテンツ配信は、一方ではクライアントとエッジ・サーバ・プロセスとの間で、他方ではエッジ・サーバ・プロセスとオリジン・サーバ・プロセスとの間でＳＳＬベースのリンクを実施する。これによって、ＳＳＬによって保護されたウェブ・ページ及び／又はそのコンポーネントを、エッジ・サーバを介して配信することができる。
【００２０】
オーバーレイとしてＣＤＮリソースを用いることにより、（プライベートに管理可能な）エンタープライズ・データ・センタと第三者へのサービスとしてのソフトウェア（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ：wide area network）高速化サービスを容易にしてもよい。
【００２１】
典型的な運営においては、コンテンツ・プロバイダは、ＣＤＮによりサービスされることを望むコンテンツ・プロバイダ・ドメイン又はサブ・ドメインを特定する。ＣＤＮサービス・プロバイダは、（例えば正規名又はＣＮＡＭＥを介して）コンテンツ・プロバイダ・ドメインをエッジ・ネットワーク（ＣＤＮ）・ホスト名と関連付け、するとＣＤＮプロバイダがそのエッジ・ネットワーク・ホスト名をコンテンツ・プロバイダに提供する。コンテンツ・プロバイダのドメイン・ネームサーバは、コンテンツ・プロバイダ・ドメイン又はサブ・ドメインへのＤＮＳクエリを受信すると、エッジ・ネットワーク・ホスト名を返すことによって応答する。エッジ・ネットワーク・ホスト名はＣＤＮを指すので、ＣＤＮネーム・サービスにより解決される。そのために、ＣＤＮネーム・サービスは１つ以上のＩＰアドレスを返す。すると、リクエストを行っているクライアント・ブラウザは、そのＩＰアドレスと関連付けられているエッジ・サーバに対して（例えばＨＴＴＰ又はＨＴＴＰＳを介して）コンテンツ・リクエストを行う。このリクエストは、オリジナル・コンテンツ・プロバイダ・ドメイン又はサブ・ドメインを含むホスト・ヘッダを含んでいる。ホスト・ヘッダを有するリクエストを受信すると、エッジ・サーバはその構成ファイルをチェックして、リクエストされたコンテンツ・ドメイン又はサブ・ドメインが実際にＣＤＮによって処理されているのか否かを判断する。処理されているのであれば、エッジ・サーバは、構成に規定されているように、そのドメイン又はサブ・ドメインに対するコンテンツ処理規則及び命令を適用する。これらのコンテンツ処理規則及び命令はＸＭＬベースの「メタデータ」構成ファイル内にあってもよい。
【００２２】
さらなる背景として、ＣＤＮカスタマは、「ファイアウォールの背後（"behindthe firewall”）」で管理されるサービス・プロダクトにサブスクライブして、カスタマのエンタープライズ・ファイアウォールの背後にてホストされるイントラネット・ウェブ・アプリケーションを高速化するとともに、ファイアウォールの背後のユーザをインターネット・クラウドにてホストされるアプリケーションへとブリッジするウェブ・アプリケーションを高速化することができる。これら２つのケースを実現するために、ＣＤＮソフトウェアは、１つ以上のカスタマ・データ・センタでホストされるバーチャル・マシーン上、及び遠隔の「ブランチ・オフィス」でホストされるバーチャル・マシーン上で実行され得る。カスタマ・データ・センタで実行するＣＤＮソフトウェアは、典型的にはサービス構成、サービス管理、サービス報告、遠隔管理アクセス、カスタマＳＳＬ証明書管理、及び構成されたウェブ・アプリケーションの他の機能を提供する。ブランチ・オフィスで実行されるソフトウェアは、そこに位置するユーザに対してラストワンマイルのウェブ高速化を提供する。ＣＤＮそれ自体は、典型的にはＣＤＮデータ・センタでホストされるＣＤＮハードウェアを提供し、カスタマ・ファイアウォールの背後で動作しているノードとサービス・プロバイダの他のインフラストラクチャ（例えばネットワーク及び運営施設）との間にゲートウェイを設ける。このように管理されたソリューションによって、企業が自社のイントラネットに対してＣＤＮ技術を利用できるようになる。図３は、このタイプの基本アーキテクチャを説明している。代表的な実施形態においては、ＢＴＦネットワークは、マネジメント・ゲートウェイ（ＡＭＧ）３００及び１つ以上のエンタープライズ・マネジメント・ゲートウェイ（ＥＭＧ）３０２により管理される。ＡＭＧは、ＣＤＮが運営するネットワーク・サービスが可用な場所にあり、既存のカスタマのデータベースを管理するとともに、ＥＭＧに対してアクセスする。ＥＭＧ３０２はカスタマのファイアウォールの内側に存在しており、ＢＴＦネットワークの個々のエンド・ノード３０４を管理する。エンド・ノードは従来のＣＤＮにおけるエッジ・ノードに相当する。ＡＭＧはＥＭＧを承認し（ステップ１）、ＥＭＧはエッジ・ノードＡ及びＢを承認する（ステップ２及び３）。かくして両エッジ・ノードは互いを信頼するとともにＥＭＧを信頼し、図示するようなカスタマの信頼ゾーンを創出する（ステップ４）。この基本的な信頼モデルによると、ＡＭＧ３００がＥＭＧ３０２に対して会社のＢＴＦ機能を実行するための権限を付与する。次いで、ＥＭＧ３０２がエンド・ノードの各々に対して、様々な役割又はタスクを実行するための権限を付与する。このような権限付与の連鎖を介して信頼が確立されると、プライベート・データ及びシークレットをネットワーク上でセキュアに交換することが可能となる。このアプローチでは、エッジ・ノードは典型的には（エンドユーザの近くの）遠隔のブランチ・オフィスにインストールされ、ＥＭＧ（親ノード／領域）はコーポレート・ハブ（典型的には、アプリケーション・サーバが位置するところ）にインストールされる。上述のように、この��リューションは、企業のために高速化を、ＳａａＳ（サービスとしてのソフトウェア）アプリケーションなどのインターネット上の任意の場所でサービスされるアプリケーションに拡大するものである。企業のＣＤＮベースのプライベート・オーバーレイ・ネットワークを既存のＣＤＮパブリック・インターネット・オーバーレイ・ネットワークにブリッジすることによって、遠隔ブランチ・オフィスのエンドユーザにとって、エンドツーエンドのアプリケーションが高速化される。
【００２３】
ＢＴＦがＳＳＬトラフィックを適切に高速化するためには、エンド・ノード上のＳＳＬ鍵及び証明書が必要である。上述のように、ＳＳＬはＲＳＡ復号化を一度行って、クライアントとサーバとの間にプライベートなプリ・マスタ・シークレットを確立する。本開示によれば、このＲＳＡ復号化を、秘密鍵を有するセキュアなエンド・ノード又は他のサービスに肩代わりさせるが、その一方でハンドシェイクの残り及びＳＳＬ接続は通常通りに続行する。次にこのプロセスを説明する。
【００２４】
ローカルにアクセス可能な秘密鍵を使用しない、ＳＳＬ接続の終了
上述のことを背景として、ここで本開示の主題について説明する。ＳＳＬハンドシェイクを熟知していることを前提とする。
【００２５】
本開示によれば、従来のＳＳＬハンドシェイク、特に暗号化されたプリ・マスタ・シークレットの復号化は、通常のＳＳＬ終了ポイント（ＳＳＬサーバ）の外部で（すなわちそこから遠く離れて）行われる。図４に図示されるように、終了ポイントにあるＳＳＬサーバ４００はプロキシ・サーバの「クライアント・コンポーネント」４０２を備え、該プロキシ・サーバの「サーバ・コンポーネント」４０４は遠隔に位置している。サーバ・コンポーネント４０４にはデータ・ストア４０６が関連付けられており、該データ・ストアには単数又は複数の復号鍵４０８が保持されている。この復号鍵４０８は、クライアント・コンポーネント４０２にはアクセス不可能である。後述するように、ＳＳＬハンドシェイクの間、暗号化されたプリ・マスタ・シークレットそれ自体を復号化する代わりに、クライアント・コンポーネント４０２は（従来のＳＳＬクライアント４１０から）受信した暗号化されたプリ・マスタ・シークレットをサーバ・コンポーネント４０４にプロキシし（転送し）、復号化されたプリ・マスタ・シークレットを応答として受信する。（ＳＳＬサーバ４００とＳＳＬクライアント４１０との間の）ＳＳＬトランザクションの残りは通常通りに完了する。このアプローチでは、ＳＳＬ秘密鍵はＳＳＬサーバ上（あるいは、より一般的には、ＳＳＬ終了ポイント）には記憶されない。
【００２６】
好ましくは、プロキシ・サーバのクライアント・コンポーネント４０２及びサーバ・コンポーネント４０４は、ＲＳＡ暗号化をベースとしている。したがって、これらのコンポーネントは、本明細書においてはＲＳＡプロキシ・コンポーネントとも称される。暗号化されたプリ・マスタ・シークレットの（クライアント・コンポーネントからサーバ・コンポーネントへの）転送は、本明細書においてはＲＳＡプロキシ・リクエストとも称される。好ましいアルゴリズムはＲＳＡであるが、他の非対称暗号化アルゴリズムも同様に使用することができる。
【００２７】
次に再び図３を参照すると、ブランチ・オフィス及びデータ・センタ・マシーンは、好ましくはセキュアな接続（例えば、相互認証されたＳＳＬ接続）を使用して通信を行いトラフィックを渡す。他のタイプのセキュアな接続（例えば、ＩＰＳｅｃ  ＶＰＮ）を使用してもよい。このような接続を、ＲＳＡプロキシ・リクエスト、ユーザ・データならびに他のトラフィックのために使用する。上述のように、ＲＳＡプロキシ・クライアント・コンポーネントはブランチ・オフィスで実行されるが、それに関連付けられたサーバ・コンポーネントは（よりセキュアな）データ・センタで実行される。一実施形態においては、すべてのマシーンが、ピアとの通信に用いる単一のクライアント証明書及び鍵ペアを有する。新たなマシーンが（例えばＣＤＮカスタマ・ポータルによって）プロビジョニングされると、当該マシーンは秘密鍵及びＣＳＲ（Certificate Signing Request；証明書署名要求）を生成し、後者をＡＭＧへ送信する。ＣＳＲは、ブランチ・オフィス又はデータ・センタ・マシーンに固有のシリアル番号などの一対の識別子と、ＣＳＲのバージョンのシリアル番号とを含むのが好ましい。ＡＭＧは（好ましくはＣＤＮに関連付けられた認証局（ＣＡ）を利用して）ＣＳＲに署名し、証明書をブランチ・オフィスのマシーンに送信する。さらに、ＡＭＧは、証明書の詳細（シリアル番号ペア）を含むメッセージを、（ポータル内のピア構成に基づいて）ブランチ・オフィスと通信する可能性のある任意のデータ・センタに送信する。ＡＭＧは、他のＣＤＮ鍵管理基盤を利用して、クライアント及びサーバのＣＳＲに（好ましくはＣＤＮに関連付けられたＣＡを利用して）署名する。好ましくは、ブランチ・オフィスのマシーン及びデータ・センタ・マシーンの両方が有効なピア及びＣＡのコレクションを保持する。このコレクションがＡＭＧにより更新されることによって、ローテーション及び失効がサポートされる。さらに、各ボックスがＣＡのコピーと、ボックス及び証明書のシリアル番号により識別される許容可能なピアのホワイトリストとを有するのが好ましい。相互認証を確立するために、相互ＳＳＬ接続の両側（換言すれば、一方の側ではＲＳＡプロキシ・クライアント・コンポーネント、他方の側ではＲＳＡプロキシ・サーバ・コンポーネント）が、ピア証明書のチェーンのルート・ノードがＣＡと合致すること及び含まれるシリアル番号ペアは許容可能であることを検証する。クライアント・コンポーネント及びサーバ・コンポーネントは、ピア証明書が予想されたマシーン・シリアル番号を含むことも検証する。
【００２８】
図４に示すように、ＲＳＡプロキシ・クライアント４０２はＳＳＬトランスポート・モジュールの一部である。動作時、ClientHelloを（入ってくるＳＳＬハンドシェイク・リクエストから）受信すると、ＳＳＬモジュールはＩＰアドレス（及びポート）及び証明書（certs）のラーニング・テーブルをチェックする。エントリが存在しなければ、データを変更せずにストリーミングする。データ・センタのマシーンがＩＰ及びポートについてＲＳＡプロキシを実行できる場合には、ＲＳＡプロキシされるサーバ証明書（cert）を含む新たなメッセージを返信する。ＳＳＬモジュールはＩＰアドレス及び証明書（cert）をラーニング・テーブルに追加する。そのＩＰアドレスについての次の新規の（再開されたのではない）ＳＳＬトランザクションでは、ＳＳＬモジュールがエントリを発見し、ＲＳＡプロキシ・トランザクションを行うことを知る。ラーニング・テーブルのエントリは、当該エントリを使用したＲＳＡプロキシ・リクエストが失敗した場合に（代替的には、一定の不使用期間の後で）、削除される。これらのエントリは、データ・センタ・マシーンによっていつでも、例えばプロキシ・クライアントが特定のＩＰ及びポートの新たな証明書（cert）を含む別のメッセージを送信することにより、更新可能である。
【００２９】
ハンドシェイクの間に、モジュールはＳＳＬ接続を終了し、リクエストを行っているクライアントに対して、ServerCertificateをラーニング・テーブルからの証明書（cert）とともに送信する。ClientKeyExchangeメッセージ及びｅＰＭＳを受信すると、モジュールは、ＲＳＡプロキシ・リクエストを正しいデータ・センタに送信する。本開示によれば、上述のように、ＲＳＡプロキシ・リクエスト及び応答はＲＳＡプロキシ・サーバのサーバ・コンポーネント４０４によって処理され、該サーバ・コンポーネントが相互認証されたＳＳＬ接続を介してデータを送受信する。ＲＳＡプロキシ・サーバのサーバ・コンポーネント４０４が失敗を返すか、又はタイム・アウトした場合には、ＳＳＬモジュール（クライアント・コンポーネント４０２）はクライアント接続を終了し、ハンドシェイクは不成功に終わる。
【００３０】
ＳＳＬモジュールは、制限なしにＳＳＬプロトコル・ターミネータとしてインプリメントされる。一実施形態においては、ＳＳＬモジュールは、標準的なＯｐｅｎＳＳＬの上に構築されたプログラム・コードである。
【００３１】
ＲＳＡプロキシ・クライアント・コンポーネント（ブランチ・オフィスのＳＳＬモジュール）は、メッセージ・インタフェースを使用して、ＲＳＡプロキシ・リクエスト及び応答を、相互認証されたＳＳＬ接続を介して送信する。好ましくは、ＲＳＡクライアント・リクエストは、｛ｅＰＭＳの長さ、ｅＰＭＳ、サーバ証明書のハッシュ｝の情報フィールドを含むパケットである。ＲＳＡプロキシ・サーバ・コンポーネント（データ・センタのＳＳＬモジュール）から返ってくる応答パケットは、｛状態、復号化されたＰＭＳの長さ、復号化されたプリ・マスタ・シークレット｝の情報フィールドを有する。
【００３２】
次に、データ・センタの施設で実行するＲＳＡプロキシ・サーバ・コンポーネントの一実施形態を説明する。前述のように、その基本的な動作は、既に説明したリクエストを含む暗号化されていないパケットを受信すること、および定義された応答パケットで応答することである。好ましくは、ＲＳＡプロキシ・サーバは、ｅＰＭＳの値の最低使用頻度（ＬＲＵ：least-recently-used）キャッシュを保持する。復号化を実行する前に、モジュールはキャッシュをチェックして、要求されたｅＰＭＳが以前にあったか否かを確認する。このチェックには、ハッシュ・ルックアップ方式を用いてよい。暗号化されたプリ・マスタ・シークレットのハッシュがキャッシュ中に既に存在する場合には、ＲＳＡプロキシ・クライアント・コンポーネントに対して不良状態を返す（そして、管理者のためにエラー又は警報を生成する）。好ましくは、ＲＳＡプロキシ・サーバのサーバ・コンポーネントがリクエストをレート制限して、危殆化したマシーンがフラッシュ攻撃を仕掛けて以前に復号化されたシークレットを削除するのを防止する。好ましくは、ＲＳＡプロキシ・サーバのサーバ・コンポーネントも、プロキシとして動作することが可能な証明書及び鍵ペアのテーブルを保持している。このテーブル（ハッシュ・テーブルとしてインプリメントしてよい）を用いることにより、プロキシ・サーバは、（例えば、クライアント・コンポーネントが送信する証明書のハッシュによって）サーバの鍵ペアを効率的にルックアップすることができる。ＲＳＡプロキシ・サーバのサーバ・コンポーネントは、ｅＰＭＳが新しいことを確認したならば、それをキャッシュに追加し、テーブル中のサーバの秘密鍵をルックアップし、ｅＰＭＳを復号化し、応答を送信する。
【００３３】
本明細書に記載の技術には多くの利点がある。第一の利点は、ＳＳＬ秘密鍵がＳＳＬサーバ上に記憶されないことである。上述したような分散型のソリューションにおいて、このことは、秘密鍵がＳＳＬを終了中であるブランチ・オフィスのボックスには記憶されず、その代わりに、ＲＳＡプロキシ・サーバのサーバ・コンポーネントをホストしているデータ・センタのボックスに記憶されることを意味している。リプレイ攻撃からの保護策をインプリメントしたため、攻撃者が危殆化したＳＳＬサーバを使用して以前のＳＳＬトランザクションを復号化することはできない。標準のＳＳＬサーバ上では、鍵が危殆化した場合、盗まれたＳＳＬ鍵の使用を防ぐため、（クライアント・ブラウザの証明書失効リスト又はＯＣＳＰなどの）他の技術が用いられなければならない。ＲＳＡプロキシによれば、サービス・プロバイダはＲＳＡプロキシ・サーバの構成を変更するだけでよい。このような分散型のアプローチを利用することにより、ＳＳＬトランザクションのうち計算コストが高い部分であるＲＳＡ復号化を、データ・センタのカスタム・ハードウェアを備えたマシーン上で行うことができる。
【００３４】
（ブランチ・オフィスの）ウェブ・プロキシ・ノードの危殆化が発見された場合には、管理者は、危殆化したノードの認証済クレデンシャルを単に削除しさえすればよい。標準的なＳＳＬの場合には、各エンドユーザ・システムで失効させる必要があるが、これを管理するのは困難である。また、鍵ローテーションはＲＳＡプロキシ・マシーン上でのみ行えばよいが、標準的なＳＳＬではすべてのウェブ・プロキシ・マシーン上で行う必要がある。
【００３５】
ファイアウォールの背後での実施形態を述べたが、これは本開示を制限することを意図するものではない。ＲＳＡプロキシ・アプローチは、企業が、インターネットを介してブランチ、データ・センタ、在宅勤務、及びモバイル・ユーザをアプリケーションへと接続する最適化なＷＡＮとして、（上述したような）インターネット・リンクを介するＣＤＮ技術を使用するときにはいつでも、利用可能である。さらに一般的には、このアプローチは、あるパーティ（クライアント）が別のパーティ（サーバ）との通信をＲＳＡベースのＳＳＬにより暗号化することを希望するけれども、サーバにＲＳＡ秘密鍵を直接記憶させることが信用できない場合にはいつでも、利用可能である。
【００３６】
代表的な実施形態においては、ＲＳＡプロキシは、プロセッサにより実行されるコンピュータ・プログラム命令として、ソフトウェアの形態でインプリメントされる。
【００３７】
より一般的には、本明細書に記載された技術は、一緒になって上述の機能を容易にし又は提供する、一連の１つ以上のコンピュータ関連のエンティティ（システム、マシーン、プロセス、プログラム、ライブラリ、機能など）を用いて提供される。典型的な実施形態においては、ソフトウェアが実行される代表的なマシーンは、コモディティ・ハードウェア、オペレーティング・システム、アプリケーション・ランタイム環境、及び一連のアプリケーション又はプロセス、ならびに関連データであって、所与のシステム又はサブシステムを提供するものから成る。既述の通り、機能はスタンドアロン・マシーンの形態でインプリメントされてもよいし、あるいは一連の分散されたマシーンにわたってインプリメントされてもよい。機能はサービス、例えばＳａａＳソリューションとして提供されてもよい。
【００３８】
上記は本発明のいくつかの実施形態によって実行される動作の特定の順序を記載したが、代替的な実施形態では、異なる順序での動作の実行、いくつかの動作の組み合わせ、いくつかの動作の重複等があり得るから、このような順序は例示的なものであることは理解されよう。本明細書における所与の実施形態の参照は、記載する実施形態が特定の特性、構造、又は特徴を含む場合があるが、全ての実施形態がその特定の特性、構造、又は特徴を必ずしも含むものではないことを示している。
【００３９】
開示した主題は、方法又はプロセスに照らして記載したが、主題の開示は本明細書における動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築してもよく、又はコンピュータに記憶したコンピュータ・プログラムによって選択的に活性化又は再構成される汎用コンピュータを含んでもよい。そのようなコンピュータ・プログラムは、限定ではないが、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクを含むいずれかのタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気もしくは光カード、又は電子命令の記憶に適したいずれかのタイプの媒体等のコンピュータ読み取り可能記憶媒体に記憶することができ、その各々はコンピュータ・システム・バスに結合される。システムの所与のコンポーネントを別個に記載したが、それらの機能のいくつかは、所与の命令、プログラム・シーケンス、コード部分等において組み合わせるか共有することが可能であることは当業者には認められよう。
【００４０】
これは限定ではないが、特定の機能の一部はオペレーティング・システム等に内蔵できるから、機能はアプリケーション層ソリューションの形態でインプリメントされるのが好ましい。
【００４１】
機能はまた、ＳＳＬ  ＶＰＮなどの、ＨＴＴＰＳ以外の他のアプリケーション層プロトコル、又は類似の動作特性を有する他のプロトコルによってインプリメントされてもよい。
【００４２】
接続のクライアント側又はサーバ側をインプリメントし得るコンピューティング・エンティティのタイプに限定はない。いかなるコンピューティング・エンティティ（システム、マシーン、デバイス、プログラム、プロセス、ユーティリティなど）であっても、クライアント又はサーバとしての機能を果たすことができる。
【００４３】
本明細書の技術はＳＳＬ通信で用いられるＲＳＡプロキシとのかかわりで説明されているが、これは限定ではない。また、この方式は、暗号技術により保護される（ＴＬＳなどの）他のトランスポート・プロトコルでインプリメントされてもよい。より一般的には、本明細書の技術は、秘密データをあるピアから別のピアへ非対称暗号を用いて交換する必要があるけれども、受信側のピアが秘密鍵を有することを信用されていない任意のコンテキストにおいて用いることができる。
【図１】
2015505994.tif 000003
【図２】
2015505994.tif 000004
【図３】
2015505994.tif 000005
【図４】
2015505994.tif 000006
【国際調査報告】
2015505994.tif 000007
2015505994.tif 000008
2015505994.tif 000009