SSL／TLS（Part.3）：不正アクセスを防止するSSL/TLS（4）（1/4 ページ）

　これまで、暗号化アルゴリズムなどの前提知識はさほど必要としない部分を中心に説明してきたが、ここより先には、少しずつ暗号アルゴリズムに絡んだ話が増えてくる。ただ、RFCなどでは数式で表現されている内容も、できるだけ図示するように心掛け、可能な限りかみ砕いて説明していくので、あきらめずに読み進んでいただければと思う。

SSL/TLSにおけるセッションとコネクション

　SSL/TLSにおけるサーバとクライアント間での暗号化通信では、基本的にセッション型のモデルを用いる。通信の信頼性を高めるという考えに立てば、これは至って正当な考え方である。

　セッション型の通信管理モデルを用いる場合、プロトコル内でセッション管理を行う必要がある。SSL/TLSでは、このために「セッション」と「コネクション」という、2つの管理すべき接続状態を規定している。最初にこの2者について説明しよう。

　SSL/TLSを使い暗号化された通信を行うためには、通信の開始に先立って、まず初めに利用可能な暗号アルゴリズム、電子証明書の有無など、暗号化の条件に関して両者が合意しなければならない。いわゆる“ネゴシエーション”と呼ばれる過程だ。

　このネゴシエーションという作業は、一般に時間とCPU処理と通信量のかかる「コストの高い」処理である。そのため、通信処理の効率を考えれば、できる限り不要なネゴシエーションは行うべきではない。

　そういった視点に立ち、SSL/TLSでは、ネゴシエーションによる通信条件の合意と、実際の通信チャネルの管理を、それぞれ概念として独立させている。このうち前者が「セッション」であり、また後者が「コネクション」である。

　セッションとコネクションについて、もうすこし詳しく個条書きにすると、次のようになる。

　図20には、サーバプロセスとクライアントプロセス間における、セッションとコネクションの関係を図示してみた。サーバプロセスとクライアントプロセス間でのネゴシエーションの結果、まずセッションαが設定されている。そして、そのインスタンスとしてコネクションｘ、ｙがそれぞれ実際の通信チャネルとして存在する。また、同じプロセス間で、異なるセッションβも設定されている。こちらのセッションにはコネクションｚが通信チャネルとして存在している。

図20　セッションは暗号化の方法を合意した関係。コネクションはそれに基づいて設定される実際の通信チャネル

　前出の個条書きにある、セッションが「合意した関係」であり、コネクションが「通信チャネル」であることの意味は、この図からより具体的に把握できるかと思う。なお、この図から分かるように、セッションそのものは物理的な存在物ではない。だが、SSL/TLSの世界では、「合意した関係」を論理的な接続と見なして、あたかも物理的なものであるかのような取り扱いをする。以降を読み進めるに当たっては、この点にも留意しておくといいだろう。

　具体的なアプリケーションの構成要素と、セッションやコネクションがどのような関係になるのかは、アプリケーションの実装状況によって異なる。ここでは、その一例としてブラウザのウィンドウとの関係で考えてみる。

　図21はPCから2つのWebサーバに接続し、Webサーバ1では2つのウィンドウ、Webサーバ2では1つのウィンドウを開いたときの状態例だ。同一のWebサーバかそうでないかによらず、セッションは各ウィンドウごとに設定され、また1つのセッションで必要に応じて複数のコネクションが利用される。

図21　Webブラウザ画面とセッション／コネクションの対応イメージ

　コネクションを張るに当たっては、実際にはTCP/IPのソケットが用いられている。ソケットの接続先はWebサーバの443番ポートであり、またローカルポートはその時点で空いているポートが割り当てられる。なお、個々のコネクションはソケットディスクリプタによって識別できるので、各コネクションが混乱することはない。

　では次に、セッション、コネクションのそれぞれのレベルで管理している情報について見ていこう。