JP2023125089A - 情報処理システム、推定方法及びプログラム - Google Patents

Abstract

【課題】電子証明書が暗号化される暗号化通信の場合にも、暗号化された通信を復号化することなく、不審な電子証明書の利用を推定することを課題とする。【解決手段】情報処理システムに、ネットワークに接続された第一の端末と第二の端末との間で行われる暗号化通信に係るデータを取得するデータ取得部２１と、取得された前記データのうち、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、該暗号化メッセージに前記第二の端末に係る不審な電子証明書が含まれていると推定する推定部２５と、を備えた。【選択図】図３

Description

本開示は、不審な電子証明書の利用を検出するための技術に関する。

従来、ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得部と、取得されたデータに係る通信のプロトコルを解析することで、当該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定するプロトコル解析部と、特定されたセッション確立用メッセージから電子証明書を抽出する証明書抽出部と、抽出された電子証明書及び前記セッションにおける通信相手の正当性を検査する検査部と、通信取得部によって取得されたデータのうち、前記セッション確立用メッセージの送受信の前に第一の端末と第二の端末との間で送受信されるデータから、前記通信相手の識別情報を抽出する識別情報抽出部と、を備え、検査部は、識別情報抽出部によって抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性を検査する情報処理装置が提案されている（特許文献１を参照）。

特許第６０８４２７８号

従来、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）等の暗号化通信では、攻撃者による不審な通信を検出するために、通信相手の電子証明書を検査する方法が用いられている。この方法では、例えば、検査の結果、検査対象の電子証明書が自己署名証明書（所謂、オレオレ証明書）等であった場合に、当該電子証明書を利用する通信を不審な通信として検出する。

しかし、近年普及が進んでいる暗号化技術であるＴＬＳ１．３では、ＴＬＳ１．２等の従来の暗号化技術と比較し、セッション確立の際に暗号化されるパラメータ（ハンドシェイクパラメータ）が増加しており、電子証明書についても、他のパラメータと同様に、暗号化されて受け渡しが行われる仕様になっている。このように電子証明書が暗号化される暗号化通信では、一旦暗号化通信を復号化した上で解析を行うことも可能であるが、暗号化通信を復号化するために高価な装置を導入する等、セキュリティ対策にかかる負担が増大してしまうという問題がある。

本開示は、上記した問題に鑑み、電子証明書が暗号化される暗号化通信の場合にも、暗号化された通信を復号化することなく、不審な電子証明書の利用を推定することを課題とする。

本開示の一例は、ネットワークに接続された第一の端末と第二の端末との間で行われる暗号化通信に係るデータを取得するデータ取得手段と、取得された前記データのうち、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、該暗号化メッセージに前記第二の端末に係る不審な電子証明書が含まれていると推定する推定手段と、を備える情報処理システムである。

本開示は、情報処理装置、システム、コンピュータによって実行される方法またはコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

本開示によれば、電子証明書が暗号化される暗号化通信の場合にも、暗号化された通信を復号化することなく、不審な電子証明書の利用を推定することが可能となる。

第一の実施形態に係るシステムの構成を示す概略図である。 第一の実施形態に係るシステムのハードウェア構成を示す図である。 第一の実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。 従来のＴＬＳ１．２におけるハンドシェイクの流れを示すシーケンス図である。 第一の実施形態に係るＴＬＳ１．３におけるハンドシェイクの流れを示すシーケンス図である。 第一の実施形態に係るデータ処理の流れの概要を示すフローチャートである。 第一の実施形態に係る推定処理の流れの概要を示すフローチャートである。 第二の実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。 第二の実施形態に係るデータ処理の流れの概要を示すフローチャートである。 第三の実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。 第三の実施形態に係るデータ処理の流れの概要を示すフローチャートである。 第五の実施形態に係るシステムの構成を示す概略図である。

以下、本開示に係る情報処理システム、情報処理装置、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理システム、情報処理装置、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

［第一の実施形態］
本実施形態では、本開示に係る情報処理システム、情報処理装置、方法及びプログラムを、ネットワークを監視するためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理システム、情報処理装置、方法及びプログラムは、不審な電子証明書であるか否かを推定するための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。なお、本実施形態及び後述する他の実施形態において、「不審な電子証明書」とは、正当な電子証明書であるか疑わしい電子証明書である。

＜システムの構成＞
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステム９は、１又は複数のクライアント端末装置８、クライアント端末装置８に係る通信を監視するためのネットワーク監視装置１、クライアント端末装置８が接続されるネットワークセグメント２、ルータ３、スイッチ４、及び１又は複数のサーバ装置７を備える。ネットワークセグメント２内のクライアント端末装置８は、インターネットや広域ネットワークを介して遠隔地において接続された各種のサーバ装置７と、プロキシ（プロキシサーバ）又はルータ（図１の例では、ルータ３）を介して通信可能である。本実施形態において、ネットワーク監視装置１は、プロキシ又はルータ（図１の例では、ルータ３）と、その上位にあるネットワークセグメント２のスイッチ（スイッチングハブ）、ルータ又はゲートウェイ（図１の例では、スイッチ４）との間に接続されることで、通過するパケットやフレーム等を取得する。図１に示されたシステム構成の場合、ネットワーク監視装置１は、取得したパケットのうち、遮断しなくてもよいパケットについては転送するインラインモードで動作する。

図２は、本実施形態に係るシステムのハードウェア構成を示す図である。ネットワーク監視装置１は、クライアント端末装置８とサーバ装置７との間で行われる通信を監視するための装置である。本実施形態では、ネットワーク監視装置１は、クライアント端末装置８とサーバ装置７の間で送受信されるデータを取得し、取得されたデータを解析することにより、クライアント端末装置８とサーバ装置７との間で行われる暗号化通信に不審な電子証明書（サーバ証明書）が利用されているか否かを推定する。

ネットワーク監視装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、及びＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信ユニット１５、等を備えるコンピュータである。但し、ネットワーク監視装置１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、ネットワーク監視装置１は、単一の筐体からなる装置に限定されない。ネットワーク監視装置１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。なお、ネットワーク監視装置１は、Ｌ２ブリッジ、Ｌ３ルータ、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）装置、スイッチ、又はプロキシに内包されてもよい。

サーバ装置７は、ユーザに対して様々なサービスを提供するためのコンピュータである。サーバ装置７は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット等（図示は省略）を備えるコンピュータである。但し、サーバ装置７の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、サーバ装置７は、単一の筐体からなる装置に限定されない。サーバ装置７は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

クライアント端末装置８は、ユーザによって使用されるコンピュータであり、ユーザは、これらのクライアント端末装置８を介してサーバ装置７によって提供される各種サービスを利用する。クライアント端末装置８は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット、入力装置、出力装置等（図示は省略）を備えるコンピュータである。但し、クライアント端末装置８の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、クライアント端末装置８は、単一の筐体からなる装置に限定されない。クライアント端末装置８は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

図３は、本実施形態に係るネットワーク監視装置（情報処理システム）の機能構成の概略を示す図である。なお、図３においては、ネットワーク監視装置１以外の構成（ルータ３、スイッチ４、サーバ装置７、クライアント端末装置８等）については、図示を省略している。ネットワーク監視装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ネットワーク監視装置１に備えられた各ハードウェアが制御されることで、データ取得部２１、プロトコル判定部２２、セッション再開判定部２３、特定部２４及び推定部２５を備える装置として機能する。なお、本実施形態及び後述する他の実施形態では、ネットワーク監視装置１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。また、ネットワーク監視装置１が備える各機能部は、単一の筐体からなる装置（１の装置）に実装されるものに限定されず、遠隔に及び／又は分散して（例えば、クラウド上に）実装されてもよい。

データ取得部２１は、ネットワークに接続されたサーバ装置７とクライアント端末装置８との間で送受信されるデータを取得する。データ取得部２１は、パケット受信部２１Ａ及びパケット組み立て部２１Ｂを備える。パケット受信部２１Ａは、サーバ装置７とクライアント端末装置８との間で送受信される複数のパケットを、相手先に到達する前に受信する。パケット組み立て部２１Ｂは、パケット受信部２１Ａにより受信されたパケットが、送信時にフラグメント化（分割）されたパケットである場合、当該パケットのヘッダ等を参照することで、分割されたパケットを元のパケットに組み立てる（再構成する）。

例えば、あるパケットが送信時に複数のパケットに分割されると、分割後の各パケットのヘッダには、同一の識別番号や、元のパケットのどの部分に相当するかを示す情報等が含まれるため、パケット組み立て部２１Ｂは、これらの情報を基にパケットの組み立てを行う。なお、パケット組み立て処理は、通信フロー（セッション）毎に行われる。通信フローは、２つのノード間のセッションの開始から終了までの一連の通信を示す単位である。具体的には、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル等の属性が同じものは同一の通信フローとして識別される。そのため、通信フローは、パケットのヘッダを参照することで識別される。以上より、データ取得部２１は、サーバ装置７とクライアント端末装置８との間で送受信されるデータ（ＴＬＳメッセージ）を取得する。

プロトコル判定部２２は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信のプロトコルを判定する。本実施形態では、プロトコル判定部２２は、取得されたデータに係る暗号化通信のプロトコルが、電子証明書を暗号化する暗号化通信プロトコルである、ＴＬＳ１．３であるか否かを判定する。このプロトコルの判定処理は、暗号化通信を確立するために、暗号化通信に先んじて行われるハンドシェイクにおいて送受信されるメッセージ（以下、「ハンドシェイクメッセージ」と称する）を参照することで行われる。

本実施形態では、プロトコル判定部２２は、データ取得部２１により取得されたＴＬＳメッセージのうち、暗号化されていないハンドシェイクメッセージである、ＣｌｉｅｎｔＨｅｌｌｏメッセージ（以下、「ＣｌｉｅｎｔＨｅｌｌｏ」と称する）及びＳｅｒｖｅｒＨｅｌｌｏメッセージ（以下、「ＳｅｒｖｅｒＨｅｌｌｏ」と称する）を参照することで、プロトコルを判定する。具体的には、プロトコル判定部２２は、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏ内の「ｅｘｔｅｎｓｉｏｎ（拡張）」フィールドの「ｓｕｐｐｏｒｔｅｄ＿ｖｅｒｓｉｏｎ」を参照し、夫々の「ｓｕｐｐｏｒｔｅｄ＿ｖｅｒｓｉｏｎ」にＴＬＳ１．３を示す情報が含まれている場合、当該ハンドシェイクメッセージにより確立される暗号化通信のプロトコルを、ＴＬＳ１．３と判定する。

本実施形態では、上述した判定処理により、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信のプロトコルが、所定の暗号化通信プロトコル（ＴＬＳ１．３）と判定された場合に、後述する推定処理（不審な証明書を利用しているかを推定する処理）が行われる。

なお、本実施形態では、ＴＬＳ１．３による暗号化通信であるかを判定する際、上述の通り、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏを参照するが、ＴＬＳ１．３であるか否かを判定可能であれば、この例に限定されない。そのため、例えば、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏの一方のみを参照するようにしてよい。また、本実施形態では、上述の通り、後述する推定処理を行う対象の暗号化プロトコルを、ＴＬＳ１．３とするが、電子証明書を暗号化するプロトコルであれば、他の任意のプロトコルであってもよい。

セッション再開判定部２３は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、フルネゴシエーションにより確立される通信であるか、つまり、セッションを再開することで行われる通信（セッション再開シーケンス）でないかを判定する。例えば、ＴＬＳ１．３の場合は、ＰＳＫ（Ｐｒｅ－Ｓｈａｒｅｄ Ｋｅｙ、事前共有鍵）を用いてセッションを再開することにより、ハンドシェイクを完全に実行しなくても新規の接続（暗号化通信）を行うことが可能である。このＰＳＫを用いてセッションを再開する場合は、ハンドシェイクにおいて電子証明書を送信する必要がないため、この場合には、ハンドシェイクメッセージには電子証明書が含まれない。そのため、本実施形態では、暗号化通信を確立する際にＰＳＫが用いられているか否かを判定し、ＰＳＫが用いられていない場合（セッション再開でない場合）、つまり、フルネゴシエーションが行われる場合（セッションを確立する場合）にのみ、後述する推定処理が行われることとする。

本実施形態では、セッション再開判定部２３は、サーバ装置７とクライアント端末装置８との間で送受信されるハンドシェイクメッセージを参照することで、フルネゴシエーションであるかを判定する。例えば、セッション再開判定部２３は、セッション再開要求に係るメッセージであるＣｌｉｅｎｔＨｅｌｌｏを参照し、ＣｌｉｅｎｔＨｅｌｌｏ内の「ｅｘｔｅｎｓｉｏｎ」フィールドに「ｐｒｅ＿ｓｈａｒｅｄ＿ｋｅｙ」が存在しないか、又は、「ｐｒｅ＿ｓｈａｒｅｄ＿ｋｅｙ」は存在するがそのデータの長さ（Ｌｅｎｇｔｈ）がゼロである場合に、当該ハンドシェイクメッセージにより確立される暗号化通信を、フルネゴシエーションにより確立される通信であると判定する。

特定部２４は、データ取得部２１により取得されたデータから、サーバ装置７とクライアント端末装置８との間で送受信されるハンドシェイクメッセージを特定する。特に、特定部２４は、サーバ装置７の電子証明書を含み得る、サーバ装置７からクライアント端末装置８に送信される暗号化されたハンドシェイクメッセージを特定する。ＴＬＳ１．３の場合、ＳｅｒｖｅｒＨｅｌｌｏ以降のメッセージが全て暗号化されるため、例えば、パケットのヘッダ等により、どのＴＬＳメッセージに電子証明書が含まれるかを特定することが困難である。以下、ＴＬＳ１．２とＴＬＳ１．３とのハンドシェイク（暗号化通信（ＴＬＳコネクション）を開始するためのネゴシエーション）の違いについて説明する。

図４は、従来のＴＬＳ１．２におけるハンドシェイクの流れを示すシーケンス図である。図４では、ＴＬＳ１．２におけるハンドシェイクにおいて、サーバとクライアントとの間で送受信されるＴＬＳメッセージを示す。また、図４では、暗号化されるメッセージについて、その矢印を破線で表す。図４に示す通り、ＴＬＳ１．２では、サーバ証明書（電子証明書）を含む「ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ」メッセージは、暗号化されることなくクライアントに送信される。そのため、電子証明書を含むメッセージか否かは、受信したメッセージ（パケット）のＴＬＳヘッダを参照することで特定することが可能である。具体的には、パケットのペイロード（ＴＬＳペイロード）に格納されているデータの種類を示す、ＴＬＳヘッダ内の「Ｃｏｎｔｅｎｔ Ｔｙｐｅ（Ｈａｎｄｓｈａｋｅ Ｔｙｐｅ）」を参照することにより、電子証明書を含むメッセージか否かを特定することが可能である。

図５は、本実施形態に係るＴＬＳ１．３におけるハンドシェイクの流れを示すシーケンス図である。図５では、ＴＬＳ１．３におけるハンドシェイクにおいて、サーバとクライアントとの間で送受信されるＴＬＳメッセージを示すが、図５に示されていないＴＬＳメッセージが含まれていてもよい。また、図５でも、暗号化されるメッセージについて、その矢印を破線で表す。図５に示す通り、ＴＬＳ１．３では、電子証明書を含む「Ｃｅｒｔｉｆｉｃａｔｅ」メッセージは、暗号化された上でクライアントに送信される。そのため、電子証明書を含むメッセージか否かを、受信したメッセージ（パケット）のＴＬＳヘッダを参照することで特定することは困難である。具体的には、ハンドシェイクに係るメッセージ（Ｃｅｒｔｉｆｉｃａｔｅ）であるにも関わらず、ＴＬＳヘッダ内の「Ｃｏｎｔｅｎｔ Ｔｙｐｅ（Ｈａｎｄｓｈａｋｅ Ｔｙｐｅ）」は、アプリケーションデータ（暗号化データ）であることを示す情報となるため、ＴＬＳヘッダによりサーバ証明書を特定することは困難である。

そのため、本実施形態では、暗号化通信を確立する際のハンドシェイクメッセージにおけるメッセージの順番から、サーバ装置７からクライアント端末装置８に送信される暗号化されたハンドシェイクメッセージを特定する。そして、少なくともこの特定されたハンドシェイクメッセージの中に、電子証明書を含むメッセージ（Ｃｅｒｔｉｆｉｃａｔｅ）が含まれると推定することが可能である。

図５に示すように、ＴＬＳ１．３では、ＳｅｒｖｅｒＨｅｌｌｏの後、サーバから、「Ｃｅｒｔｉｆｉｃａｔｅ」メッセージを含む各種ＴＬＳメッセージ（ハンドシェイクメッセージ）がクライアントに送信されると、クライアントから「Ｆｉｎｉｓｈｅｄ」メッセージが送信される。なお、クライアントから送信されるメッセージは「Ｆｉｎｉｓｈｅｄ」メッセージに限定されず、状況に応じて、「Ａｌａｒｔ」メッセージ等がサーバに送信される。そのため、特定部２４は、ＳｅｒｖｅｒＨｅｌｌｏが送信されてから、クライアントからデータ（ＴＣＰパケット）が送信されるまでの間に送受信された暗号化メッセージを、サーバ装置７からクライアント端末装置８に送信される暗号化されたハンドシェイクメッセージ（電子証明書を含み得るＴＬＳメッセージ）と特定することが可能である。

推定部２５は、不審な電子証明書を含むメッセージを推定する。本実施形態では、メッセージのデータサイズに基づき、不審な電子証明書を含むメッセージを推定する。推定部２５は、例えば、（１）暗号化メッセージのデータサイズに基づき、電子証明書を含むメッセージを推定した上で、（２）推定された当該メッセージのデータサイズに基づき、当該推定されたメッセージに含まれる電子証明書が不審なものであるか（当該メッセージに不審な電子証明書が含まれるか）を推定する。以下、（１）と（２）夫々の推定方法について、説明する。

＜（１）電子証明書を含むメッセージの推定＞
通常、サーバ装置７から送信される暗号化されたハンドシェイクメッセージのうち、Ｃｅｒｔｉｆｉｃａｔｅメッセージ以外のメッセージは、Ｃｅｒｔｉｆｉｃａｔｅメッセージに比べてデータサイズが小さくなる。そのため、特定部２４により特定された暗号化メッセージのうち、所定のデータサイズ（第二の閾値）を超えるメッセージを、電子証明書を含むメッセージと推定することが可能である。例えば、推定部２５は、特定部２４により特定された暗号化メッセージのデータサイズが４００バイトを超える場合に、当該暗号化メッセージを、電子証明書を含むメッセージと推定する。なお、第二の閾値は、４００バイトに限定されず、任意の値に設定可能である。また、暗号化メッセージのデータサイズは、ＴＬＳペイロードの長さを示す、ＴＬＳヘッダ内の「Ｌｅｎｇｔｈ」を参照することで取得することが可能である。

＜（２）電子証明書が不審であるかの推定＞
一般的に、自己署名証明書（オレオレ証明書）等の不正なサーバ証明書は、正当なサーバ証明書と比べて情報が少なく、データサイズが小さくなる傾向がある。この特徴に着目し、上述した第二の閾値を超える暗号化メッセージのうち、所定のデータサイズ（第一の閾値）未満であるメッセージを、不審な電子証明書を含むメッセージであると推定することが可能である。例えば、推定部２５は、特定部２４により特定された暗号化メッセージのデータサイズが、４００バイトを超過し且つ１２００バイト未満である場合に、当該暗号化メッセージを、不審な電子証明書を含むメッセージと推定する。なお、第一の閾値は、１２００バイトに限定されず、任意の値に設定可能である。なお、暗号化メッセージのデータサイズは、上述した通り、ＴＬＳヘッダ内の「Ｌｅｎｇｔｈ」を、参照することで取得することが可能である。

上述の通り、推定部２５は、特定部２４により特定された暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、当該暗号化メッセージに不審な電子証明書が含まれていると推定する。なお、上述した例では、データサイズに係る所定の条件を、暗号化メッセージのデータサイズが所定の範囲内（第二の閾値を超過し且つ第一の閾値未満）の大きさであることとして説明した。但し、データサイズに係る所定の条件は、上述した例に限定されず、例えば、暗号化メッセージのデータサイズが所定の大きさ（例えば、１０００バイト）であること、としてもよい。

＜処理の流れ＞
次に、本実施形態に係るネットワーク監視装置（情報処理システム）によって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の態様に応じて適宜選択されてよい。

図６は、本実施形態に係るデータ処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、ネットワーク監視装置１において、データ取得部２１によりパケットの受信及び組み立てが行われた結果、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏが取得されたこと等を契機として開始される。つまり、本フローチャートに示された処理は、ネゴシエーション毎に実行される。なお、以下の説明（図６の説明）で用いられる「ＣｌｉｅｎｔＨｅｌｌｏ」及び「ＳｅｒｖｅｒＨｅｌｌｏ」は、本フローチャートの開始の契機となったＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏを示す。

ステップＳ１０１では、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信のプロトコルが、ＴＬＳ１．３であるかが判定される。プロトコル判定部２２は、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏ（「ｓｕｐｐｏｒｔｅｄ＿ｖｅｒｓｉｏｎ」）を参照することで、暗号化プロトコルがＴＬＳ１．３であるかを判定する。サーバ装置７とクライアント端末装置８との間で行われる暗号化通信のプロトコルがＴＬＳ１．３と判定された場合（ステップＳ１０１のＹＥＳ）、処理はステップＳ１０３へ進む。一方、ＴＬＳ１．３でないと判定された場合（ステップＳ１０１のＮＯ）、推定処理を行わないため、本フローチャートに示された処理は終了する。

ステップＳ１０３では、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、フルネゴシエーションにより確立される通信であるか（セッション再開に係る通信でないか）が判定される。セッション再開判定部２３は、ＣｌｉｅｎｔＨｅｌｌｏ（「ｐｒｅ＿ｓｈａｒｅｄ＿ｋｅｙ」）を参照することで、フルネゴシエーションが行われるかを判定する。サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、フルネゴシエーションにより確立される通信であると判定された場合（ステップＳ１０３のＹＥＳ）、処理はステップＳ１０６へ進む。一方、フルネゴシエーションが行われないと判定された場合（ステップＳ１０３のＮＯ）、推定処理を行わないため、本フローチャートに示された処理は終了する。なお、ステップＳ１０１及びステップＳ１０３は、順不同である。

ステップＳ１０６では、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏに続くＴＬＳメッセージ（ＴＬＳレコード）に対して推定処理が行われる。推定処理の詳細は、図７を用いて後述する。その後、本フローチャートに示された処理は終了する。

図７は、本実施形態に係る推定処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、図６におけるステップＳ１０３で、フルネゴシエーションと判定されたことを契機として開始される。なお、以下の説明（図７の説明）で用いられる「ＣｌｉｅｎｔＨｅｌｌｏ」及び「ＳｅｒｖｅｒＨｅｌｌｏ」は、図６に示されたフローチャートの開始の契機となったＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏを示す。

ステップＳ２０１では、サーバ装置７とクライアント端末装置８との間で送受信されるデータが取得される。データ取得部２１は、ＳｅｒｖｅｒＨｅｌｌｏに続くパケット（ＴＬＳメッセージ）を取得する。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、取得されたデータが、クライアント端末装置８からサーバ装置７に送信されたデータ（ＴＣＰパケット）であるかが判定される。特定部２４は、ステップＳ２０１で取得されたパケットのＩＰヘッダ等を参照することにより、当該取得されたパケットが、クライアント端末装置８からサーバ装置７へ送信されたパケットであるかを判定する。取得されたパケットが、クライアント端末装置８からサーバ装置７へ送信されたパケットであると判定された場合（ステップＳ２０２のＹＥＳ）、暗号化されたハンドシェイクメッセージについては既に検査済みであるため、本フローチャートに示された処理は終了する。一方、クライアント端末装置８からサーバ装置７へ送信されたパケットでないと判定された場合（ステップＳ２０２のＮＯ）、処理はステップＳ２０３へ進む。

ステップＳ２０３では、取得されたデータが、サーバ装置７からクライアント端末装置８に送信されたアプリケーションデータ（暗号化データ）であるかが判定される。特定部２４は、ステップＳ２０１で取得されたパケットのヘッダ（ＴＬＳヘッダ）を参照し、ヘッダ内の「Ｃｏｎｔｅｎｔ Ｔｙｐｅ」が、アプリケーションデータであることを示す情報である場合に、アプリケーションデータ（暗号化データ）であると判定する。また、特定部２４は、ステップＳ２０１で取得されたパケットのＩＰヘッダ等を参照することにより、当該取得されたパケットが、サーバ装置７からクライアント端末装置８へ送信されたパケットであるかを判定する。

取得されたデータが、サーバ装置７からクライアント端末装置８に送信されたアプリケーションデータであると判定された場合（ステップＳ２０３のＹＥＳ）、処理はステップＳ２０４へ進む。一方、サーバ装置７からクライアント端末装置８に送信されたアプリケーションデータでないと判定された場合（ステップＳ２０３のＮＯ）、ステップＳ２０１に戻り、後続するデータ（パケット）が取得される。なお、ステップＳ２０３でＮＯに進む場合とは、サーバ装置７からクライアント端末装置８に送信される、暗号化されていないハンドシェイクメッセージに該当する場合であり、当該ハンドシェイクメッセージとしては、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージが例示される。

ステップＳ２０４では、アプリケーションデータ（暗号化メッセージ）のデータサイズが第二の閾値を超過しているかが判定される。推定部２５は、例えば、ステップＳ２０１で取得されたパケットのＴＬＳヘッダ内の「Ｌｅｎｇｔｈ」を参照することで、暗号化メッセージのデータサイズが第二の閾値を超過するかを判定する。

暗号化メッセージのデータサイズが第二の閾値を超過すると判定された場合（ステップＳ２０４のＹＥＳ）、当該暗号化メッセージに電子証明書が含まれると推定され、処理はステップＳ２０５へ進む。一方、第二の閾値を超過しないと判定された場合（ステップＳ２０４のＮＯ）、サーバ装置７からクライアント端末装置８に送信されるＣｅｒｔｉｉｃａｔｅメッセージ以外の暗号化メッセージ（ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージやＦｉｎｉｓｈｅｄメッセージ等）と推定され、ステップＳ２０１に戻り、後続するデータ（パケット）が取得される。

ステップＳ２０５では、暗号化メッセージ（アプリケーションデータ）のデータサイズが第一の閾値未満であるかが判定される。推定部２５は、例えば、ステップＳ２０１で取得されたパケットのＴＬＳヘッダ内の「Ｌｅｎｇｔｈ」を参照することで、暗号化メッセージのデータサイズが第一の閾値未満であるかを判定する。暗号化メッセージのデータサイズが第一の閾値未満と判定された場合（ステップＳ２０５のＹＥＳ）、処理はステップＳ２０６へ進む。一方、第一の閾値未満でないと判定された場合（ステップＳ２０５のＮＯ）、正当な電子証明書を含むメッセージであると推定され、本フローチャートに示された処理は終了する。

ステップＳ２０６では、不審な電子証明書が利用されていると推定される。推定部２５は、ステップＳ２０１で取得されたパケット（暗号化メッセージ）を、不審な電子証明書を含むメッセージと推定する。その後、本フローチャートに示された処理は終了する。

上述の通り、本実施形態に係る情報処理システムによれば、暗号化メッセージのデータサイズに基づき不審な証明書か否かを判定することで、ＴＬＳ１．３のように電子証明書が暗号化される暗号化通信の場合にも、暗号化された通信を復号化することなく、不審な電子証明書の利用を推定すること（マルウェア通信を検出すること）が可能となる。そのため、本実施形態に係る情報処理システムによれば、暗号化通信を復号化するために高価な装置を導入する等の負担が生じず、セキュリティ対策を容易に行うことが可能である。

［第二の実施形態］
上記説明した第一の実施形態では、暗号化されたメッセージのデータサイズに基づくことで、当該メッセージに不審な証明書が含まれているかを推定する例について説明した。但し、ハンドシェイク中に送信される電子証明書（サーバ証明書）は、証明書を圧縮する拡張（ＴＬＳ１．３の場合、「ｃｏｍｐｒｅｓｓ＿ｃｅｒｔｉｆｉｃａｔｅ」拡張）を用いることにより、データが圧縮された上で送信される場合がある。この場合、圧縮後の電子証明書は圧縮前よりそのデータサイズが小さくなる。そのため、不審な証明書であるかを推定するために用いられる所定の条件（データサイズ）は、電子証明書を圧縮する場合としない場合とで異なることが望ましい。よって、以下に説明する第二の実施形態では、電子証明書が圧縮される場合を考慮した、不審な証明書の推定方法の例について説明する。なお、第一の実施形態において説明した構成及び処理内容については、同一の符号を付し、説明を省略する。

＜システムの構成＞
本実施形態に係るシステムの構成及びハードウェア構成は、図１及び図２を参照して説明した第一の実施形態と概略同様であるため、説明を省略する。

図８は、本実施形態に係るネットワーク監視装置（情報処理システム）の機能構成の概略を示す図である。なお、図８においては、ネットワーク監視装置１以外の構成については、図示を省略している。ネットワーク監視装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ネットワーク監視装置１に備えられた各ハードウェアが制御されることで、データ取得部２１、プロトコル判定部２２、セッション再開判定部２３、特定部２４及び推定部２５に加え、圧縮判定部２６及び条件管理部２７を備える装置として機能する。以下、圧縮判定部２６及び条件管理部２７について説明するが、その他の機能部については、第一の実施形態と概略同様であるため、説明を省略する。

圧縮判定部２６は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、圧縮された電子証明書を利用する通信（電子証明書を圧縮する拡張（以下、「圧縮拡張」と称する）を利用する通信）であるかを判定する。本実施形態では、圧縮判定部２６は、ＴＬＳ１．３以上で利用可能な圧縮拡張である「ＴＬＳ Ｃｅｒｔｉｆｉｃａｔｅ Ｃｏｍｐｒｅｓｓ」を利用する通信か否かを判定する。具体的には、圧縮判定部２６は、ＣｌｉｅｎｔＨｅｌｌｏを参照し、ＣｌｉｅｎｔＨｅｌｌｏ内の「ｅｘｔｅｎｓｉｏｎ」フィールドに「ｃｏｍｐｒｅｓｓ＿ｃｅｒｔｉｆｉｃａｔｅ」拡張が存在する場合に、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信を、圧縮拡張を利用する通信であると判定する。

条件管理部２７は、不審な証明書か否かを推定するために用いられる所定の条件（閾値）を管理する。本実施形態では、条件管理部２７は、圧縮拡張を利用しない通信の場合に利用される第一の閾値と、圧縮拡張を利用する通信の場合に利用される第三の閾値とを管理する。具体的には、条件管理部２７は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が圧縮拡張を利用する通信であると判定された場合に、第一の閾値よりも小さい値である第三の閾値を設定（算出）する。つまり、圧縮拡張を利用する通信の場合は、不審な証明書か否かの推定を行うための第一の閾値を、より小さい値に変更することになる。例えば、条件管理部２７は、第三の閾値を、第一の閾値（例えば、１２００バイト）を０．８倍した値（例えば、９６０バイト）に設定する。

これより、圧縮拡張を利用しない通信の場合は、不審な証明書の推定処理に第一の閾値（例えば、１２００バイト）が用いられ、圧縮拡張を利用する通信の場合は、不審な証明書の推定処理に第三の閾値（例えば、９６０バイト）が用いられる。なお、所定の条件が、暗号化メッセージのデータサイズが所定の大きさであること、である場合は、例えば、圧縮拡張を利用しない通信の場合は、データサイズが１０００バイトである場合に不審な電子証明書と推定し、圧縮拡張を利用しない通信の場合は、データサイズが８００バイトである場合に不審な電子証明書と推定する。

以上の通り、圧縮拡張を利用する通信でない場合と、圧縮拡張を利用する通信である場合とで、推定処理に利用される所定の条件を異ならせることが可能となる。具体的には、圧縮拡張を利用する通信でない場合に用いられる所定の条件（第一の条件）は、暗号化メッセージのデータサイズが、第一の所定の範囲内（第二の閾値を超過し且つ第一の閾値未満）の大きさであることである。一方、圧縮拡張を利用する通信である場合に用いられる所定の条件（第二の条件）は、例えば、暗号化メッセージのデータサイズが、第二の所定の範囲内（第二の閾値を超過し且つ第三の閾値未満）の大きさであることである。

また、所定の条件が、暗号化メッセージのデータサイズが所定の大きさであること、である場合は、例えば、第一の条件は、データサイズが第一の所定の大きさ（例えば、１０００バイト）であることであり、第二の条件は、データサイズが第一の大きさより小さい第二の所定の大きさ（例えば、８００バイト）である。これより、圧縮された電子証明書に対しても、不審な電子証明書か否かを適切に推定することが可能となる。つまり、電子証明書が圧縮される場合を考慮した、不審な証明書の推定処理を行うことが可能となる。

なお、第三の閾値を第一の閾値に比べてどの程度小さくするか（小さくする割合）は、任意に設定可能であるため、上述した０．８倍に限定されるものではない。また、第一の閾値と同様に、第二の閾値についても、圧縮拡張を利用する通信である場合に、より小さい値に変更した閾値（第四の閾値）が設定されるようにしてもよい。この場合、推定部２５は、当該閾値（第四の閾値）を用いることで、電子証明書を含むメッセージか否かを推定する。更に、本実施形態では、圧縮拡張を利用する通信と判定された場合に、第一の閾値をより小さい値に変更する（第三の閾値を算出する）処理を行うが、第三の閾値が算出されるタイミングはこの例に限定されない。そのため、例えば、事前準備において、第一の閾値と同様に、第三の閾値についても設定されておくようにしてもよい。

＜処理の流れ＞
次に、本実施形態に係るネットワーク監視装置（情報処理システム）によって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の態様に応じて適宜選択されてよい。

図９は、本実施形態に係るデータ処理の流れの概要を示すフローチャートである。図９に示したデータ処理は、図６を参照して第一の実施形態において説明した処理（ステップ）と、ステップＳ１０４及びステップＳ１０５を追加した点が異なる。なお、これらの処理（ステップ）以外の処理については、第一の実施形態（図６）と同一の符号を付し、説明を省略する。以下、本実施形態において追加された処理である、ステップＳ１０４及びステップＳ１０５について説明する。

ステップＳ１０４では、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、圧縮拡張を利用する通信（圧縮された電子証明書を利用する通信）であるか判定される。例えば、圧縮判定部２６は、ＣｌｉｅｎｔＨｅｌｌｏを参照し、ＣｌｉｅｎｔＨｅｌｌｏ内の「ｅｘｔｅｎｓｉｏｎ」フィールドに「ｃｏｍｐｒｅｓｓ＿ｃｅｒｔｉｆｉｃａｔｅ」拡張が存在する場合に、圧縮拡張を利用する通信であると判定する。圧縮拡張が利用されると判定された場合（ステップＳ１０４のＹＥＳ）、処理はステップＳ１０５へ進む。一方、圧縮拡張が利用されないと判定された場合（ステップＳ１０４のＮＯ）、処理はステップＳ１０６へ進む。

ステップＳ１０５では、閾値（第一の閾値）が変更される。条件管理部２７は、ステップＳ１０６（図７のステップＳ２０５）で用いられる第一の閾値を、より小さい値に変更する（第三の閾値の設定）。その後、処理はステップＳ１０６へ進む。ステップＳ１０５の処理により、圧縮拡張を利用する通信の場合（ステップＳ１０４のＹＥＳから、ステップＳ１０６に進む場合）は、ステップＳ２０５の処理において、第三の閾値（第一の閾値より小さい値）が用いられる。一方、圧縮拡張を利用しない通信の場合（ステップＳ１０４のＮＯから、ステップＳ１０６に進む場合）は、ステップＳ２０５の処理において、第一の閾値が用いられることとなる。なお、ステップＳ１０１、ステップＳ１０３、並びにステップＳ１０４及びステップＳ１０５は、順不同である。

なお、本実施形態に係る推定処理については、第一の実施形態において図７を参照して説明した内容と概略同様であるため、説明を省略する。但し、上述した通り、本実施形態では、ステップＳ２０５において用いられる第一の閾値が、圧縮拡張を利用する通信と圧縮拡張を利用しない通信とで異なる点が、第一の実施形態とは異なる。

［第三の実施形態］
上記説明した第一の実施形態では、暗号化されたメッセージのデータサイズに基づくことで、当該メッセージに不審な証明書が含まれているかを推定する例について説明した。具体的には、第一の実施形態では、暗号化メッセージのデータサイズが所定の範囲内（第二の閾値を超過し、且つ、第一の閾値未満）の大きさである場合に、当該暗号化メッセージに不審な電子証明書が含まれていると推定する例について示した。

但し、この所定の範囲内の大きさ（長さ）を有する暗号化メッセージであっても、正当な電子証明書である可能性がある。このように、不審な証明書と推定される所定の条件を満たすようなメッセージ（電子証明書）であっても、正当な電子証明書については、不審な証明書と推定されないことが望ましい。よって、以下に説明する第三の実施形態では、正当な証明書に関する情報を予めホワイトリストに登録しておくことで、正当な証明書を検査対象から除外した上で、不審な証明書を推定する方法の例について説明する。なお、第一の実施形態において説明した構成及び処理内容については、同一の符号を付し、説明を省略する。

＜システムの構成＞
本実施形態に係るシステムの構成及びハードウェア構成は、図１及び図２を参照して説明した第一の実施形態と概略同様であるため、説明を省略する。

図１０は、本実施形態に係るネットワーク監視装置（情報処理システム）の機能構成の概略を示す図である。なお、図１０においては、ネットワーク監視装置１以外の構成については、図示を省略している。ネットワーク監視装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ネットワーク監視装置１に備えられた各ハードウェアが制御されることで、データ取得部２１、プロトコル判定部２２、セッション再開判定部２３、特定部２４及び推定部２５に加え、正当条件保持部２８及び正当判定部２９を備える装置として機能する。以下、正当条件保持部２８及び正当判定部２９について説明するが、その他の機能部については、第一の実施形態と概略同様であるため、説明を省略する。

正当条件保持部２８は、正当な電子証明書を利用する通信を識別するための条件（不審な電子証明書か否かを推定する対象（検査対象）から除外する条件）を保持する。ユーザは、予め、正当な電子証明書が利用される通信を特定することが可能である場合、当該通信を識別可能とするため、ホワイトリストに、当該通信を識別するための条件（通信情報）を登録する。そして、ホワイトリストに登録された条件に合致する通信においては、不審な電子証明書かを推定する処理が行われないようにすることが可能である。正当条件保持部２８は、このようにユーザにより登録された、正当な電子証明書を利用する通信を識別するための条件（以下、「正当条件」と称する）を保持する。但し、正当条件は、予めユーザにより登録される場合に限定されず、その他の方法により登録されるようにしてもよい。以下、保持される正当条件の例について説明する。

正当条件保持部２８は、例えば、正当条件として、以下に示した通信情報（１）～（３）のうち少なくとも一の情報に係る条件を保持する。以下、各条件（通信情報）について夫々説明する。
（１）ＳＮＩ（ドメイン名）
（２）ＩＰアドレス（ＩＰｖ４／ＩＰｖ６アドレス）
（３）ＴＬＳフィンガープリント（Ｆｉｎｇｅｒｐｒｉｎｔ）

＜（１）ＳＮＩ＞
ＳＮＩ（Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）は、１つのＩＰアドレスで複数のドメイン名（ホスト名）のサーバ証明書を運用可能とするＴＬＳの拡張機能である。具体的には、ハンドシェイク時に、クライアントがアクセスしたいドメイン名を伝えることで、サーバ側がＩＰアドレス毎ではなくドメイン名によって異なる電子証明書を使い分けることが可能となる。よって、本実施形態では、正当な証明書を利用するドメイン名をホワイトリストに登録しておくことで、当該ドメイン名による電子証明書を含むメッセージを、検査対象から除外することが可能となる。この場合の正当条件は、「クライアントによりアクセスされるドメイン名が、登録（保持）されているドメイン名に合致すること」である。

＜（２）ＩＰアドレス＞
正当な証明書を利用するサーバ装置７を予め特定することが可能である場合、当該サーバ装置７のＩＰアドレス（ＩＰｖ４アドレスやＩＰｖ６アドレス等）をホワイトリストに登録しておくことで、当該ＩＰアドレスから送信されるメッセージを、検査対象から除外することが可能となる。この場合の正当条件は、「メッセージの宛先又は送信元のＩＰアドレスが、登録（保持）されているＩＰアドレスに合致すること」である。

＜（３）ＴＬＳフィンガープリント＞
フィンガープリンティング（Ｆｉｎｇｅｒｐｒｉｎｔｉｎｇ）は、通信の特徴から、人の指紋のようにデバイス（端末）を識別する技術であり、ＴＬＳフィンガープリンティングは、サーバにアクセスしてきたクライアントを、受信パケット（ＣｌｉｅｎｔＨｅｌｌｏ）の特徴を用いることで識別する（ブラウザの種類まで識別可能）技術である。予め、正常な通信（正当な証明書が利用される通信）に係る特徴をフィンガープリント（ＣｌｉｅｎｔＨｅｌｌｏから得られる情報）により取得可能である場合、当該フィンガープリントの情報をホワイトリストに登録しておくことで、正常な通信に係るメッセージを、検査対象から除外することが可能となる。この場合の正当条件は、「受信されたＣｌｉｅｎｔＨｅｌｌｏ内の情報（フィンガープリント）が、登録（保持）されているフィンガープリントに合致すること」である。

例えば、主要ブラウザによるＳＳＬ／ＴＬＳ通信と、マルウェアによるＳＳＬ／ＴＬＳ通信とでは、ＣｌｉｅｎｔＨｅｌｌｏで利用される拡張（ｅｘｔｅｎｓｉｏｎ）に異なる点がある。具体的には、主要ブラウザでは様々な拡張が用いられるのに対し、マルウェアでは、特定用途である等の理由で、限られた拡張のみが用いられる。そのため、主要ブラウザによる通信の特徴として、主要ブラウザによる通信の場合にＣｌｉｅｎｔＨｅｌｌｏで利用される拡張の数や種類等をホワイトリストに登録しておくことで、主要ブラウザによる通信に係るメッセージを、検査対象から除外することが可能となる。

なお、正当条件保持部２８は、上記説明した通信情報（１）～（３）のうち少なくとも何れか一つの通信情報（例えば、（１）のみ）を利用した条件を保持すればよい。また、（１）～（３）は、正当条件に用いられる通信情報の一例であり、（１）～（３）以外の通信情報が正当条件に用いられてよい。

正当判定部２９は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、正当な電子証明書を利用する通信であるかを判定する。具体的には、データ取得部２１により取得されたデータが、正当条件保持部２８により保持されている正当条件を満たすか（正当条件に合致するか）を判定し、正当条件を満たす場合に、正当な電子証明書を利用する通信であると判定する。

例えば、正当条件が上記（１）の通信情報を利用した条件である場合、正当判定部２９は、ＣｌｉｅｎｔＨｅｌｌｏを参照し、ＣｌｉｅｎｔＨｅｌｌｏ内の「ｓｅｒｖｅｒ＿ｎａｍｅ」に格納されたドメイン名が、ホワイトリストに登録されたドメイン名の何れかに合致する場合に、正当な電子証明書を利用する通信であると判定する。

また、例えば、正当条件が上記（２）の通信情報を利用した条件である場合、正当判定部２９は、ＣｌｉｅｎｔＨｅｌｌｏを含むパケットのヘッダ内にある宛先ＩＰアドレス及び／又はＳｅｒｖｅｒＨｅｌｌｏを含むパケットのヘッダ内にある送信元ＩＰアドレスを参照することで、正当な電子証明書を利用する通信であるかを判定する。例えば、正当判定部２９は、ＣｌｉｅｎｔＨｅｌｌｏに該当するパケットのヘッダ内の宛先ＩＰアドレスが、ホワイトリストに登録されたＩＰアドレスの何れかに合致する場合に、正当な電子証明書を利用する通信であると判定する。

また、例えば、正当条件が上記（３）の通信情報を利用した条件である場合、正当判定部２９は、ＣｌｉｅｎｔＨｅｌｌｏを参照し、ＣｌｉｅｎｔＨｅｌｌｏ内の「ｅｘｔｅｎｓｉｏｎ」フィールドに含まれる拡張の数やパラメータ値等が、ホワイトリストに登録された拡張の数やパラメータ値に合致する場合に、正当な電子証明書を利用する通信であると判定する。

本実施形態では、上述した判定処理により、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、予めホワイトリストに登録されている正当な電子証明書を利用する通信でないと判定された場合に、不審な証明書を利用しているかを推定する処理が行われる。

これより、正当な電子証明書が利用されると予め特定されている通信に係るデータを検査対象から除外した上で、不審な証明書を推定する処理を行うことが可能である。つまり、不審な証明書と推定される条件（所定の条件）を満たすようなメッセージ（電子証明書）であっても、正当な電子証明書については不審な証明書と推定されないようにすることが可能である。

＜処理の流れ＞
次に、本実施形態に係るネットワーク監視装置（情報処理システム）によって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の態様に応じて適宜選択されてよい。

図１１は、本実施形態に係るデータ処理の流れの概要を示すフローチャートである。図１１に示したデータ処理は、図６を参照して第一の実施形態において説明した処理（ステップ）と、ステップＳ１０２を追加した点が異なる。なお、ステップＳ１０２以外の処理については、第一の実施形態（図６）と同一の符号を付し、説明を省略する。以下、本実施形態において追加された処理である、ステップＳ１０２について説明する。

ステップＳ１０２では、ホワイトリストの条件に合致するかが判定される。正当判定部２９は、サーバ装置７とクライアント端末装置８との間で行われる暗号化通信が、予め登録した、正当な電子証明書を利用する通信であるかを、ホワイトリストの条件（正当条件）に合致するか否かで判定する。ホワイトリストの条件に合致する（予め登録した正当な電子証明書利用である）場合（ステップＳ１０２のＹＥＳ）、推定処理を行う必要はないため、本フローチャートに示された処理は終了する。一方、ホワイトリストの条件に合致しない（予め登録した正当な電子証明書利用でない）場合（ステップＳ１０２のＮＯ）、処理はステップＳ１０３へ進む。なお、ステップＳ１０１～ステップＳ１０３は、順不同である。

以上より、予め正当な電子証明書と判断されている電子証明書を利用する通信については、推定処理が行われないようにすることが可能となる。なお、本実施形態に係る推定処理については、第一の実施形態において図７を参照して説明した内容と概略同様であるため、説明を省略する。

［第四の実施形態］
本実施形態は、上記説明した第二の実施形態及び第三の実施形態を組み合わせた実施形態である。本実施形態に係るシステムの構成及びハードウェア構成は、図１及び図２を参照して説明した第一の実施形態と概略同様であるため、説明を省略する。また、本実施形態に係るネットワーク監視装置の機能構成は、図８の機能構成に、図１０で示した正当条件保持部２８及び正当判定部２９を追加した構成であり、各機能部の概要は、第一の実施形態～第三の実施形態で説明した機能部の概要と概略同様であるため、説明を省略する。また、本実施形態に係るデータ処理では、第二の実施形態において図９を参照して説明した処理と、第三の実施形態において図１１を参照して説明した処理が組み合わされた処理となる。具体的には、本実施形態に係るデータ処理では、ステップＳ１０１～ステップＳ１０６の処理（６つの処理）が実行される。夫々の処理（ステップ）については、第一の実施形態～第三の実施形態において説明した内容と概略同様であるため、説明を省略する。

［第五の実施形態］
上記実施形態では、ネットワーク監視装置１が、ルータ３とその上位にあるスイッチ４との間に接続されることで、クライアント端末装置８によって送受信されるパケットやフレーム等を取得し、遮断しなくてもよいパケットについては転送するインラインモードで動作する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその他のネットワーク構成が採用されてもよい。以下、他のネットワーク構成の一例について説明する。

図１２は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステム９では、上記実施形態と同様に、ネットワークセグメント２内のクライアント端末装置８は、インターネットや広域ネットワークを介して遠隔地において接続された各種のサーバ装置７と、ルータ３を介して通信可能である。そして、本バリエーションでは、ネットワーク監視装置１は、ネットワークセグメント２のスイッチ、ルータ又はゲートウェイ（図１２の例では、スイッチ４）のモニタリングポート（ミラーポート）に接続されることで、クライアント端末装置８によって送受信されるパケットやフレーム等を取得する。この場合、ネットワーク監視装置１は、取得したパケットを転送しないパッシブモードで動作する。

また、例えば、ネットワーク監視装置１は、モニタリングポート（ミラーポート）に接続されず、単にネットワークセグメント２に接続されている場合であっても、ネットワークセグメント２を流れるフレームを、自身のＭＡＣアドレス宛でないものも含めて全て取得することで、クライアント端末装置８によって送受信されるパケットやフレーム等を取得することが出来る。この場合も、ネットワーク監視装置１は、パッシブモードで動作する。また、上記実施形態と同様に、ネットワーク監視装置１は、Ｌ２ブリッジ、Ｌ３ルータ、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）装置、スイッチ、又はプロキシ等に内包されてもよい。

１ ネットワーク監視装置
７ サーバ装置
８ クライアント端末装置
９ システム

Claims (16)

1. ネットワークに接続された第一の端末と第二の端末との間で行われる暗号化通信に係るデータを取得するデータ取得手段と、
   取得された前記データのうち、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、該暗号化メッセージに前記第二の端末に係る不審な電子証明書が含まれていると推定する推定手段と、
   を備える情報処理システム。
2. 前記所定の条件とは、前記暗号化メッセージのデータサイズが所定の範囲内の大きさであることである、
   請求項１に記載の情報処理システム。
3. 前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージを特定する特定手段を更に備え、
   前記特定手段は、取得された前記データのうち、前記暗号化通信を確立するために前記第一の端末と前記第二の端末との間で送受信される非暗号化メッセージが送信されてから、前記第一の端末から前記第二の端末にデータが送信されるまでの間に送受信された暗号化メッセージを、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージと特定する、
   請求項１又は２に記載の情報処理システム。
4. 前記暗号化通信が、所定の暗号化通信プロトコルによる暗号化通信であるかを判定するプロトコル判定手段を更に備え、
   前記暗号化通信のプロトコルが前記所定の暗号化通信プロトコルであると判定された場合に、前記推定手段による処理が実行される、
   請求項１～３の何れか一項に記載の情報処理システム。
5. 前記所定の暗号化通信プロトコルは、ＴＬＳ１．３である、
   請求項４に記載の情報処理システム。
6. 前記プロトコル判定手段は、取得された前記データに含まれる、前記暗号化通信を確立するために前記第一の端末と前記第二の端末との間で送受信される非暗号化メッセージのうち、少なくとも一のメッセージを参照することで、前記暗号化通信のプロトコルが前記所定の暗号化通信プロトコルであるかを判定する、
   請求項４又は５に記載の情報処理システム。
7. 前記暗号化通信が、セッションを再開することで行われる通信であるか否かを判定するセッション再開判定手段を更に備え、
   前記暗号化通信が前記セッションを再開することで行われる通信でないと判定された場合に、前記推定手段による処理が実行される、
   請求項１～６の何れか一項に記載の情報処理システム。
8. 前記セッション再開判定手段は、取得された前記データに含まれる、前記暗号化通信を確立するために前記第一の端末と前記第二の端末との間で送受信される非暗号化メッセージのうち、セッション再開要求に係るメッセージを参照することで、前記暗号化通信が前記セッションを再開することで行われる通信であるか否かを判定する、
   請求項７に記載の情報処理システム。
9. 前記暗号化通信が、圧縮された電子証明書を利用する通信であるかを判定する圧縮判定手段を更に備え、
   前記推定手段は、
   前記暗号化通信が、前記圧縮された電子証明書を利用する通信でないと判定された場合、前記データサイズに係る所定の条件として、第一の条件を使用し、
   前記暗号化通信が、前記圧縮された電子証明書を利用する通信であると判定された場合、前記データサイズに係る所定の条件として、前記第一の条件とは異なる第二の条件を使用する、
   請求項１～８の何れか一項に記載の情報処理システム。
10. 前記第一の条件は、前記暗号化メッセージのデータサイズが、第一の所定の範囲内の大きさであることであり、
    前記第二の条件は、前記暗号化メッセージのデータサイズが、前記第一の所定の範囲とは異なる第二の所定の範囲内の大きさであることである、
    請求項９に記載の情報処理システム。
11. 前記第二の所定の範囲を定める上限値は、前記第一の所定の範囲を定める上限値よりも小さい値である、
    請求項１０に記載の情報処理システム。
12. 正当な電子証明書を利用する通信を識別するための条件を保持する正当条件保持手段と、
    前記暗号化通信が、前記正当な電子証明書を利用する通信であるかを、保持された前記条件に基づき判定する正当判定手段と、を更に備え、
    前記暗号化通信が、前記正当な電子証明書を利用する通信でないと判定された場合に、前記推定手段による処理が実行される、
    請求項１～１１の何れか一項に記載の情報処理システム。
13. 前記暗号化通信を確立するために前記第一の端末と前記第二の端末との間で送受信される非暗号化メッセージは、ＣｌｉｅｎｔＨｅｌｌｏメッセージ及びＳｅｒｖｅｒＨｅｌｌｏメッセージである、
    請求項３、６、及び８の何れか一項に記載の情報処理システム。
14. 前記データ取得手段は、前記第一の端末と前記第二の端末との間で行われる前記暗号化通信に係るデータを、相手先に到達する前に取得する、
    請求項１～１３の何れか一項に記載の情報処理システム。
15. コンピュータが、
    ネットワークに接続された第一の端末と第二の端末との間で行われる暗号化通信に係るデータを取得するデータ取得ステップと、
    取得された前記データのうち、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、該暗号化メッセージに前記第二の端末に係る不審な電子証明書が含まれていると推定する推定ステップと、を実行する、
    推定方法。
16. コンピュータを、
    ネットワークに接続された第一の端末と第二の端末との間で行われる暗号化通信に係るデータを取得するデータ取得手段と、
    取得された前記データのうち、前記暗号化通信を確立するために前記第二の端末から前記第一の端末に送信される暗号化メッセージが、データサイズに係る所定の条件を満たす場合に、該暗号化メッセージに前記第二の端末に係る不審な電子証明書が含まれていると推定する推定手段と、として機能させる、
    プログラム。

Images