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

[福永勇二，インタラクティブリサーチ]

SSLとTLSの関係

　もともとSSLはNetscape Communicatinos社が提唱してきたもので、暗号技術を有効に活用して、インターネットを安全に利用することを目的としたプロトコルだ。SSL 3.0まで同社で開発されたが、インターネット標準とするべく検討の場がIETFに移された。その後、1999年には標準化案がまとまり、TLS 1.0という名称により、RFC2246として公開されることとなった。本稿の執筆現段階でもこのTLS 1.0が最新バージョンである。

　TLS 1.0とSSL 3.0との間に正確な互換性はないが、その仕様の違いはごくわずかなものになっている。実質的にはSSL 3.0のマイナーバージョンアップを行って、RFC化したものがTLS 1.0と考えてよい。実際、TLS 1.0プロトコル中でのバージョン表記は“3.1”となっているくらいである。

　もっとも、インターネットの実情を見ると、TLS 1.0の利用はまだこれからという段階のようである。IE5ではすでにTLS 1.0のコードが入っているが、デフォルトでは利用しない設定になっている。また、Netscape Communicatorは、いまのところTLS 1.0は利用できない。これらから想像する限り、多くのWebアクセスではまだSSL 3.0が利用されているはずである。

　そうは言っても、IEでTLS 1.0を利用できるような設定にして、いくつかのSSLサイトにアクセスしてみると、いずれもTLS 1.0のヘッダが返ってきた。これはWebサーバのTLS化がかなり進んでいることを示していると考えられる。ならばWebブラウザの対応が進むことで、いずれTLS 1.0が標準的に利用されることになる可能性は高い。

　そういった状況を踏まえて、本稿では特に断りがない限りTLS 1.0の仕様（RFC2246）をベースに話を進めてゆく。前述のとおり、TLS 1.0とSSL 3.0とは非常によく似ているので、コンセプトや大部分のパケットフォーマットについては、概ねSSL 3.0にも共通すると考えて構わない。また、言うまでもないが、SSL 3.0の正確な定義が必要な方はSSL 3.0の定義ドキュメントを参照していただきたい。

TCP/IPスタックにおけるSSL/TLS

　最初に図2でSSL/TLSのプロトコル的な位置づけを確認しておこう。SSL/TLSを利用しているとき、それらはTCPやUDPなどトランスポート層の直上で、アプリケーション層の直下、つまりトランスポート層とアプリケーション層にサンドイッチされた部分に位置することがわかる。この位置付けから想像できるとおり、SSL/TLSはTCPやUDPが提供する機能（具体的にはソケット）を使用し、そこから得られたデータに何らかのセキュリティ処理を施して、その結果をアプリケーションに引き渡す、という動作を行う。そのため、利用できるアプリケーションが限定されないという特長を備える。図にはアプリケーションを3種類しか描いていないが、本質的にあらゆるアプリケーションでSSL/TLSの機能を利用可能である。

図2　TCP/IP中でのSSL/TLSのポジション

【注】

トランスポート層以下の信頼性が低い環境に向けては、TLSに欠落や並べ替え機能を追加したDTLS（Datagram Transport Layer Security）も定義されている。

　ここでは、SSL/TLS利用の代表例であるWebブラウザの実装を見てみよう。現在、SSL/TLSに対応する機能は「Webブラウザに組み込む」のが普通となっている。SSL/TLSの位置付けから考えると、OS機能として備えるのが自然なはずだが、SSL/TLSを利用するサービスがWebサービス中心という事情もあって、こういった形の実装になっているようだ。Internet Explorer、Netscape Communicatorいずれもこの考え方は同じである。

　SSL/TLS機能の利用有無の判別は、ユーザーがWebブラウザに指定するURLによって行われる（図3）。「http://〜」と書いた場合、SSL/TLS機能は利用せず、OSのTCP/IP機能を直接利用してWebサーバと通信する。また、「https://〜」と書いた場合、Webブラウザ機能は、自身が備えているSSL/TLS層機能を介してOSのTCP/IP機能を利用する。そのため通信内容は暗号化され安全な通信を実現するという仕組みである。なお、こうして発生したリクエストをWebサーバ側で容易に判定できるよう、それぞれのリクエストでは異なったTCPのポート番号を利用している。具体的には、前者はhttp本来のポート番号80番、後者は新たに割り当てられた443番をそれぞれ用いる。

図3　WebブラウザにおけるURLとSSL/TLSの関係

　繰り返しになるが、SSL/TLSはWebサービスに限らず多彩なアプリケーションに適用可能である。SSL/TLSが有用なプロトコルとして生き残っているのには、その柔軟性に対する評価も大きいようである。ちなみに、既存サービスをSSL/TLS化したときのポート番号は、現在、表1のようなものが定義されている。

プロトコル名	ポート番号 （TCP/UDP）	説明
https	443	http protocol over TLS/SSL
nntps	563	nntp protocol over TLS/SSL（旧snntp）
ldaps	636	ldap protocol over TLS/SSL（旧sldap）
ftps-data	989	ftp protocol, data, over TLS/SSL
ftps	990	ftp protocol, control, over TLS/SSL
telnets	992	telnet protocol over TLS/SSL
imaps	993	imap4 protocol over TLS/SSL
ircs	994	irc protocol over TLS/SSL
pop3s	995	pop3 protocol over TLS/SSL（旧spop3）
表1　SSL/TLS化プロトコルとポート番号。Internet Assigned Numbers Authority（IANA）ポート割当リストから、SSL/TLS 化に関するものを抜粋

SSL/TLSのレイヤ構成

　ではSSL/TLS層の内容を更に詳しく見ていこう。図4はSSL/TLS層の内部構造、各レイヤのプロトコル、そして提供する機能を表したものだ。

図4　SSL/TLSのレイヤ構造

　この図を見て最初に気づくことは、SSL/TLS層の中身は大きく2つに分かれているという点かと思う。何気なく眺めていれば、単なる二分割のようにも思えなくもない。だが、機能面の理解が進んでゆくと、この位置がなかなか絶妙な機能境界を提供していることに気づくことになるはずだ。もっとも、この段階ではピンとこないと思うので、どこか頭の隅にでも入れておいていただくとよいだろう。

　SSL/TLS層のうち、下位レイヤで使用されるプロトコルはRecord Protocolと呼ばれている。このプロトコルはSSLの中でも比較的単純かつ基本的な機能を提供するものだ。冒頭で述べた3つのポイントで言えば、「盗聴」と「改ざん」を防止する役割を担っている。

　「盗聴」を防止する機能とは何か。これは「暗号化」機能である。Record Protocolでは、上位レイヤから引き渡されたデータを暗号化し、第三者では内容を理解できない形にしてから、下位にあるTCP/UDP層に引き渡す。逆に、TCP/UDP層から到着したデータは、最初にRecord Protocolの中で復号し、誰もが意味を理解できる形に戻してから、上位レイヤに引き渡す、といった動作をする。

　このような動作を行うことにより、「Record Protocolより下位にあるプロトコル、つまりTCP/IPレベルで運ばれているデータは基本的にすべて暗号化されている」という状況ができあがる。このとき、もしネットワーク上でデータを盗聴されたとしても、残念ながら盗聴内容は第三者に理解できない。つまり、盗聴という行為を実質的に無効化することが可能となるわけである。

　では、もうひとつ「改ざん」の防止はどうだろうか。こちらを実現するには「メッセージダイジェスト」と呼ばれる機能を利用する。メッセージダイジェストは、暗号化に関連した技術の一つで、一言でいえば、文章を機械的に要約したような一連の情報を指す。もし、通信途中で文章が改ざんされれば、その要約値は変わってしまうため、改ざんを検出可能という理屈だ。メッセージダイジェストの正確な説明にはページが必要なので、後ほど詳しく触れることにしよう。

【コラム】 「メッセージダイジェスト」を簡単に説明すると……

　「そうはいっても、具体的なイメージが湧かないよなぁ」という方のために、ここであえて大胆なたとえをさせていただこう。メッセージダイジェストは、「文章」といっしょに「文章に出現する全文字の画数の合計数」を送るようなもの、という説明だ。総画数だけでは誰でも計算できてしまうので、送り主と受信者だけが知っている「秘密のキーワード」を決めておいて、それも含めた総画数を計算することにしておく。

　文章の送り主は、文章といっしょにその総画数を相手に送る。文章を受信した者は、受信した文章から自分で総画数を計算し、その結果と送信者の送ってきた総画数を比較する。もし、この両者が一致すれば、文章は第三者に改ざんされることなく、安全に届いたと見なすことができる。反対に一致しなければ、文章は通信途中で改ざんされていると考えられる。こんなイメージである。

　実際には、画数の増減を他の部分で相殺可能であったり、秘密のキーワードが逆計算できたりするので、総画数はメッセージダイジェストとしては役立たない。本物のメッセージダイジェストでは、文章本体とダイジェストから、改ざん内容の相殺方法や、秘密のキーワードが想像できない（逆計算困難な）、特別な関数が用いられている。

　一方、SSL/TLS層の上位レイヤには、Handshake Protocol、Alert Protocol、Change Cipher Spec Protocol、Application Data Protocolの4つのプロトコルが含まれる。こちらのレイヤが提供する機能は、「なりすまし」の防止、そして各機能の利用準備を整える機能だ。

　このうち、「なりすまし」の防止には「、認証」機能が必要となる。この「認証」とは何か。端的に言えば、あるサーバが本当にそのサーバであることを確認することだ。

　こういったケースは実世界でもよく起こる。役所等に重要な届け出や申請をするときに、運転免許証等の提示を求められた経験をもつ方は多いだろう。これは申請者が本人かどうかを確認するために行われているものだ。ではなぜ、運転免許証を提示すれば本人と認めることができるのか。それは「運転免許証や保険証の発行機関は十分に信用できる」→「そこに書かれている内容は十分に信用できる」→「免許証の写真と実物の顔、免許証の名前と申請者の名前が一致するなら、それは本人に間違いない」というロジックが成り立つからである。つまりこの役所では、自らが苦労して身元調査をしなくても、十分に信頼できる機関での証明を根拠に、本人性の確認ができたと見なすことが可能となるわけだ。

　SSL/TLSでの認証にはいくつかの方法が規定されているが、そのうちもっとも基本的なスタイルがこれと大変よく似たものになっている。つまり、あるサーバが本当にその名前どおりのサーバかどうかの確認は、「十分に信頼できる機関が発行した証明書」を使って行われるのである。具体的には、SSL/TLS通信を開始する最初の段階で、サーバは本人性を証明する証明書をクライアントに提示する。クライアントは、受け取った証明書がニセの証明書でないか、信頼できる証明機関が発行したものかを確認。問題なければそのサーバを信用して暗号化通信の準備を継続実行し、実際のアプリケーション間の通信を開始する、という流れとなってゆく。ご覧のとおり、実世界の出来事によく似ていることがお分かりいただけるだろう。

　上位レイヤのもう1つの機能は「ネゴシエーション」機能である。これは、通信に先立って、通信相手を確認したり、双方が利用できる暗号化アルゴリズムを確認するなど、いわゆる暗号化通信のお膳立てを行う働きを備えている。前出の認証機能も、見方を変えればこのネゴシエーション機能の一部と見なせなくもない。SSL/TLSでの通信を開始するにあたっては、最初にこのネゴシエーション機能が働き、必要な合意が交わされた後に、実際のアプリケーション間の通信が始まる。外国人とミーティングをする前に、「何語でミーティングをしましょうか」と、英語メールで相談するようなもの、と見れば理解しやすいかもしれない。