複数の暗号方式から選択した暗号方式を使用して他の通信装置との間で暗号通信を行う通信装置であって、前記他の通信装置の使用可能な暗号方式の第1の情報を取得する暗号方式取得部と、前記第1の情報に基づいて、前記複数の暗号方式から前記他の通信装置との間の通信で使用する暗号方式を選択する暗号方式選択部と、前記暗号方式選択部が選択した暗号方式を前記他の通信装置に送信する送信部と、を備える通信装置。請求項1記載の通信装置であって、前記暗号方式取得部は、前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第1の情報を取得する通信装置。請求項2記載の通信装置であって、前記他の通信装置との通信における前記複数の暗号方式の優先順位情報をさらに有し、前記暗号方式取得部は、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信する通信装置。請求項3記載の通信装置であって、前記優先順位情報は、他の通信装置に応じてそれぞれ異なる通信装置。請求項2記載の通信装置であって、前記暗号方式取得部は、前記応答結果に基づいて前記他の通信装置が使用できない暗号方式の第2の情報を取得する通信装置。請求項1記載の通信装置であって、前記暗号方式取得部は、前記複数の暗号方式から選択した複数の暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第1の情報を取得する通信装置。第1の通信装置と第2の通信装置とを備える通信システムであって、前記第1の通信装置は、複数の暗号方式を使用可能であり、使用可能な暗号方式を前記第2の通信装置に送信し、前記第2の通信装置は、前記第1の通信装置から送信された暗号方式の使用可否の情報を前記第1の通信装置に送信する通信システム。請求項6記載の通信システムであって、前記第1の通信装置は、前記第2の通信装置から送信された前記使用可否の情報に基づいて、前記複数の暗号方式から前記第2の通信装置との間の通信で使用する暗号方式を選択する通信システム。請求項6記載の通信システムであって、前記第1の通信装置は、前記第2の通信装置における前記複数の暗号方式の優先順位情報を有し、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記第2の通信装置に送信する通信装置。請求項8記載の通信システムであって、前記第1の通信装置と通信可能な第3の通信装置をさらに有し、前記第1の通信装置は、前記第3の通信装置における前記複数の暗号方式の優先順位情報を有する通信システム。請求項6記載の通信システムであって、前記第1の通信装置は、前記複数の暗号方式から選択した複数の暗号方式を前記第2の通信装置に送信し、前記第2の通信装置は、前記第1の通信装置から送信された各暗号方式の使用可否の情報を前記第1の通信装置に送信する通信システム。しかしながら、サーバの中には、クライアントが提示する優先順位の高い暗号スイートをサポートしているにも関わらず、優先順位を無視して、提示された暗号スイートの中から、サーバが希望する暗号スイートを選択するものが存在する。つまり、サーバの中には、SSL/TLS暗号通信の仕様に従わずに、サーバ側で暗号スイートの優先順位付けを行うものが存在する。本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、SSL/TLS暗号通信のクライアントとして動作している安価な組込み機器に、本来のSSL/TLS暗号通信の仕様非特許文献1、2、3参照通りに、暗号スイートの優先順位付けの権利を与えることを目的としている。これにより、安価な組込み機器でも、パフォーマンス良くSSL暗号通信を利用できるようにするものである。上述の課題を解決するために、本発明の通信装置は、複数の暗号方式から選択した暗号方式を使用して他の通信装置との間で暗号通信を行う通信装置であって、前記他の通信装置の使用可能な暗号方式の第1の情報を取得する暗号方式取得部と、前記第1の情報に基づいて、前記複数の暗号方式から前記他の通信装置との間の通信で使用する暗号方式を選択する暗号方式選択部と、前記暗号方式選択部が選択した暗号方式を前記他の通信装置に送信する送信部と、を備えるように構成とした。また、本発明の通信装置は、前記暗号方式取得部は、前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第1の情報を取得するように構成した。また、本発明の通信装置は、前記他の通信装置との通信における前記複数の暗号方式の優先順位情報をさらに有し、前記暗号方式取得部は、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信するように構成した。また、本発明の通信装置は、前記優先順位情報は、他の通信装置に応じてそれぞれ異なるように構成した。また、本発明の通信装置は、前記暗号方式取得部は、前記応答結果に基づいて前記他の通信装置が使用できない暗号方式の第2の情報を取得するように構成した。また、本発明の通信装置は、前記暗号方式取得部は、前記複数の暗号方式から選択した複数の暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第1の情報を取得するように構成した。また、本発明の通信システムは、第1の通信装置と第2の通信装置とを備える通信システムであって、前記第1の通信装置は、複数の暗号方式を使用可能であり、使用可能な暗号方式を前記第2の通信装置に送信し、前記第2の通信装置は、前記第1の通信装置から送信された暗号方式の使用可否の情報を前記第1の通信装置に送信するように構成した。また、本発明の通信システムは、前記第1の通信装置は、前記第2の通信装置から送信された前記使用可否の情報に基づいて、前記複数の暗号方式から前記第2の通信装置との間の通信で使用する暗号方式を選択するように構成した。また、本発明の通信システムは、前記第1の通信装置は、前記第2の通信装置における前記複数の暗号方式の優先順位情報を有し、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記第2の通信装置に送信するように構成した。また、本発明の通信システムは、前記第1の通信装置と通信可能な第3の通信装置をさらに有し、前記第1の通信装置は、前記第3の通信装置における前記複数の暗号方式の優先順位情報を有するように構成した。また、本発明の通信システムは、前記第1の通信装置は、前記複数の暗号方式から選択した複数の暗号方式を前記第2の通信装置に送信し、前記第2の通信装置は、前記第1の通信装置から送信された各暗号方式の使用可否の情報を前記第1の通信装置に送信するように構成した。また、本発明の通信装置は、クライアントにおける暗号スイートの優先順位情報に従って、利用する暗号スイートを選択するクライアントであって、前記クライアントはサーバの暗号スイートの搭載状況を調査する暗号スイート調査手段を備え、前記クライアントはこの前記暗号スイート調査手段を用いて、少なくとも1度は事前にサーバにおける暗号スイートの搭載情報を取得するものとし、SSL/TLS暗号通信で利用する暗号スイートの選択において、取得した暗号スイートの搭載情報を用いて、最適な暗号スイートを指定するように構成した。ここで、暗号スイート調査手段というのは、例えば、別のコンピュータが調査した搭載情報を、そのコンピュータから取得するものであってもよいし、また自ら対象のサーバを調査し、搭載情報を取得するものであってもよい。これによると、たとえ、相手が利用する暗号スイートの優先順位づけを行うサーバであっても、クライアントが主導的に利用する暗号スイートの優先順位付けを行うことが可能となり、安価な組込み機器のクライアントでも、パフォーマンス良くSSL暗号通信を利用できるようなる。また、本発明の通信装置は、クライアントにおける暗号スイートの優先順位情報に従って、利用する暗号スイートを選択するクライアントであって、前記クライアントはサーバの暗号スイートの搭載状況を調査する暗号スイート調査手段を備え、前記クライアントはこの前記暗号スイート調査手段を用いて、少なくとも1度は事前にサーバにおける暗号スイートの搭載情報を取得するものとし、SSL/TLS暗号通信で利用する暗号スイートの選択において、前記クライアントは、前記サーバにおける暗号スイートの搭載情報と前記クライアントにおける暗号スイートの優先順位情報とから、前記サーバで利用可能な、クライアントにとって最も優先順位の高い暗号スイートを選択し、SSL/TLSネゴシエーションSSL/TLSハンドシェイクで、前記クライアントが前記サーバに利用する暗号スイートを指定するにあたっては、前記クライアントが選択した前記暗号スイートを少なくとも含み、かつ、選択した前記暗号スイートよりも前記サーバで優先順位の高い暗号スイートを含まない暗号スイートを指定するように構成した。これによると、たとえ、相手が利用する暗号スイートの優先順位づけを行うサーバであっても、クライアントが主導的に利用する暗号スイートの優先順位付けを行うことが可能となり、安価な組込み機器のクライアントでも、パフォーマンス良くSSL暗号通信を利用できるようなる。また、本発明の通信装置は、前記暗号スイート調査手段は、調査したい暗号スイートを指定してSSL/TLSネゴシエーションSSL/TLSハンドシェイクを行い、前記サーバの応答結果を得ることで、その指定した暗号スイートが、前記サーバで搭載されているか否かを判断するように構成した。これによると、クライアントは、サーバにおける暗号スイートの搭載情報を簡単、かつ迅速に取得できるようになる。また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントが搭載していない暗号スイートも調査するように構成した。これによると、暗号スイートの追加が図れるクライアントにおいては、あらかじめ追加される暗号スイートも含めてサーバにおける搭載状況を調査し、その搭載情報を保存しておけば、暗号スイート追加時に再調査の必要がなく、迅速な処理が可能となる。また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントが搭載している暗号スイートのみを調査するように構成した。これによると、サーバにおける暗号スイートの搭載状況の調査を迅速に行うことができる。暗号スイートの追加がない、若しくは稀にしかないクライアントでは、暗号スイート追加時の再調査を考慮するより、最初の搭載状況の調査時間を短縮させる方が望ましい。また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントにおける暗号スイートの優先順位順に、前記サーバにおける暗号スイートの搭載状況を調査し、かつ前記サーバがアラートを返信するか、若しくは調査する暗号スイートがなくなるまで、前記サーバにおける暗号スイートの搭載状況を調査するように構成した。これによると、クライアントが搭載する暗号スイートに関して、サーバが搭載するか否かを調査することになるので、この搭載情報を保存すれば、クライアント側で暗号スイートの優先順位付けが変更になる際に、再調査の必要がなくなる。クライアントにおける暗号スイートの優先順位付けをユーザ設定にしていて、頻繁に暗号スイートの優先順位付けが変更される場合に効果が大きい。また、本発明の通信装置は、前記クライアントは、調査したい複数の暗号スイートを複数同時に指定してSSL/TLSネゴシエーションSSL/TLSハンドシェイクを行い、前記サーバの応答結果を得ることで、その指定した少なくとも1つ以上の暗号スイートが、前記サーバで搭載されているか否かを判断するものとし、前記応答結果が、前記サーバからの暗号スイートの指定であった場合には、先に指定した複数の暗号スイートから、この前記サーバが指定した暗号スイートを除去した1つ以上の暗号スイートを指定して、再度、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを行い、前記サーバの応答結果から、この新たに指定した少なくとも1つ以上の暗号スイートが、前記サーバで搭載されているか否かの判断を行うように構成した。これによると、クライアントが搭載する暗号スイートに関して、サーバが搭載するか否かを調査する場合、その調査時間を短縮できる。クライアントが搭載する暗号スイートをサーバが搭載するか否かを1つ1つ調査する場合は、暗号スイートの数だけ調査しなければならず時間を要する。一方この方法では、クライアントが、サーバが搭載する暗号スイートを少なくとも1つでも含む暗号スイートを提示している間は、1つ1つ調査する場合と手間は変わらないが、最後に、サーバが搭載しない複数の暗号スイートを提示した場合に、一回の調査で済み、手間を省ける。なおこの方法では、サーバが暗号スイートの優先順位付けを行うサーバの場合、サーバが搭載する暗号スイートだけでなく、サーバが選択した暗号スイートの順番を見ることで、サーバにおける暗号スイートの優先順位付けをも知ることが可能である。また、本発明の通信装置は、前記暗号スイート調査手段は、サーバにおける暗号スイートの優先順位も合わせて調査するように構成した。これによると、サーバにおける暗号スイートの優先順位付けと、クライアントにおける暗号スイートの優先順位付けが同じであれば、クライアントはSSL/TLSネゴシエーションを通常の方法で実行できる。クライアントで搭載情報を記憶できない装置の場合、毎回、サーバにおける暗号スイートの搭載状況を調査する必要がなくなる。つまり、SSL/TLSネゴシエーション処理の迅速化が図れてよい。また、本発明の通信装置は、前記暗号スイート調査手段は、複数のTCPポートを用意し、それぞれのポートで、各々に調査したい暗号スイートを指定して、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを行うように構成した。これによると、クライアントはサーバにおける暗号スイートの搭載状況を迅速に調査することが可能となる。同じTCPポートを利用して調査する場合は、一回一回、サーバの応答を待たなくてはならないが、この方法を利用すれば、その必要がなくなる。また、本発明の通信装置は、前記暗号スイート調査手段は、SSL/TLS暗号通信で利用するTCPポートとは別のTCPポートを利用して調査するように構成した。これによると、SSL/TLS暗号通信を行うのに、SSL/TLS暗号通信を行う主体であるアプリケーションと、SSL/TLS暗号通信を実現するSSL/TLS暗号モジュールが分離され実装されている場合に、SSL/TLS暗号モジュールは、アプリケーションがSSL/TLS暗号通信に利用するとしてSSL/TLS暗号モジュールに指定したTCPポートを利用せずに、別のTCPポートを利用してサーバにおける暗号スイートの搭載状況を調査できる。調査に利用するTCPポートは閉じらる場合があるが、この方法であれば、アプリケーションがSSL/TLS暗号通信に利用するとしてSSL/TLS暗号モジュールに指定したTCPポートは調査には利用されないので、閉じられない。これにより、アプリケーションのつくりを非常に簡単にできる。また、本発明の通信装置は、前記クライアントは、前記サーバにおける暗号スイートの搭載情報の記憶、及び、読出しを行う搭載状況記憶手段を備え、前記クライアントはこの前記搭載状況記憶手段を用いて、前記サーバにおける暗号スイートの搭載情報を記憶し、SSL/TLS暗号通信において、この前記搭載状況記憶手段を用いて、記憶した前記サーバにおける暗号スイートの搭載情報を読出すように構成した。これによると、サーバにおける暗号スイートの搭載状況調査を再度実行する必要がないので、SSL/TLSネゴシエーションを迅速に行うことができる。また、本発明の通信装置は、前記サーバにおける暗号スイートの搭載情報と前記クライアントにおける暗号スイートの優先順位情報とを別々に記憶するように構成した。これによると、接続するサーバや通信目的によってクライアントにおける暗号スイートの優先順位付けが異なる場合に、記憶容量を減らせると共に、記憶方法を簡略化することが可能となる。また、本発明の通信装置は、前記サーバにおける暗号スイートの搭載情報と、前記クライアントにおける暗号スイートの優先順位情報とを、合わせて記憶するように構成した。これによると、接続するサーバが決まっている場合などに、記憶容量を減らすことができる。また、本発明の通信装置は、通信内容やクライントの負荷状況など、前記クライントの都合によって、利用する暗号スイートの優先順位付けが異なる前記クライアントであって、前記クライアントがSSL/TLS暗号通信中に通信内容を変更する場合に、SSL/TLSの再ネゴシエーションを行うように構成した。これによると、たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、通信目的やクライントの負荷状況に応じて、クライアントが主導的に暗号スイートを選択できる。例えば、クライアントは、認証ではセキュリティの高い暗号スイートを選択し、負荷状況が高い多量のデータの受け渡しにおいては、パフォーマンスのよい暗号スイートを選択することが可能である。また、本発明の通信装置は、複数のサーバと通信する前記クライアントであって、通信するサーバに合わせて、利用する暗号スイートの優先順位情報を変更するように構成した。これによると、様々な種類のサーバに対してもクライアント主導で暗号スイートを選択して通信できるようになる。また、本発明の通信装置は、前記クライアントにおける暗号スイートの優先順位情報をユーザが変更できる優先順位変更手段を備え、この前記優先順位変更手段を用いて、前記クライアントにおける暗号スイートの優先順位情報を変更するように構成した。これによると、ユーザのセキュリティポリシーや考え方を、SSL/TLS暗号通信に反映できる。また、本発明の通信装置は、前記クライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する調査判断手段を備え、前記クライアントが、前記調査判断手段を用いて、前記サーバにおける暗号スイートの搭載情報を調査するか否かの判断を行うように構成した。これによると、暗号スイート優先順位付けを行わないサーバや、暗号スイートの優先付けを行っていてもクライアントにとって影響の小さいサーバに対してまでも、クライアントがサーバにおける暗号スイートの搭載状況を調査する必要がなくなり、手間が省けてよい。また、本発明の通信装置は、前記調査判断手段は、サーバが搭載する少なくとも2つ以上の暗号スイートを同時に指定したSSL/TLSネゴシエーションSSL/TLSハンドシェイクを行い、前記サーバが、ClientHelloで先頭に記述した暗号スイートを選択するか否かで、サーバが暗号スイートの優先付けを行っているか否かを判断するものであって、サーバがClientHelloで先頭に記述した暗号スイートを選択しない場合は、サーバが暗号スイートの優先付けを行わないと判断するように構成した。これによると、簡単にサーバが暗号スイートの優先順位付けを行っているか否かを、自動的に調査可能となる。また、本発明の通信装置は、前記調査判断手段は、サーバがサポートする少なくとも2つの暗号スイート内、1つの暗号スイートを選択し、これをClientHelloで先頭に記述暗号スイートとして、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを行い、次に、別の暗号スイートを選択し、これをClientHelloで先頭に記述暗号スイートとして、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを行うことで、サーバが暗号スイートの優先付けを行っているか否かを判断するように構成した。これによると、クライアントは、確実、かつ、迅速に、暗号スイートの優先順位付けを行っているか否かを、自動的に調査可能となる。本発明によれば、通信装置の負荷を他の通信装置に分散することができる。すなわち、通信装置の負荷を低減することができる。以下、本発明の実施の形態を、図面を参照しながら説明する。なお説明を簡単にするため、クライアント、サーバはそれぞれ下記の暗号スイートを保持するものと仮定して説明を行う。なお、暗号スイートとは、例えば、暗号化アルゴリズムと圧縮アルゴリズムであり、鍵交換方式や、暗号方式等を含む。実際の実装においては、搭載されるすなわち、使用可能な暗号スイートはどのようなものであっても構わない。クライアント:TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHAサーバ:TLS_RSA_WITH_3DES_EDE_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHAまた、特別に説明がない場合は、クライアントにおける暗号スイートの優先順位付けは下記の設定になっているものとして説明を行う。これも実際の実装においては、どのような優先順位づけを行ってもよい。なお、この優先順位の情報はサーバまたはクライアントに格納されてもよいし、外部の記憶装置等に格納されてもよい。外部の記憶装置に格納される場合、サーバまたはクライアントがネットワーク等を介して優先順位の情報を取得すればよい。また、CPU等の制御部で、優先順位を都度算出してもよい。1:TLS_RSA_WITH_RC4_128_MD52:TLS_RSA_WITH_RC4_128_SHA3:TLS_RSA_WITH_AES_128_CBC_SHA4:TLS_RSA_WITH_AES_256_CBC_SHA優先順位は1が最も高く、2、3、4という順番で優先順位が低くなるものとする。なお説明を簡単にするために、同じ優先順位の暗号スイートはないようにしているが、実際の実装においては同じ優先順位の暗号スイートが複数存在してもよい。図1は、本発明によるSSL/TLS暗号通信の一例を示すシーケンス図である。図1-S1クライアントは、サーバがサポートする暗号スイートの搭載状況使用可能な暗号スイートの情報を調査することで、クライアントがサポートする暗号スイートの内、以下の暗号スイートをサーバがサポートしないことを知る。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHA図1-S2クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当すれば、次に優先順位の高い暗号スイートを選択する。クライアントの優先順位1、2の暗号スイートは、上記暗号スイートに該当するので、クライアントは下記に記述する、優先順位3の暗号スイートを選択する。TLS_RSA_WITH_AES_128_CBC_SHAなお本図を含めてすべての図で、同じ優先順位の暗号スイートは1つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで1つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。すなわち、本実施の形態において、ここでの選択とはすべて暗号スイート選択する場合も含む。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するClientHelloを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは1つしかないものとする。図1-S3クライアントがこの選択した暗号スイートを指定して、サーバにClientHelloを送信する。4サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにServerHelloを送信する。図示していないが、この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、本発明に従えば、このように、クライアントが主導的に暗号スイートを選択できるメリットがある。パフォーマンスのよい暗号スイートをクライアント主導で選択できるため、特に、脆弱なCPUを搭載しているような組込み機器の場合にこの効果は大きい。なお、ここでは、クライアントが1つのサーバを相手にするケースで説明を行っているが、複数のサーバを相手にするケースでは、クライントがサポートする暗号スイートの優先順位情報はサーバ毎に異なっていてもよい。例えば、銀行や証券など金融系サーバに対しては、セキュリティを重視した暗号スイートの優先順位を高くし、大量にデータを受信するインターネットテレビなどコンテンツ系サーバに対しては、パフォーマンスを重視した暗号スイートの優先順位を高くするなどの設定を行うとよい。図2は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第1例を示すシーケンス図であり、図1のサーバがサポートする暗号スイートの搭載状況を調査する方法の一例を示すシーケンス図でもある。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを1つ指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその暗号スイートを保持していないと判断する。図2-S1クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位1の暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を指定してClientHelloを送信する。図2-S2サーバはTLS_RSA_WITH_RC4_128_MD5をサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5をサポートしていないことを知る。図2-S3そして通信を切断する。通信の切断はサーバ側から行われるのが一般的であるが、サーバが切断しない場合は、クライアント側から通信を切断する。これ以降のすべての図の説明において、アラートhandshake_failure後の通信の切断は同様であり、説明を割愛する。なお、通信の切断は例えば、ネットワーク制御部100で行われる。図2-S4優先順位1の暗号スイートであるTLS_RSA_WITH_RC4_128_MD5をサーバがサポートしていないので、クライアントは次に優先順位2の暗号スイートであるTLS_RSA_WITH_RC4_128_SHAを指定してClientHelloを送信する。図2-S5サーバはTLS_RSA_WITH_RC4_128_SHAをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。図2-そして通信を切断する。なお、ここまでの処理が、結果として、クライアントがサーバの暗号スイートの搭載情報を調査するものになる。つまり、クライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5、及びTLS_RSA_WITH_RC4_128_SHAをサポートしないというサーバがサポートしない暗号スイートの情報を取得したことになる。なお、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。なお、クライアントは、サーバがサポートしない暗号スイートの情報を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、サーバがサポートしない暗号スイートの情報を利用して、直ちに、次のの処理に進むことが可能となる。図2-S7優先順位2の暗号スイートであるTLS_RSA_WITH_RC4_128_SHAをサーバがサポートしていないので、クライアントは次に優先順位3の暗号スイートを選択する。結果として、これが利用する暗号スイートを選択したことになる。図2-そしてTLS_RSA_WITH_AES_128_CBC_SHAを指定してClientHelloを送信する。結果として、これが利用する暗号スイートを伝達したことになる。図2-S5サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。この方法は、優先順位の高い暗号スイートから順に、サーバがその暗号スイートをサポートするか否かを逐次確かめるものである。そして、サーバが指定した暗号スイートをサポートしていれば、通信を切断することなく、そのままSSL/TLS暗号通信を行うものである。なお上記の説明では、説明を簡便にするため、暗号スイートの優先順位順に逐次調査すると説明したが、必ずしも暗号スイートの優先順位順に調査しなければならないものではない。複数のポート番号を利用可能な場合は、複数のチャネルで接続し、同時に複数のClientHelloを送信することが可能である。図2で言えば、サーバの暗号スイートの搭載状況を調べるClientHelloと利用する暗号スイートを伝達するClientHello、つまり1、4、8どれが先に送信されてもよいを同時に送信し、その後、2、5、9を得て、その結果から、TLS_RSA_WITH_AES_128_CBC_SHAを選択することが可能である。そしてこの暗号スイートの通信でそのままSSL/TLS暗号通信を行う。この後の図の説明でも、このような複数ポート番号を利用する方法はあるが、特に必要がなければ、説明を簡単にするため、この説明は割愛する。図3は、本発明の実施の形態における機能ブロックの第1例を示す図であり、図2の機能ブロック図の一例でもある。また図4は、本発明の実施の形態におけるクライアント側のフローチャートの第1例を示す図であり、図3のクライアント1のフローチャートでもある。また、図5は、本発明の実施の形態におけるサーバ側のフローチャートの第1例を示す図であり、本発明の実施の形態におけるサーバ側のフローチャートの第1例を示す図でもある。次にこの図3、図4、図5を用いて説明を行う。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1はクライアントがサポートする暗号スイートの優先順位情報で、利用したい暗号スイートの優先順位づけを行っており、現在、どの優先順位の暗号スイートが選択されているかを現在の優先順位を示すカウンタ700に番号として記憶する仕組みになっている。現在の優先順位を示すカウンタ700の初期値は1である。図4-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在の優先順位を示すカウンタ700から暗号スイートの情報を読み出す。はじめは、現在の優先順位を示すカウンタ700の値が1なので、TLS_RSA_WITH_RC4_128_MD5という情報が読み出される。図4-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_RC4_128_MD5を指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図4-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図4-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図5-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図5-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図5-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5が指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図5-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図5-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのメッセージ受信待ち状態になる図4-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図4-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図4-S6ServerHello受信部500暗号スイート調査手段の一部は、handshake_failureメッセージを受け取ったので、通信を切断する。なおサーバ側が通信を切断しない場合でも、通信の切断を行う。そしてServerHello受信部500暗号スイート調査手段の一部は、現在の優先順位を示すカウンタ700に1を加算して、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。現在の優先順位を示すカウンタ700に1を加算したことで、サーバ2がTLS_RSA_WITH_RC4_128_MD5を搭載しないことの調査結果を得たことになる。図4-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在の優先順位を示すカウンタ700から暗号スイートの情報を読み出す。現在の優先順位を示すカウンタ700の値が2なので、TLS_RSA_WITH_RC4_128_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_RC4_128_MD5の場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_RC4_128_SHAをサポートしていないので、図4-S6ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在の優先順位を示すカウンタ700に1を加算して、再びClientHello生成部400を呼び出す。現在の優先順位を示すカウンタ700に1を加算したことで、サーバ2がTLS_RSA_WITH_RC4_128_SHAを搭載しないことの調査結果を得たことになる。図4-S1次に、ClientHello生成部400は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在の優先順位を示すカウンタ700から暗号スイートの情報を読み出す。現在の優先順位を示すカウンタ700の値が3なので、TLS_RSA_WITH_AES_128_CBC_SHAという情報が読み出される。なお、サーバ2はTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ここでクライアント1は結果的に、利用する暗号スイートを選択したことになる。図4-S2ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。つまり、ここでクライアント1は結果的に、利用する暗号スイートを伝達したことになる。図4-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図4-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図5-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図5-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図5-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図5-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図5-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図5-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図4-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図4-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図4-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、これをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図4-S7SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図4-S8データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図4-S9その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる図5-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図5-S10SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図5-S11データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。機能ブロック図には図示していないが、この後は、サーバ2は作成した共通鍵を使ってクライアント1と暗号通信を行う。なお、暗号通信とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図4-S9クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図4-S10SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。以上の説明により、暗号方式暗号スイート取得部は、ClientHello生成部400暗号スイート調査手段の一部とServerHello受信部500暗号スイート調査手段の一部とに相当する。また、暗号方式取得部が取得した情報に基づいて、サーバ2に送信する暗号スイートを選択するClientHello生成部400は暗号方式選択部でもある。なお、暗号方式取得部または暗号方式選択部が優先順位を算出してもよい。機能ブロック図には図示していないが、この後は、クライアント1は作成した共通鍵を使ってサーバ2と暗号通信を行う。図6は、本発明の実施の形態におけるハードウェア構成の第1例を示す図であり、図3のハードウェア構成図の一例でもある。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、書き換え可能な不揮発性メモリであるHDDハードディスク30、書き換え不可の不揮発性メモリであるROM40とネットワークのデータ送受信を実行するMAC/PHY50で構成されている。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM41とネットワークのデータ送受信を実行するMAC/PHY51で構成されている。また、クライアント1とサーバ2はMAC/PHY50とMAC/PHY51を介してネットワークで接続されている。はじめにクライアント1のハード構成に関して説明を行う。図3に示したクライアント1の各処理部は、CPU10、及びRAM20で実行される。現在の優先順位を示すカウンタ700は、一時的な記憶メモリであるRAM20に配置しているが、書き換え可能なメモリであれば良く、HDDハードディスク30やフラッシュROMなどに配置してもよい。次にクライアントがサポートする暗号スイートの優先順位情報であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてHDDハードディスク30を利用しているが、フラッシュROMなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。クライアントがサポートする暗号スイートの優先順位情報を一時的な記憶メモリであるRAM20に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。なお、クライアントがサポートする暗号スイートの優先順位情報が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるROM40などに配置してもよい。クライアントがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント1の機能ブロック図には、クライアントがサポートする暗号スイートを示していないが、サーバ2の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、クライアントがサポートする暗号スイートをROM40に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、RAM20のような揮発性メモリに配置することも可能である。MAC/PHY50は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次にサーバ2のハード構成に関して説明を行う。図3に示したサーバ2の各処理部は、CPU11、及びRAM21で実行される。サーバがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、サーバがサポートする暗号スイートをROM41に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、RAM21のような揮発性メモリに配置することも可能である。MAC/PHY51は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置200を実現するものである。図7は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第2例を示すシーケンス図であり、図1のサーバがサポートする暗号スイートの搭載状況を調査する方法の別の一例を示すシーケンス図でもある。図2とほぼ同じシーケンスでもある。図2との違いは、図7-S7、図7-S8、図7-S9に示すように、クライアントがサーバに対して、優先順位3の暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信し、サーバがServerHelloを返信した際に、連続してSSL/TLSネゴシエーションを実行せず、一端通信を切断していることである。これにより、サーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズが明確に分離することが可能となる。サーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズを分離すれば、事前に、サーバの暗号スイートの搭載情報を調査することが可能となるので、SSL/TLSネゴシエーションを実行する際に、再度、調査する必要がなくなり、迅速なSSL/TLSネゴシエーションを実現できるようになる。例えば、クライアント装置でユーザが接続するサーバ装置を指定できる場合、その設定時に、サーバ装置の暗号スイートの搭載情報を調査して記憶するようなことが可能となる。なお、この図7の機能ブロック図、フローチャートは、ほぼ図3、図4、図5、図6とほぼ同様なので説明を割愛する。大きな違いは、図4-S5でServerHelloを受信した場合に、図4-S7に進まず、通信を切断するところである。詳細に関しては、次の図8以降で説明を行う。図8は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第3例を示すシーケンス図であり、図1のサーバがサポートする暗号スイートの搭載状況を調査する方法の別の一例を示すシーケンス図でもある。図7とほぼ同じシーケンスである。これもサーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズを明確に分離するものである。図7では、クライアントがサポートする優先順位の高い暗号スイートをサーバがサポートするか否かを調査しているが、図8では、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるもののクライアントがサポートする暗号スイートの優先順位情報が変更になった場合に、再度調査する必要がなくなる。例えば、クライアント装置でユーザがクライアントがサポートする暗号スイートの優先順位情報を変更する場合に都合がよい。また、今までの図の説明では、クライアントがサポートする暗号スイートの優先順位情報は1つしか存在しないケースで説明を行っているが、これが複数ある場合にも、図8の手法が適している。例えば、同じサーバに接続する場合であっても、認証にはより強力な処理の重い暗号スイートを優先し、通常の通信にはパフォーマンスのよい軽い暗号スイートを優先させたい場合がある。このような場合でも、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを一度調査すれば、それぞれの場合で、選択すべき暗号スイートが分かるので手間が省けてよい。なお、ここではクライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で暗号スイートの優先順位付けをする場合に、どのような場合であっても利用されない暗号スイートがある場合は、これを除外するのは合理的である。またどのような場合であっても、優先順位が高い暗号スイートがあり、接続するサーバがこの暗号スイートを必ずサポートする場合は、この暗号スイートより優先順位が高い暗号スイートだけを調査すればよい。次に図8の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを1つ指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその暗号スイートを保持していないと判断する。図8-S1クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位1の暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を指定してClientHelloを送信する。図8-S2サーバはTLS_RSA_WITH_RC4_128_MD5をサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておく。図8-S3そして通信を切断する。図8-S4次にクライアントは、優先順位2の暗号スイートであるTLS_RSA_WITH_RC4_128_SHAを指定してClientHelloを送信する。図8-S5サーバはTLS_RSA_WITH_RC4_128_SHAをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておく。図8-そして通信を切断する。図8-S7次にクライアントは、優先順位3の暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを指定してClientHelloを送信する。図8-S8サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。図8-S9そして通信を切断する。なお、ここでは図8-S9で通信を切断しているが、ServerHelloを返信されてきた場合は、SSL/TLSネゴシエーションを完了してから、通信の切断を行ってもよい。また、SSL/TLSネゴシエーションを完了した場合は、通信を切断せずに、次の図8-S10のClientHelloで再ネゴシエーションを行ってもよい。これ以降の図の説明でも、ServerHelloが返信されてきた場合には、同様の処理が可能である。以降の図ではこの説明は割愛する。但し、SSL/TLSネゴシエーションを完了すると公開鍵暗号処理で時間を要するので、好ましくない。図8-S10次にクライアントは、優先順位4の暗号スイートであるTLS_RSA_WITH_AES_256_CBC_SHAを指定してClientHelloを送信する。図8-S11サーバはTLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。図8-S12そして通信を切断する。以上の手順によって、クライアントは、自らがサポートする暗号スイートの内、TLS_RSA_WITH_RC4_128_MD5とTLS_RSA_WITH_RC4_128_SHAをサーバがサポートしないというサーバがサポートしない暗号スイートの情報を少なくとも記憶する。なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。なお、図2、図7と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。またクライアントは、サーバがサポートしない暗号スイートの情報を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、サーバがサポートしない暗号スイートの情報を利用して、直ちに、次の図8-S13の処理に進むことが可能となる。図8-S13次に、クライアントはサーバと実際にSSL/TLS暗号通信を行うため、利用する暗号スイートの選択を行う。優先順位1と2の暗号スイートをサーバがサポートしていないので、クライアントは優先順位3の暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを利用する暗号スイートとして選択する。図8-S14そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信する。図8-S15サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。なお、サーバの暗号スイートの搭載状況を十分調査し、サーバが、TLS_RSA_WITH_AES_256_CBC_SHAよりTLS_RSA_WITH_AES_128_CBC_SHAを優先しているという情報を得るか、またはサーバはクライアントの優先順位に従う、つまり上位に記載された暗号スイートを選択するという情報を得ている場合には、クライアントはTLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_256_CBC_SHAを指定したClientHelloを送信してもよい。但しこのような方法は時間を要すので好ましくない。この後の図でもこれは同じなので、これ以降の図では、この説明は割愛する。図9は、本発明の実施の形態における機能ブロックの第2例を示す図であり、図8の機能ブロック図の一例でもある。また図10は、本発明の実施の形態におけるクライアント側のフローチャートの第2例を示す図であり、図9のクライアント1のフローチャートでもある。また、図11は、本発明の実施の形態におけるサーバ側のフローチャートの第2例を示す図であり、図9のサーバ2のフローチャートでもある。次にこの図9、図10、図11を用いて説明を行う。なお、この図9、図10、図11は、一部、図7の詳細説明にもなっている。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1はクライアントがサポートする暗号スイートの優先順位情報で、利用したい暗号スイートの優先順位付けを行っており、搭載情報800搭載状況記憶手段または暗号方式格納部で、その各々の暗号スイートに対して、サーバ2でサポートされていない暗号スイートをチェックする仕組みになっている。なお、サポートされている暗号スイートは、サポートされるものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされない暗号スイートのみをチェックするものとする。またここでは、搭載情報800搭載状況記憶手段は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。なおここでは、搭載情報800搭載状況記憶手段で、サーバの暗号スイートの搭載情報を記憶するようにしているが、このような記憶領域を特別に設けずに、クライアントがサポートする暗号スイートの優先順位情報に、サーバの暗号スイートの搭載情報も記憶するとすることも可能である。しかし説明を簡単にするために、これ以降の図でも、搭載情報800搭載状況記憶手段で、サーバの暗号スイートの搭載情報を記憶するものとする。但し、図37、図38では、クライアントがサポートする暗号スイートの優先順位情報に、サーバの暗号スイートの搭載情報を記憶する方法を説明する。また、クライアント1には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す現在のカウンタ710が設けてある。現在のカウンタ710には暗号スイートの優先順位の番号を入力するようになっており、クライアント1は、現在のカウンタ710に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。現在のカウンタ710に0が代入された場合には、クライアント1はサーバの暗号スイートの搭載状況を調査せず、通常のSSL/TLSネゴシエーションを行い、SSL/TLS暗号通信を行うようになっている。なおここでは、現在のカウンタ710の初期値は1とする。図10-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。はじめは、現在のカウンタ710の値が1なので、TLS_RSA_WITH_RC4_128_MD5という情報が読み出される。図10-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_RC4_128_MD5を指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図10-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図10-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5が指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図11-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図11-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのClientHelloメッセージの受信待ち状態になる。図10-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図10-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図10-S6ServerHello受信部500暗号スイート調査手段の一部は、handshake_failureメッセージを受け取ったので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_RC4_128_MD5をサポートしないことを記憶する。図10-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図10-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は2なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図10-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が2なので、TLS_RSA_WITH_RC4_128_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_RC4_128_MD5の場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_RC4_128_SHAをサポートしていないので、図10-S6ServerHello受信部500暗号スイート調査手段の一部は、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_RC4_128_SHAをサポートしないことを記憶する。図10-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図10-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は3なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図10-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が3なので、TLS_RSA_WITH_AES_128_CBC_SHAという情報が読み出される。図10-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図10-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図10-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図10-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図10-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段には何も処理しない。図10-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図10-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は4なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図11-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図10-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が4なので、TLS_RSA_WITH_AES_256_CBC_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_AES_128_CBC_SHAの場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_AES_256_CBC_SHAをサポートするので、搭載情報800搭載状況記憶手段には何も処理しない。図10-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図10-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。図10-S9ここで現在のカウンタ710の値は5なので、つまり、上記等式が成り立つのでServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710に0を設定し、ClientHello生成部400を呼び出すつまりAに進む。図10-S10次に、ClientHello生成部400は、現在のカウンタ710が0の場合、搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。具体的には以下のように選定する。1ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位1のTLS_RSA_WITH_RC4_128_MD5がサポートされていないことを知る。2次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位2のTLS_RSA_WITH_RC4_128_SHAがサポートされていないことを知る。3次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位3のTLS_RSA_WITH_AES_128_CBC_SHAがサポートされていることを知る。そこで、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを選択する。なおここでは、ClientHello生成部400は、搭載情報800搭載状況記憶手段の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、チェックされている1つ前の暗号スイートを選択するとしてもよい。このように、搭載情報800搭載状況記憶手段から暗号スイートの選択方法する方法は様々な手段が存在する。図10-S11ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図10-S12データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図10-S13この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図10-S13クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図10-S14ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710が0の場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図10-S15SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図10-S16データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図10-S17その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる図11-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図11-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図11-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。機能ブロック図には図示していないが、この後は、サーバ2は作成した共通鍵を使ってクライアント1と暗号通信を行う。なお、暗号通信とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図10-S17クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図10-S18SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。機能ブロック図には図示していないが、この後は、クライアント1は作成した共通鍵を使ってサーバ2と暗号通信を行う。図12は、本発明の実施の形態におけるハードウェア構成の第2例を示す図であり、図9のハードウェア構成図の一例でもある。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、書き換え可能な不揮発性メモリであるHDDハードディスク30、書き換え不可の不揮発性メモリであるROM40とネットワークのデータ送受信を実行するMAC/PHY50で構成されている。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM41とネットワークのデータ送受信を実行するMAC/PHY51で構成されている。また、クライアント1とサーバ2はMAC/PHY50とMAC/PHY51を介してネットワークで接続されている。はじめにクライアント1のハード構成に関して説明を行う。図3に示したクライアント1の各処理部は、CPU10、及びRAM20で実行される。現在のカウンタ710、及び搭載情報800搭載状況記憶手段は、一時的な記憶メモリであるRAM20に配置しているが、書き換え可能なメモリであれば良く、HDDハードディスク30やフラッシュROMなどに配置してもよい。次にクライアントがサポートする暗号スイートの優先順位情報であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてHDDハードディスク30を利用しているが、フラッシュROMなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。クライアントがサポートする暗号スイートの優先順位情報を一時的な記憶メモリであるRAM20に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。なお、クライアントがサポートする暗号スイートの優先順位情報が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるROM40などに配置してもよい。クライアントがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント1の機能ブロック図には、クライアントがサポートする暗号スイートを示していないが、サーバ2の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、クライアントがサポートする暗号スイートをROM40に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、RAM20のような揮発性メモリに配置することも可能である。MAC/PHY50は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次にサーバ2のハード構成に関して説明を行う。図3に示したサーバ2の各処理部は、CPU11、及びRAM21で実行される。サーバがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、サーバがサポートする暗号スイートをROM41に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、RAM21のような揮発性メモリに配置することも可能である。MAC/PHY51は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置200を実現するものである。図13は、本発明の実施の形態におけるSSL/TLS暗号通信の第2例を示すシーケンス図である。S13-S1クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、クライアントがサポートする暗号スイートの内、以下の暗号スイートをサーバがサポートすることを知る。TLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHAS13-S2クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当しないものは選択せず、該当するものが出現するまで優先順位を下げる。クライアントの優先順位1、2の暗号スイートは、上記暗号スイートに該当しないので選択されない。クライアントは下記に記述する、優先順位3の暗号スイートを選択する。TLS_RSA_WITH_AES_128_CBC_SHAなお図1で説明したように、同じ優先順位の暗号スイートは1つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで1つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するClientHelloを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは1つしかないものとする。S13-S3クライアントがこの選択した暗号スイートを指定して、サーバにClientHelloを送信する。4サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにServerHelloを送信する。図示していないが、この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図14は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第4例を示すシーケンス図であり、図13のサーバがサポートする暗号スイートの搭載状況を調査する方法の一例を示すシーケンス図でもある。図8とほぼ同じシーケンスである。これもサーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズを明確に分離するものである。図8では、クライアントがサポートする暗号スイート内、サーバがサポートしない暗号スイートを調査しているが、図14では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるもののクライアントがサポートする暗号スイートの優先順位情報が変更になった場合に、再度調査する必要がなくなる。例えば、クライアント装置でユーザがクライアントがサポートする暗号スイートの優先順位情報を変更する場合に都合がよい。また、クライアントがサポートする暗号スイートの優先順位情報が複数ある場合にも、図14の手法が適している。例えば、同じサーバに接続する場合であっても、認証にはより強力な処理の重い暗号スイートを優先し、通常の通信にはパフォーマンスのよい軽い暗号スイートを優先させたい場合がある。このような場合でも、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを一度調査すれば、それぞれの場合で、選択すべき暗号スイートが分かるので手間が省けてよい。なお、ここではクライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で暗号スイートの優先順位付けをする場合に、どのような場合であっても利用されない暗号スイートがある場合は、これを除外するのは合理的である。またどのような場合であっても、優先順位が高い暗号スイートがあり、接続するサーバがこの暗号スイートを必ずサポートする場合は、この暗号スイートより優先順位が高い暗号スイートだけを調査すればよい。次に図14の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを1つ指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその暗号スイートを保持していないと判断する。図14-S1クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位1の暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を指定してClientHelloを送信する。図14-S2サーバはTLS_RSA_WITH_RC4_128_MD5をサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。S13-S3そして通信を切断する。図14-S4次にクライアントは、優先順位2の暗号スイートであるTLS_RSA_WITH_RC4_128_SHAを指定してClientHelloを送信する。図14-S5サーバはTLS_RSA_WITH_RC4_128_SHAをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。S13-S6そして通信を切断する。S13-S7次にクライアントは、優先順位3の暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを指定してClientHelloを送信する。S13-S8サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。S13-S9そして通信を切断する。S13-S10次にクライアントは、優先順位4の暗号スイートであるTLS_RSA_WITH_AES_256_CBC_SHAを指定してClientHelloを送信する。S13-S11サーバはTLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。S13-S12そして通信を切断する。以上の手順によって、クライアントは、自らがサポートする暗号スイートの内、TLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_256_CBC_SHAをサーバがサポートするというサーバとクライアントが共にサポートする暗号スイートの情報を少なくとも記憶する。なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。なお、図2、図7、図8と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。またクライアントは、サーバとクライアントが共にサポートする暗号スイートの情報を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、サーバとクライアントが共にサポートする暗号スイートの情報を利用して、直ちに、次のS13-S13の処理に進むことが可能となる。S13-S13次に、クライアントはサーバと実際にSSL/TLS暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを利用する暗号スイートとして選択する。S13-S14そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信する。S13-S15サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図15は、本発明の実施の形態における機能ブロックの第3例を示す図であり、図14の機能ブロック図の一例でもある。また図16は、本発明の実施の形態におけるクライアント側のフローチャートの第3例を示す図であり、図15のクライアント1のフローチャートでもある。なお、図15のサーバ2のフローチャートは図11と同様である。次にこの図15、図16、図11を用いて説明を行う。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1はクライアントがサポートする暗号スイートの優先順位情報で、利用したい暗号スイートの優先順位付けを行っており、搭載情報800搭載状況記憶手段で、その各々の暗号スイートに対して、サーバ2でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。またここでは、搭載情報800搭載状況記憶手段は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。また、クライアント1には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す現在のカウンタ710が設けてある。現在のカウンタ710には暗号スイートの優先順位の番号を入力するようになっており、クライアント1は、現在のカウンタ710に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。現在のカウンタ710に0が代入された場合には、クライアント1はサーバの暗号スイートの搭載状況を調査せず、通常のSSL/TLSネゴシエーションを行い、SSL/TLS暗号通信を行うようになっている。なおここでは、現在のカウンタ710の初期値は1とする。図16-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。はじめは、現在のカウンタ710の値が1なので、TLS_RSA_WITH_RC4_128_MD5という情報が読み出される。図16-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_RC4_128_MD5を指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図16-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図16-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5が指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図11-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図11-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのClientHelloメッセージの受信待ち状態になる。図16-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図16-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージなので、搭載情報800搭載状況記憶手段には何も処理しない。図16-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図16-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は2なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図16-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が2なので、TLS_RSA_WITH_RC4_128_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_RC4_128_MD5の場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_RC4_128_SHAをサポートしていないので、搭載情報800搭載状況記憶手段には何も処理しない。図16-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図16-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は3なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図16-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が3なので、TLS_RSA_WITH_AES_128_CBC_SHAという情報が読み出される。図16-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図16-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図16-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図16-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図16-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図16-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_128_CBC_SHAをサポートすることを記憶する。図16-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図16-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は4なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図11-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図16-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が4なので、TLS_RSA_WITH_AES_256_CBC_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_AES_128_CBC_SHAの場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_AES_256_CBC_SHAをサポートするので、図10-S6ServerHello受信部500暗号スイート調査手段の一部は、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_256_CBC_SHAをサポートすることを記憶する。図16-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図16-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。図16-S9ここで現在のカウンタ710の値は5なので、つまり、上記等式が成り立つのでServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710に0を設定し、ClientHello生成部400を呼び出すつまりAに進む。図16-S10次に、ClientHello生成部400は、現在のカウンタ710が0の場合、搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。具体的には以下のように選定する。1ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位1のTLS_RSA_WITH_RC4_128_MD5がサポートされていないことを知る。2次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位2のTLS_RSA_WITH_RC4_128_SHAがサポートされていないことを知る。3次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位3のTLS_RSA_WITH_AES_128_CBC_SHAがサポートされていることを知る。そこで、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを選択する。なおここでは、ClientHello生成部400は、搭載情報800搭載状況記憶手段の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、最後にチェックされている暗号スイートを選択するとしてもよい。このように、搭載情報800搭載状況記憶手段から暗号スイートの選択方法する方法は様々な手段が存在する。図16-S11ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図16-S12データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図16-S13この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図16-S13クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図16-S14ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710が0の場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図16-S15SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図16-S16データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図16-S17その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる図11-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図11-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図11-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。機能ブロック図には図示していないが、この後は、サーバ2は作成した共通鍵を使ってクライアント1と暗号通信を行う。なお、暗号通信とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図16-S17クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図16-S18SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。機能ブロック図には図示していないが、この後は、クライアント1は作成した共通鍵を使ってサーバ2と暗号通信を行う。なお、図12は、図9と同様、図15のハードウェア構成図の一例を示している。説明は同じなので割愛する。図17は、本発明の実施の形態におけるSSL/TLS暗号通信の第3例を示すシーケンス図である。図17-S1クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートが以下であることを知る。TLS_RSA_WITH_AES_128_CBC_SHA図17-S2クライアントは、暗号スイートの選択において、上記暗号スイートを選択する。TLS_RSA_WITH_AES_128_CBC_SHAなお図1で説明したように、同じ優先順位の暗号スイートは1つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで1つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するClientHelloを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは1つしかないものとする。図17-S3クライアントがこの選択した暗号スイートを指定して、サーバにClientHelloを送信する。図17-S4サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにServerHelloを送信する。図示していないが、この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図18は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第5例を示すシーケンス図であり、図17のサーバがサポートする暗号スイートの搭載状況を調査する方法の一例を示すシーケンス図である。図8や図14とほぼ同じシーケンスでもある。これもサーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズを明確に分離するものである。図14では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査しているが、図18では、サーバがサポートする暗号スイート内、クライアントで最も優先順位の高い暗号スイートを調査している。すべての暗号スイートを調査しないので、調査時間が短縮できる。次に図18の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを1つ指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその暗号スイートを保持していないと判断する。図18-S1クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位1の暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を指定してClientHelloを送信する。図18-S2サーバはTLS_RSA_WITH_RC4_128_MD5をサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5をサポートしていないことを知る。図18-S3そして通信を切断する。図18-S4次にクライアントは、優先順位2の暗号スイートであるTLS_RSA_WITH_RC4_128_SHAを指定してClientHelloを送信する。図18-S5サーバはTLS_RSA_WITH_RC4_128_SHAをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。図18-S6そして通信を切断する。図18-S7次にクライアントは、優先順位3の暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを指定してClientHelloを送信する。図18-S8サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。そして、この暗号スイートを、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートの情報として記憶しておく。図18-S9そして通信を切断する。なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。例えば、優先順位の低い方から調査する場合は、サーバがアラートhandshake_failureが返送するまで調べ、直前のServerHelloを返した暗号スイートを記憶すればよい。なお、図2、図7、図8、図14と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。またクライアントは、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートの情報を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートの情報を利用して、直ちに、次の図18-S13の処理に進むことが可能となる。図18-S10次に、クライアントはサーバと実際にSSL/TLS暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを利用する暗号スイートとして選択する。図18-S11そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信する。図18-S12サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図19は、本発明の実施の形態における機能ブロックの第4例を示す図の一例であり、図18の機能ブロック図の一例でもある。また図20は、本発明の実施の形態におけるクライアント側のフローチャートの第4例を示す図であり、図19のクライアント1のフローチャートでもある。なお、図19のサーバ2のフローチャートは図11と同様である。次にこの図19、図20、図11を用いて説明を行う。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1はクライアントがサポートする暗号スイートの優先順位情報で、利用したい暗号スイートの優先順位付けを行っており、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートを、搭載情報800搭載状況記憶手段で記憶する仕組みになっている。ここでは、搭載情報800搭載状況記憶手段はクライアントがサポートする各々の暗号スイートに対応する記憶領域であり、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートをチェックする仕組みとして説明しているが、この記憶手段はこれに限られるものではない。搭載情報800搭載状況記憶手段は、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートの番号を、単に記憶するものであっても良く、その記憶手段は様々である。また、クライアント1には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す現在のカウンタ710が設けてある。現在のカウンタ710には暗号スイートの優先順位の番号を入力するようになっており、クライアント1は、現在のカウンタ710に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。現在のカウンタ710に0が代入された場合には、クライアント1はサーバの暗号スイートの搭載状況を調査せず、通常のSSL/TLSネゴシエーションを行い、SSL/TLS暗号通信を行うようになっている。なおここでは、現在のカウンタ710の初期値は1とする。図20-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。はじめは、現在のカウンタ710の値が1なので、TLS_RSA_WITH_RC4_128_MD5という情報が読み出される。図20-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_RC4_128_MD5を指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図20-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図20-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5が指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図11-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図11-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのClientHelloメッセージの受信待ち状態になる。図20-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図20-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージなので、搭載情報800搭載状況記憶手段には何も処理しない。図20-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図20-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は2なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図20-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が2なので、TLS_RSA_WITH_RC4_128_SHAという情報が読み出される。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_RC4_128_MD5の場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_RC4_128_SHAをサポートしていないので、搭載情報800搭載状況記憶手段には何も処理しない。図20-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図20-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、暗号スイートの優先順位の数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAXこの図では41か否かをチェックする。ここで現在のカウンタ710の値は3なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図20-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイートの優先順位情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値が3なので、TLS_RSA_WITH_AES_128_CBC_SHAという情報が読み出される。図20-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図20-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図20-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図20-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図20-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図20-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_128_CBC_SHAをサポートすることを記憶する。なおこれが、サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートということになる。そして、ServerHello受信部500暗号スイート調査手段の一部は通信を切断する。図11-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図20-S9ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710に0を設定し、ClientHello生成部400を呼び出すつまりAに進む。図20-S10次に、ClientHello生成部400は、現在のカウンタ710が0の場合、搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。搭載情報800搭載状況記憶手段にチェックされている暗号スイートは、TLS_RSA_WITH_AES_128_CBC_SHAなので、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを選択する。図20-S11ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図20-S12データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図20-S13この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S11サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図20-S13クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図20-S14ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710が0の場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図20-S15SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図20-S16データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図20-S17その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる図11-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図11-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図11-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。機能ブロック図には図示していないが、この後は、サーバ2は作成した共通鍵を使ってクライアント1と暗号通信を行う。なお、暗号通信とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図20-S17クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図20-S18SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。機能ブロック図には図示していないが、この後は、クライアント1は作成した共通鍵を使ってサーバ2と暗号通信を行う。なお、図12は、図9、図15と同様、図19のハードウェア構成図の一例を示している。説明は同じなので割愛する。図21は、本発明の実施の形態におけるSSL/TLS暗号通信の第4例を示すシーケンス図である。図21-S1クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、サーバが以下の暗号スイートをサーバがサポートすることを知る。TLS_RSA_WITH_3DES_EDE_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図21-S2クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当しないものは選択せず、該当するものが出現するまで優先順位を下げる。クライアントの優先順位1、2の暗号スイートは、上記暗号スイートに該当しないので選択されない。クライアントは下記に記述する、優先順位3の暗号スイートを選択する。TLS_RSA_WITH_AES_128_CBC_SHAなお図1で説明したように、同じ優先順位の暗号スイートは1つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで1つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するClientHelloを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは1つしかないものとする。図21-S3クライアントがこの選択した暗号スイートを指定して、サーバにClientHelloを送信する。図21-S4サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにServerHelloを送信する。図示していないが、この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図22は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第6例を示すシーケンス図であり、図21のサーバがサポートする暗号スイートの搭載状況を調査する方法の一例を示すシーケンス図でもある。図8、図14、図18とほぼ同じシーケンスである。これもサーバの暗号スイートの搭載情報を調査するフェーズと利用する暗号スイートを選択するフェーズを明確に分離するものである。図14では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査しているが、図22では、クライアントがサポートする暗号スイートに関係なく、サーバがサポートする暗号スイートを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるものの、クライアントがサポートする暗号スイートが追加された場合に、再度調査する必要がなくなる。例えば、クライアント装置がソフトウェアダウンロードなどで暗号スイートを追加できる仕組みがある場合に都合がよい。なお、ここではサーバがサポートするすべての暗号スイートを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で将来に渡って絶対に利用しない暗号スイートが明らかである場合は、このような暗号スイートを除外するのは合理的である。例えば、現在、セキュリティ的に弱くて利用できない暗号スイートなどは除外した方が好ましい。なお、これまでの説明で分かるように、サーバがサポートする暗号スイートを調査するのを、逆にサーバがサポートしない暗号スイートを調査することに置き換えてもよい。これは同じことになるので、詳細の説明は割愛する。次に図22の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを1つ指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその暗号スイートを保持していないと判断する。また、クライアントはSSL/TLS仕様で定義されている暗号スイートの情報を保持している。この情報は、基本的にはSSL/TLS仕様で定義されているすべて暗号スイートの情報であるが、先に説明したように、将来に渡ってクライアントが使用しないと分かっている暗号スイートは除去してもよい。図22-S1クライアントはSSL/TLS仕様で定義されている暗号スイートの情報を見て、それに掲載されている暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を指定してClientHelloを送信する。図22-S2サーバはTLS_RSA_WITH_RC4_128_MD5をサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。図22-S3そして通信を切断する。図22-S4次にクライアントは、SSL/TLS仕様で定義されている暗号スイートの情報を見て、それに掲載されている暗号スイートであるTLS_RSA_WITH_RC4_128_SHAを指定してClientHelloを送信する。図22-S5サーバはTLS_RSA_WITH_RC4_128_SHAをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。図22-S6そして通信を切断する。図22-S7次にクライアントは、SSL/TLS仕様で定義されている暗号スイートの情報を見て、それに掲載されている暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを指定してClientHelloを送信する。図22-S8サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ServerHelloを返信する。これによってクライアントは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。図22-S9そして通信を切断する。このようにして、クライアントは、SSL/TLS仕様で定義されている暗号スイートの情報を見て、それに掲載されている暗号スイートをサーバが搭載しているか否かを順々に、調査する。以上の手順によって、クライアントは、サーバが、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_256_CBC_SHAをサーバがサポートするというサーバがサポートする暗号スイートの情報を少なくとも記憶する。なお、ここでは、TLS_RSA_WITH_RC4_128_MD5、TLS_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、という順番で調査しているが、実際はどのような順番で調査しても構わない。なお、図2、図7、図8、図14、図18と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。またクライアントは、サーバがサポートする暗号スイートの情報を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、サーバがサポートする暗号スイートの情報を利用して、直ちに、次の図22-S10の処理に進むことが可能となる。図22-S10次に、クライアントはサーバと実際にSSL/TLS暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを利用する暗号スイートとして選択する。図22-S11そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信する。図22-S12サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。図23は、本発明の実施の形態における機能ブロックの第5例を示す図であり、図22の機能ブロック図の一例でもある。また図24は、本発明の実施の形態におけるクライアント側のフローチャートの第5例を示す図であり、図23のクライアント1のフローチャートである。なお、図23のサーバ2のフローチャートは図11と同様である。次にこの図23、図24、図11を用いて説明を行う。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1はクライアントがサポートする暗号スイートの優先順位情報で、利用したい暗号スイートの優先順位付けを行っており、搭載情報800搭載状況記憶手段で、その各々の暗号スイートに対して、サーバ2でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。また、クライアントはサーバがサポートする暗号スイートを調査するのに、先に説明したSSL/TLS仕様で定義されている暗号スイートの情報を保持している。この情報は、基本的にはSSL/TLS仕様で定義されているすべて暗号スイートの情報であるが、先に説明したように、将来に渡ってクライアントが使用しないと分かっている暗号スイートは除去してもよい。ここでは、搭載情報800搭載状況記憶手段は、SSL/TLS仕様で定義されている暗号スイートの情報に掲載されている各々の暗号スイートが、サポートされているか否かを記憶する仕組みとしている。なお、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。また、クライアント1には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す現在のカウンタ710が設けてある。SSL/TLS仕様で定義されている暗号スイートの情報には、暗号スイートの情報だけでなく、その各々の暗号スイートを調査する順番も定義されており、現在のカウンタ710に、この順番を入力すれば、クライアント1は、その順番の暗号スイートを調査する仕組みとなっている。現在のカウンタ710に0が代入された場合には、クライアント1はサーバの暗号スイートの搭載状況を調査せず、通常のSSL/TLSネゴシエーションを行い、SSL/TLS暗号通信を行うようになっている。なおここでは、現在のカウンタ710の初期値は1とする。図24-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部はSSL/TLS仕様で定義されている暗号スイートの情報と現在のカウンタ710から暗号スイートの情報を読み出す。はじめは、現在のカウンタ710の値が1であるが、これがSSL/TLS仕様で定義されている暗号スイートの情報ではTLS_RSA_WITH_RC4_128_MD5に該当するものとして説明する。図24-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_RC4_128_MD5を指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図24-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図24-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5が指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図11-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図11-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのClientHelloメッセージの受信待ち状態になる。図24-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図24-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージなので、搭載情報800搭載状況記憶手段には何も処理しない。図24-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図24-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、調査する暗号スイートの数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAX1か否かをチェックする。ここで現在のカウンタ710の値は2なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図24-S1次に、ClientHello生成部400暗号スイート調査手段の一部はSSL/TLS仕様で定義されている暗号スイートの情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値は2であるが、これがSSL/TLS仕様で定義されている暗号スイートの情報ではTLS_RSA_WITH_RC4_128_SHAに該当するものとして説明する。この後は、クライアント1、サーバ2共、TLS_RSA_WITH_RC4_128_MD5の場合と同様のフローとなる。サーバ2は、TLS_RSA_WITH_RC4_128_SHAをサポートしていないので、搭載情報800搭載状況記憶手段には何も処理しない。図24-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図24-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、調査する暗号スイートの数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAX1か否かをチェックする。ここで現在のカウンタ710の値は3なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図24-S1次に、ClientHello生成部400暗号スイート調査手段の一部はSSL/TLS仕様で定義されている暗号スイートの情報と現在のカウンタ710から暗号スイートの情報を読み出す。現在のカウンタ710の値は3であるが、これがSSL/TLS仕様で定義されている暗号スイートの情報ではTLS_RSA_WITH_AES_128_CBC_SHAに該当するものとして説明する。図24-S2ClientHello生成部400暗号スイート調査手段の一部は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図24-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図24-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図24-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図16-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図24-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_128_CBC_SHAをサポートすることを記憶する。図24-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、現在のカウンタ710に1を加算する。図24-S8ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710の値が、調査する暗号スイートの数=MAX値を超えているか、つまり、現在のカウンタ710の値=MAX1か否かをチェックする。ここで現在のカウンタ710の値は4なので、ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710には何も処理せずに、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図11-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図24-S1次に、ClientHello生成部400暗号スイート調査手段の一部はSSL/TLS仕様で定義されている暗号スイートの情報と現在のカウンタ710から暗号スイートの情報を読み出す。このような手順でクライアント1はSSL/TLS仕様で定義されている暗号スイートの情報に掲載されている暗号スイートを順々に調査していく。そして、すべての調査を終了した時点で、図24-S9ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710に0を設定し、ClientHello生成部400を呼び出すつまりAに進む。調査を終了した時点で、クライント1は、サーバ2が以下の暗号スイートをサポートしていることを、搭載情報800搭載状況記憶手段にチェックしている。TLS_RSA_WITH_3DES_EDE_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図24-S10次に、ClientHello生成部400は、現在のカウンタ710が0の場合、搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。具体的には以下のように選定する。1ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位1のTLS_RSA_WITH_RC4_128_MD5がサポートされていないことを知る。2次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位2のTLS_RSA_WITH_RC4_128_SHAがサポートされていないことを知る。3次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位3のTLS_RSA_WITH_AES_128_CBC_SHAがサポートされていることを知る。そこで、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを選択する。なおここでは、ClientHello生成部400は、搭載情報800搭載状況記憶手段の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、最後にチェックされている暗号スイートを選択するとしてもよい。このように、搭載情報800搭載状況記憶手段から暗号スイートの選択方法する方法は様々な手段が存在する。図24-S11ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図24-S12データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図24-S13この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図11-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図11-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図11-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図11-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図11-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図11-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図24-S13クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図24-S14ServerHello受信部500暗号スイート調査手段の一部は、現在のカウンタ710が0の場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図24-S15SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図24-S16データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図24-S17その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる図11-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図11-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図11-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。機能ブロック図には図示していないが、この後は、サーバ2は作成した共通鍵を使ってクライアント1と暗号通信を行う。なお、暗号通信とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図24-S17クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図24-S18SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。機能ブロック図には図示していないが、この後は、クライアント1は作成した共通鍵を使ってサーバ2と暗号通信を行う。図25は、本発明の実施の形態におけるハードウェア構成の第3例を示す図であり、図23のハードウェア構成図の一例でもある。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、書き換え可能な不揮発性メモリであるHDDハードディスク30、書き換え不可の不揮発性メモリであるROM40とネットワークのデータ送受信を実行するMAC/PHY50で構成されている。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM41とネットワークのデータ送受信を実行するMAC/PHY51で構成されている。また、クライアント1とサーバ2はMAC/PHY50とMAC/PHY51を介してネットワークで接続されている。はじめにクライアント1のハード構成に関して説明を行う。図23に示したクライアント1の各処理部は、CPU10、及びRAM20で実行される。現在のカウンタ710、及び搭載情報800搭載状況記憶手段は、一時的な記憶メモリであるRAM20に配置しているが、書き換え可能なメモリであれば良く、HDDハードディスク30やフラッシュROMなどに配置してもよい。次にクライアントがサポートする暗号スイートの優先順位情報であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてHDDハードディスク30を利用しているが、フラッシュROMなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。クライアントがサポートする暗号スイートの優先順位情報を一時的な記憶メモリであるRAM20に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。なお、クライアントがサポートする暗号スイートの優先順位情報が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるROM40などに配置してもよい。クライアントがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント1の機能ブロック図には、クライアントがサポートする暗号スイートを示していないが、サーバ2の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、クライアントがサポートする暗号スイートをROM40に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、RAM20のような揮発性メモリに配置することも可能である。次にSSL/TLS仕様で定義されている暗号スイートの情報であるが、基本的には書き換えしないものなので、ROM40など不揮発性メモリに配置するのがよい。しかし、長期間に渡り利用される機器などでは、その間に、セキュリティレベルが下がった暗号スイートを除外したい場合も出てくるので、HDD30やRAM20など、書き換え可能なメモリに配置した方がよいケースもある。MAC/PHY50は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次にサーバ2のハード構成に関して説明を行う。図23に示したサーバ2の各処理部は、CPU11、及びRAM21で実行される。サーバがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、サーバがサポートする暗号スイートをROM41に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、RAM21のような揮発性メモリに配置することも可能である。MAC/PHY51は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置200を実現するものである。図26は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第7例を示すシーケンス図であり、図8で示したサーバがサポートする暗号スイートの搭載状況を調査する方法の別の一例を示すシーケンス図でもある。図26では図8と同様に、クライアントがサポートする暗号スイートの内、サーバがサポートしない暗号スイートを調査している。しかし図26では図8と異なり、サーバがサポートする暗号スイートの調査するのに、暗号スイートを1つ1つ調査することはせず、ClientHelloで複数の暗号スイートを提示する手段を用いている。次に図26の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。図26-S1クライアントは自らがサポートするすべての暗号スイートを指定してClientHelloを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図26-S2暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、ClientHelloで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、ServerHelloを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、ClientHelloで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、ServerHelloを返信する。ここでは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAを選択したものとして説明を行う。サーバは、TLS_RSA_WITH_AES_128_CBC_SHAを指定した、ServerHelloを返信する。クライアントは、このServerHelloにより、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。ここではこれを記憶するように図示していないが、これを記憶しておいてもよい。図26-S3そして通信を切断する。図26-S4次にクライアントは、最初にサーバに指定した暗号スイートから、このTLS_RSA_WITH_AES_128_CBC_SHAを除外した、以下の暗号スイートを指定したClientHelloを送信する。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_256_CBC_SHA図26-S5サーバは、TLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_256_CBC_SHAを指定した、ServerHelloを返信する。クライアントは、このServerHelloにより、サーバがTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていることを知る。ここではこれを記憶するように図示していないが、これを記憶しておいてもよい。図26-S6そして通信を切断する。図26-S7次にクライアントは、2番目にサーバに指定した暗号スイートから、このTLS_RSA_WITH_AES_256_CBC_SHAを除外した、以下の暗号スイートを指定したClientHelloを送信する。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHA図26-S8サーバは、上記暗号スイートをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5、及びTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。クライアントは、この暗号スイートはサポートされていないものとして記憶する。図26-S9そして通信を切断する。後の手順は図8と同様である。この図26と図8を比較して分かるように、サーバの暗号スイートの搭載状況を調査するのに、図26の方が、工数が少ない。これにより迅速な調査が可能となる。この方法によれば、暗号スイートの優先順位を自ら決めるサーバの場合に対して、そのサーバで決められている優先順位を知ることも可能となる。図27は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第8例を示すシーケンス図であり、図18で示したサーバがサポートする暗号スイートの搭載状況を調査する方法の別の一例を示すシーケンス図でもある。図27では図18と同様に、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートを調査している。しかし図27では図18と異なり、サーバがサポートする暗号スイートの調査するのに、暗号スイートを1つ1つ調査することはせず、ClientHelloで複数の暗号スイートを提示する手段を用いている。次に図27の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。図27-S1クライアントは自らがサポートするすべての暗号スイートを指定してClientHelloを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図27-S2暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、ClientHelloで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、ServerHelloを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、ClientHelloで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、ServerHelloを返信する。ここでは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAを選択したものとして説明を行う。サーバは、TLS_RSA_WITH_AES_128_CBC_SHAを指定した、ServerHelloを返信する。クライアントは、このServerHelloにより、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。クライアントは、これは記憶しておく。図27-S3そして通信を切断する。図27-S4次にクライアントは、最初にサーバに指定した暗号スイートから、このTLS_RSA_WITH_AES_128_CBC_SHAと、これより優先順位の低いすべての暗号スイートを除外したClientHelloを送信する。TLS_RSA_WITH_AES_128_CBC_SHAより優先順位の低い暗号スイートは、この例では、TLS_RSA_WITH_AES_256_CBC_SHAの1つだけである。従って、この例では、以下の暗号スイートを指定したClientHelloを送信する。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHA図27-S5サーバは、上記暗号スイートをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5、及びTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。これによって、クライアントは、TLS_RSA_WITH_AES_128_CBC_SHAが、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートであることを知る。図27-S9そして通信を切断する。なお、この例ではTLS_RSA_WITH_AES_128_CBC_SHAの後は、サーバはアラートhandshake_failureを返す例になっているが、例えば、サーバがこの後にTLS_RSA_WITH_RC4_128_SHAでServerHelloを返信してくるケースでは、クライアントは、TLS_RSA_WITH_AES_128_CBC_SHAに代えて、このTLS_RSA_WITH_RC4_128_SHAを記憶することになる。後の手順は図18と同様である。この図27と図18を比較して分かるように、サーバの暗号スイートの搭載状況を調査するのに、図26の方が、工数が少ない。これにより迅速な調査が可能となる。なお、図26、図27の手順は、図8、図18の別の調査方法を例示したものであるが、この手順は、他の図でも応用可能である。図28は、本発明の実施の形態におけるサーバがサポートする暗号スイートの搭載状況を調査する方法の第9例を示すシーケンス図であり、図8で示したサーバがサポートする暗号スイートの搭載状況を調査する方法の別の一例を示すシーケンス図でもある。図28では図8と同様に、クライアントがサポートする暗号スイートの内、サーバがサポートしない暗号スイートを調査している。しかし図28では図8と異なり、サーバがサポートする暗号スイートの調査するのに利用するTCPポート番号と、実際にSSL/TLS暗号通信を行うTCPポート番号が異なる。図28では、クライアント側はアプリアプリケーションとSSLSSL/TLSモジュール/SSLSSL/TLSタスクで構成されている。図28のように、利用するTCPポート番号と、実際にSSL/TLS暗号通信を行うTCPポート番号を分ければ、アプリ側がSSL/TLS暗号通信に指定したTCPポート番号を、サーバがサポートする暗号スイートの調査に利用しなくて済むようになる。アプリ側がSSL/TLS暗号通信に指定したTCPポート番号を、サーバがサポートする暗号スイートの調査に利用すれば、通信切断の度に、アプリ側で再度TCPポート番号を取得しなくてはならなくなり、プログラミングを難しくしてしまう。図28のように、サーバがサポートする暗号スイートの調査に利用するTCPポート番号を、SSLSSL/TLSモジュール/SSLSSL/TLSタスクが別に用意するようにすれば、アプリ側がSSL/TLS暗号通信に指定したTCPポート番号は切断されることがなくなり、アプリ側から見た場合に、プログラミングが非常に簡単になる。なお、サーバがサポートする暗号スイートの調査に利用するTCPポート番号と実際にSSL/TLS暗号通信を行うTCPポート番号が異なることを除けば、手順は図8と同じなので、詳細の説明は割愛する。なお、この手順は他の図でも応用可能である。図29は、本発明の実施の形態におけるSSL/TLS暗号通信の第5例を示すシーケンス図である。図29は図14と同様に、サーバとクライアントが共にサポートする暗号スイートを調査している。但し、その調査方法は図26、図27と同様の手法を利用している。図14と全く同じ手法を利用してもよいが、図26、図27の説明で、機能ブロック図やフローチャートの説明を省いたので、これらの説明を兼ねるため、本質的な問題ではないが、あえてここでは、この手法を利用する。また図29では、実際のSSL/TLS暗号通信で、暗号スイートの切り替えを行っている。この図の本質はここにある。はじめ、認証を行うために、クライアントは自らがサポートする暗号スイートの内、最もセキュリティレベルの高い暗号スイートであるTLS_RSA_WITH_AES_128_CBC_SHAを選択し、利用している。そして、通信用普通の通信データの受け渡しには、クライアントは自らがサポートする暗号スイートの内、最も高速処理可能な暗号スイートであるTLS_RSA_WITH_RC4_128_MD5を選択し、利用している。たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、本発明に従えば、このように目的に応じて、クライアントが主導的に暗号スイートを選択できるメリットがある。特に、脆弱なCPUを搭載しているような組込み機器がクライアントの場合にこの効果は大きい。このような組込み機器の場合でもセキュリティとパフォーマンスを両立することが可能である。次に図29の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したClientHelloを送信している。アラートhandshake_failureが返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。図29-S1クライアントは自らがサポートするすべての暗号スイートを指定してClientHelloを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図29-S2暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、ClientHelloで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、ServerHelloを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、ClientHelloで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、ServerHelloを返信する。ここでは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAを選択したものとして説明を行う。サーバは、TLS_RSA_WITH_AES_128_CBC_SHAを指定した、ServerHelloを返信する。クライアントは、このServerHelloにより、サーバがTLS_RSA_WITH_AES_128_CBC_SHAをサポートしていることを知る。クライアントはこれを記憶する。図29-S3そして通信を切断する。図29-S4次にクライアントは、最初にサーバに指定した暗号スイートから、このTLS_RSA_WITH_AES_128_CBC_SHAを除外した、以下の暗号スイートを指定したClientHelloを送信する。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_256_CBC_SHA図29-S5サーバは、TLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_256_CBC_SHAを指定した、ServerHelloを返信する。クライアントは、このServerHelloにより、サーバがTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていることを知る。クライアントはこれを記憶する。図29S6そして通信を切断する。図29-S7次にクライアントは、2番目にサーバに指定した暗号スイートから、このTLS_RSA_WITH_AES_256_CBC_SHAを除外した、以下の暗号スイートを指定したClientHelloを送信する。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHA図29-S8サーバは、上記暗号スイートをサポートしていないので、アラートhandshake_failureを返す。これによってクライアントは、サーバがTLS_RSA_WITH_RC4_128_MD5、及びTLS_RSA_WITH_RC4_128_SHAをサポートしていないことを知る。クライアントは、この暗号スイートはサポートされていないものとして記憶してもよい。ここまでの手順で、クライアントは、サーバとクライアントが共に、TLS_RSA_WITH_AES_128_CBC_SHA、及びTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていることを知る。図29-S9そして通信を切断する。なお、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。図29-S13次に、クライアントはサーバと実際にSSL/TLS暗号通信を行うため、利用する暗号スイートの選択を行う。図29には図示していないが、図30に図示しているように、クライアントには、認証用認証データの受け渡しと通信用通信データの受け渡しで、それぞれ暗号スイートの優先順位情報が存在する。ここでははじめに、クライアントがサーバに対して認証を行うものとして説明を行う。クライアントは暗号スイートの優先順位情報認証用と、サーバとクライアントが共にサポートする暗号スイートの情報からTLS_RSA_WITH_AES_256_CBC_SHAを利用する暗号スイートとして選択する。図29-S14そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_256_CBC_SHAを指定したClientHelloを送信する。図29-S15サーバはTLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_256_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_256_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。そして、クライアントとサーバ間で認証データの受け渡しが行われる。図29-S16次にクライアントはサーバに対して通信を行うものとする。クライアントは暗号スイートの優先順位情報通信用と、サーバとクライアントが共にサポートする暗号スイートの情報からTLS_RSA_WITH_AES_128_CBC_SHAを利用する暗号スイートとして選択する。図29-S17そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、TLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloを送信する。図29-S18サーバはTLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、TLS_RSA_WITH_AES_128_CBC_SHAを指定してServerHelloを返す。これによってクライアントは、サーバとTLS_RSA_WITH_AES_128_CBC_SHAでSSL/TLSネゴシエーションを行う。この後はSSL/TLSネゴシエーションが正しく実行され、SSL/TLS暗号通信における共通鍵暗号の通信が開始される。そして、クライアントとサーバ間で通信データの受け渡しが行われる。なお、このSSL/TLSネゴシエーションは再ネゴシエーションなので、通常、このSSL/TLSネゴシエーションは先の暗号通信の中で実行される。このケースでは、このSSL/TLSネゴシエーションは、TLS_RSA_WITH_AES_256_CBC_SHAで暗号化されて行われる。このSSL/TLSネゴシエーションが完了した時点から、TLS_RSA_WITH_AES_128_CBC_SHAで暗号化が始まる。図30は、本発明の実施の形態における機能ブロックの第6例を示す図であり、図29の機能ブロック図の一例でもある。また、図31、及び図32は、本発明の実施の形態におけるクライアント側のフローチャートの第6例を示す図であり、図30のクライアント1のフローチャートでもある。図33は、本発明の実施の形態におけるサーバ側のフローチャートの第3例を示す図であり、図30のサーバのフローチャートでもある。次にこの図30、図31、図32、図33を用いて説明を行う。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を開始する。クライアント1では、サポートする暗号スイートを、クライアントがサポートする暗号スイート情報で把握できるようになっている。また、搭載情報800搭載状況記憶手段で、その各々の暗号スイートに対して、サーバ2でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。またここでは、搭載情報800搭載状況記憶手段は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。またクライアント1には、認証用認証データの受け渡しと通信用通信データの受け渡しで、それぞれ暗号スイートの優先順位情報が存在する。このように目的によって利用する暗号スイートの優先順位付けを行っている。また、クライアント1には、サーバ2の暗号スイートの搭載状況を調査するか否かを示すフラグ720が設けてある。このフラグがTRUEの場合のみ、クライアント1はサーバ2の暗号スイートの搭載状況を調査する仕組みとなっている。このフラグ720には最初、TRUEが設定されているものとする。図31-S1はじめに、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイート情報と搭載情報800搭載状況記憶手段から暗号スイートの情報を読み出す。はじめは搭載情報800搭載状況記憶手段にチェックされている暗号スイートはないので、クライアントがサポートする暗号スイート情報に掲載されているすべての暗号スイートが読み出す。このケースでは以下の暗号スイートが読み出される。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA図31-S2ClientHello生成部400暗号スイート調査手段の一部は、上記暗号スイートを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図31-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図31-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図33-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、ClientHelloで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、ServerHelloを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、ClientHelloで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、ServerHelloを返信する。ここでは、サーバがTLS_RSA_WITH_AES_128_CBC_SHAを選択したものとして説明を行う。図33-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図33-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図33-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図33-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図31-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図31-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図31-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_128_CBC_SHAをサポートすることを記憶する。図31-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図33-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図31-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイート情報と搭載情報800搭載状況記憶手段から暗号スイートの情報を読み出す。この時点で搭載情報800搭載状況記憶手段には、TLS_RSA_WITH_AES_128_CBC_SHAがチェックされているいるので、クライアントがサポートする暗号スイート情報に掲載されているすべての暗号スイートの中から、TLS_RSA_WITH_AES_128_CBC_SHAを除外した暗号スイートを読み出す。このケースでは以下の暗号スイートが読み出される。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_256_CBC_SHA図31-S2ClientHello生成部400暗号スイート調査手段の一部は、上記暗号スイートを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図31-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図31-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S5サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図33-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図33-S6サーバ2は、TLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図33-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図33-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図33-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図31-S4クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図31-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。図31-S6ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージでないので、搭載情報800搭載状況記憶手段に、サーバ2がTLS_RSA_WITH_AES_256_CBC_SHAをサポートすることを記憶する。図31-S7次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、ClientHello生成部400暗号スイート調査手段の一部を呼び出すつまりAに進む。図33-S9なお、サーバ2はクライアント1からのメッセージ受信待ち状態であったが、クライアント1から通信を切断されたので、このメッセージ受信待ち状態を抜け、ClientHelloの受信待ち状態になる。また、図11のフローチャートでは分かりやすいのようにS9とS10を分けて図示しているが、実際は、S9のメッセージ受信処理の中で、S10の通信の切断処理が実行される。図31-S1次に、ClientHello生成部400暗号スイート調査手段の一部は自らが保持するクライアントがサポートする暗号スイート情報と搭載情報800搭載状況記憶手段から暗号スイートの情報を読み出す。この時点で搭載情報800搭載状況記憶手段には、TLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_256_CBC_SHAがチェックされているいるので、クライアントがサポートする暗号スイート情報に掲載されているすべての暗号スイートの中から、TLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_128_CBC_SHAを除外した暗号スイートを読み出す。このケースでは以下の暗号スイートが読み出される。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHA図31-S2ClientHello生成部400暗号スイート調査手段の一部は、上記暗号スイートを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図31-S3データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図31-S4この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図33-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図33-S3ClientHelloメッセージには暗号スイートしてTLS_RSA_WITH_RC4_128_MD5、及びTLS_RSA_WITH_RC4_128_SHAが指定されているが、これをサーバ2はサポートしていないので、ClientHello受信部410がhandshake_failureメッセージを生成し、これをデータ送信部210に送る。図33-S4データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、handshake_failureメッセージを送信する。図33-S5その後、ClientHello受信部410は、クライアント1との通信を切断し、サーバ2は再びクライアント1からのClientHelloメッセージの受信待ち状態になる。図31-S4クライアント1のデータ受信部120は、サーバ2が送信したhandshake_failureメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、handshake_failureメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図31-S5ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージか否かをチェックする。ServerHello受信部500暗号スイート調査手段の一部は、受け取ったメッセージがhandshake_failureメッセージなので、搭載情報800搭載状況記憶手段には何も処理しない。図31-S8次に、ServerHello受信部500暗号スイート調査手段の一部は通信を切断し、フラグ720をFALSEに設定する。そしてClientHello生成部400を呼び出すつまりAに進む。図31-S9次に、ClientHello生成部400は、フラグ720がFALSEの場合、暗号スイートの優先順位と情報搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。はじめクライアント1はサーバ2に対して、認証を行うので、暗号スイートの優先順位は認証用を利用する。具体的には以下のように選定する。1ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位1のTLS_RSA_WITH_AES_256_CBC_SHAがサポートされていることを知る。そこで、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_256_CBC_SHAを選択する。図31-S10ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_256_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。図31-S11データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図31-S12この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図33-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図33-S6サーバ2は、TLS_RSA_WITH_AES_256_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図33-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図33-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図33-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図31-S12クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図31-S13ServerHello受信部500暗号スイート調査手段の一部は、フラグ720がFALSEの場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図31-S14SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図31-S15データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図31-S16その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図33-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図33-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。図33-S13その後、サーバ2はクライアント1からのデータ認証データ受信待ち状態になる。図31-S16クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図31-S17SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。図31-S18この後通信部900が、作成した共通鍵を使って、認証データの暗号化を行い、この暗号化された認証データをデータ送信部110に送る。データ送信部110は、この暗号化された認証データを、ネットワーク制御装置100を介して、サーバ2に対して送信する。なお、暗号化とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図33-S13サーバ2のデータ受信部220は、クライアント1が送信した暗号化された認証データを、ネットワーク制御装置200を介して受信する。データ受信部220は、この暗号化された認証データを、通信部910に送る。図33-S14通信部910は、暗号化された認証データを復号化する。データが認証データなので、通信部910は、この認証データを認証部920に送る。なお、認証部920が通信部910に認証結果がOKであったことを通知しない間は、通信部910は、データが通信データであれば、これを破棄し処理しない仕組みになっている。図33-S15認証部920は、認証データを検査する。ここでは認証データが正しい場合で以下説明を行う。認証部920は通信部910に認証結果がOKであることを通知する。なお図33のフローチャートでは、図33-S15の後、スタートに戻っているが、これは実際にはデータ受信待ち状態である。この後、クライアント1からのClientHelloを受信することになるが、そこで実際にはスタートに戻る。図31-S13次に、ClientHello生成部400は、フラグ720がFALSEで、かつ認証データ送信後の場合、暗号スイートの優先順位と情報搭載情報800搭載状況記憶手段より、利用する暗号スイートを選択する。クライアント1はサーバ2に対して、通信データの送信を行うので、暗号スイートの優先順位は通信用を利用する。具体的には以下のように選定する。1ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位1のTLS_RSA_WITH_RC4_128_MD5がサポートされていないことを知る。2次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位2のTLS_RSA_WITH_RC4_128_SHAがサポートされていないことを知る。3次に、ClientHello生成部400は、搭載情報800搭載状況記憶手段より、優先順位3のTLS_RSA_WITH_AES_128_CBC_SHAがサポートされていることを知る。そこで、ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを選択する。図31-S20ClientHello生成部400は、暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを指定したClientHelloメッセージを生成し、これをデータ送信部110に送る。なお、このClientHelloメッセージに始まるSSL/TLSネゴシエーションは再ネゴシエーションなので、通常、このSSL/TLSネゴシエーションは先の暗号通信の中で実行される。このケースでは、このSSL/TLSネゴシエーションは、TLS_RSA_WITH_AES_256_CBC_SHAで暗号化されて行われる。従って実際は、通信部900と通信部910の暗号、復号処理が介在する。説明が煩雑になるので、この処理は省略して以下説明を行う。図31-S21データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図31-S22この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S1サーバ2のデータ受信部220は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientHelloメッセージを、ClientHelloメッセージを処理解釈するClientHello受信部410に送る。図33-S2ClientHello受信部410は、ClientHelloメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。図33-S6サーバ2は、TLS_RSA_WITH_AES_128_CBC_SHAをサポートしているので、ClientHello受信部410は、このClientHelloメッセージを処理し、ServerHello生成部510を呼び出す。図33-S7ServerHello生成部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。図33-S8データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図33-S9その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図31-S22クライアント1のデータ受信部120は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部120は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、handshake_failureメッセージを処理解釈するServerHello受信部500暗号スイート調査手段の一部に送る。図31-S23ServerHello受信部500暗号スイート調査手段の一部は、フラグ720がFALSEの場合、受け取ったメッセージをSSLネゴシエーション処理部600に送るつまりBに進む。なお、SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図31-S24SSLネゴシエーション処理部600は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理し、共通鍵を生成する。そして次に、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部110に送る。図31-S25データ送信部110は、ネットワーク制御装置100を介して、サーバ2に対して、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図31-S26その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図33-S9サーバ2のデータ受信部220は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置200を介して受信する。データ受信部220は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部610に送る。なお、SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージ処理以降のSSL/TLS暗号通信におけるネゴシエーション処理を行う。図33-S11SSLネゴシエーション処理部610は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理し、共通鍵を生成する。そして次に、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。図33-S12データ送信部210は、ネットワーク制御装置200を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。図33-S13その後、サーバ2はクライアント1からのデータ認証データ受信待ち状態になる。図31-S26クライアント1のデータ受信部120は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部220は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理解釈するSSLネゴシエーション処理部600に送る。図31-S27SSLネゴシエーション処理部600は、ChangeCipherSpec/Finishedメッセージを処理する。図31-S18この後通信部900が、作成した共通鍵を使って、通信データの暗号化を行い、この暗号化された通信データをデータ送信部110に送る。データ送信部110は、この暗号化された認証データを、ネットワーク制御装置100を介して、サーバ2に対して送信する。なお、暗号化とはSSL/TLS暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。図33-S13サーバ2のデータ受信部220は、クライアント1が送信した暗号化された通信データを、ネットワーク制御装置200を介して受信する。データ受信部220は、この暗号化された通信データを、通信部910に送る。図33-S16通信部910は、暗号化された通信データを復号化する。通信部910は先に認証部920より認証結果がOKである通知を受けているので、この通信データを処理する。なお、図31のフローチャートの図31-S28、図33のフローチャートの図33-S16の後は、クライアント1とサーバ2の間で、SSL/TLS暗号通信が続く。図34は、本発明の実施の形態におけるハードウェア構成の第4例を示す図であり、図30のハードウェア構成図の一例でもある。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、書き換え可能な不揮発性メモリであるHDDハードディスク30、書き換え不可の不揮発性メモリであるROM40とネットワークのデータ送受信を実行するMAC/PHY50で構成されている。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM41とネットワークのデータ送受信を実行するMAC/PHY51で構成されている。また、クライアント1とサーバ2はMAC/PHY50とMAC/PHY51を介してネットワークで接続されている。はじめにクライアント1のハード構成に関して説明を行う。図34に示したクライアント1の各処理部は、CPU10、及びRAM20で実行される。フラグ720、及び搭載情報800搭載状況記憶手段は、一時的な記憶メモリであるRAM20に配置しているが、書き換え可能なメモリであれば良く、HDDハードディスク30やフラッシュROMなどに配置してもよい。次にクライアントがサポートする暗号スイートの優先順位情報認証用とクライアントがサポートする暗号スイートの優先順位情報通信用とであるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてHDDハードディスク30を利用しているが、フラッシュROMなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。クライアントがサポートする暗号スイートの優先順位情報認証用とクライアントがサポートする暗号スイートの優先順位情報通信用を一時的な記憶メモリであるRAM20に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。なお、クライアントがサポートする暗号スイートの優先順位情報認証用とクライアントがサポートする暗号スイートの優先順位情報通信用が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるROM40などに配置してもよい。クライアントがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント1の機能ブロック図には、クライアントがサポートする暗号スイートを示していないが、サーバ2の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、クライアントがサポートする暗号スイートをROM40に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、RAM20のような揮発性メモリに配置することも可能である。MAC/PHY50は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次にサーバ2のハード構成に関して説明を行う。図3に示したサーバ2の各処理部は、CPU11、及びRAM21で実行される。サーバがサポートする暗号スイートとは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、サーバがサポートする暗号スイートをROM41に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、RAM21のような揮発性メモリに配置することも可能である。MAC/PHY51は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置200を実現するものである。図35は、本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第1例を示す図である。ここでは、サーバはサーバA、サーバB、サーバCと3種類あるものとして説明を行う。クライアントの搭載情報は、暗号スイート毎に、サーバがその暗号スイートをサポートしているか否かを記憶した情報となっている。サーバA、サーバB、サーバCと複数のサーバがある場合は、搭載情報は、暗号スイート毎に、それぞれのサーバがその暗号スイートをサポートしているか否かを記憶する仕組みとなっている。図36は、本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第2例を示す図である。クライアントの搭載情報は、サーバ毎に、サーバがどの暗号スイートをサポートしているか否かを記憶した情報となっている。図37は、本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合のクライアントがサポートする暗号スイートの優先順位情報の実装方法のの第1例を示す図である。ここでは、サーバはサーバAとサーバBと2種類あり、サーバAとサーバBとで、クライアントおける暗号スイートの優先順位付けが異なるものとして説明を行う。また、サーバAと通信する場合は、認証と通信で、クライアントおける暗号スイートの優先順位付けが異なるものとする。クライアントがサポートする暗号スイートの優先順位情報は、暗号スイート毎に、優先順位づけが行われる仕組みとなっている。このケースでは、暗号スイート毎に、サーバAの認証、サーバAの通信、サーバBが相手の場合の優先順位を記憶する仕組みとなっている。図では1が、優先順位が一番高く、以下、2、3と優先順位が下がる。なお、図では優先順位が記述されていない空欄が存在するが、これはそのサーバがその暗号スイートをサポートしていないことを示している。暗号スイートの搭載状況は搭載情報で記憶するが、このようにクライアントがサポートする暗号スイートの優先順位情報に、搭載情報を合体させて記憶させてもよい。図38は、本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合のクライアントがサポートする暗号スイートの優先順位情報の実装方法の第2例を示す図である。ここでも、サーバはサーバAとサーバBと2種類あり、サーバAとサーバBとで、クライアントおける暗号スイートの優先順位付けが異なるものとして説明を行う。また、サーバAと通信する場合は、認証と通信で、クライアントおける暗号スイートの優先順位付けが異なるものとする。クライアントがサポートする暗号スイートの優先順位情報は、サーバ、目的別毎に、優先順位づけが行われる仕組みとなっている。このケースでは、サーバAの認証、サーバAの通信、サーバB毎に、暗号スイートの優先順位を記憶する仕組みとなっている。図では1が、優先順位が一番高く、以下、2、3と優先順位が下がる。なお、図では優先順位が記述されていない空欄が存在するが、これはそのサーバがその暗号スイートをサポートしていないことを示している。暗号スイートの搭載状況は搭載情報で記憶するが、このようにクライアントがサポートする暗号スイートの優先順位情報に、搭載情報を合体させて記憶させてもよい。図39は、本発明の実施の形態におけるクライアントがサポートする暗号スイートの優先順位情報をユーザが変更する方法の第1例を示す図である。ここでは、ユーザはクライアント1の優先順位入力部950優先順位変更手段を使用して暗号スイートの優先順位を変更する仕組みになっている。優先順位入力部950優先順位変更手段は、例えば、モニタ、及びキーボードで構成される装置とすることができる。図39に記載した入力画面例をモニタに表示し、サーバのアドレスIPアドレスなどや各暗号スイートの優先順位の数字ここでは1が一番高い優先順位で、2、3と低くなるものとするを、ユーザにキーボードで入力させることなどで、暗号スイートの優先順位を変更させることが可能である。図40は、本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第1例を示す図である。この図は、ほぼ図9と同じである。違いは図40に調査フラグ730調査判断手段の一部が存在するところである。ここではClientHello生成部400調査判断手段の一部が、サーバにおける暗号スイートの搭載情報を調査する前に、調査フラグ730を見て、これがTRUEになっていたら、サーバにおける暗号スイートの搭載情報を調査する仕組みになっている。この調査フラグ730の値をFALSEにすれば、ClientHello生成部400調査判断手段の一部は、通常のSSL/TLS暗号通信を行う。これにより、クライアント1は必要な場合だけ、サーバ2における暗号スイートの搭載情報を調査するようになるため、無駄な手間を削減できる。多くのサーバ2は暗号スイートの優先順位付けを行っていないので、この機能は重要である。この調査フラグ730調査判断手段の一部は、ユーザ設定としてもよい。その場合、ユーザが接続するサーバ毎に設定できるのが望ましい。あるサーバとSSL/TLS暗号通信を利用してみてパフォーマンスが悪ければ、この調査フラグ730調査判断手段の一部をTRUEに設定することで、パフォーマンスの改善を試みることが可能となる。なおここでは図示していないが、調査フラグ730調査判断手段の一部は、接続するサーバが複数ある場合には、サーバ毎に記憶するとよい。また調査フラグ730調査判断手段の一部は、搭載情報800や、暗号スイートの優先順位情報と共に記憶するものであってもよい。図41は、本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第2例を示す図である。はじめにクライアントは、手順図41-S1~図41-S12に記載しているように、サーバが搭載している少なくとも2つ以上の暗号スイートを探す。そして、図41-S13次にサーバが搭載していると分かった少なくとも2つ以上の暗号スイートを同時に指定したClientHelloをサーバに送信する。この例では、TLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_256_CBC_SHAを同時に指定したClientHelloをサーバに送信している。なお、ここではTLS_RSA_WITH_AES_128_CBC_SHAをTLS_RSA_WITH_AES_256_CBC_SHAより先に記載しているが、その順番は逆でも構わない。図41-S14ここでは、サーバはTLS_RSA_WITH_AES_128_CBC_SHAを指定したServerHelloを返信したとする。もしここで、サーバがTLS_RSA_WITH_AES_256_CBC_SHAを指定したServerHelloを返信すれば、この時点で、サーバが暗号スイートの優先順位付けを行っていることが分かる。サーバがTLS_RSA_WITH_AES_128_CBC_SHAを指定したServerHelloを返信した場合は、この時点では、サーバがクライアントの優先順位を尊重しているのか、または暗号スイートの優先順位付けを行っているのかは判別できない。図41-S15通信を切断する。なおここでは一回一回調査するように記載しているが、図41-S16以下の調査は、違うTCPポート利用するなどして図41-S13と同時に行っても構わない。図41-S16次にまた、サーバが搭載していると分かった少なくとも2つ以上の暗号スイートを同時に指定したClientHelloをサーバに送信する。但し、先ほどとは逆のTLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHAの順で記載した暗号スイートのClientHelloをサーバに送信している。なお、先にTLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHAの順で指定したのであれば、ここでは逆のTLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_256_CBC_SHAの順で指定する。図41-S14ここでは、サーバはTLS_RSA_WITH_AES_128_CBC_SHAを指定したServerHelloを返信したとする。もしここで、サーバがTLS_RSA_WITH_AES_256_CBC_SHAを指定したServerHelloを返信すれば、サーバがクライアントの優先順位を尊重していることが分かる。サーバがこの図のようにTLS_RSA_WITH_AES_128_CBC_SHAを指定したServerHelloを返信すれば、サーバが暗号スイートの優先順位付けを行っているのが分かる。このブロック図はほぼ図40と同じになる。ClientHello生成部調査判断手段の一部とServerHello受信部500調査判断手段の一部との間で、サーバが優先順位付けを行っているか否かを判断できる。なお、判断結果は調査フラグ730調査判断手段の一部に反映してもしなくてもどちらでもよい。調査フラグ730調査判断手段の一部に反映すれば、再度調査する必要がなくなるので手間は省ける。図42は、本発明の実施の形態におけるSSL/TLS暗号通信の第6例を示すシーケンス図である。図2とほぼ同じシーケンスであるが、大きな違いは、利用する暗号スイートを選択する際、複数の暗号スイートを選択しているところにある。これは、サーバの暗号スイートの搭載状況調査で、サーバからhandshakefailureが連続で返信され、クライントが、クライントサーバが共にサポートする暗号スイートを見つけられないままに時間が経過した場合の処理方法を示している。このような場合、図42に示したように、クライアントは許容できる時間が経過した段階で、サーバの暗号スイートの搭載状況調査を終え、それまでの情報によって、暗号スイートを選択すればよい。