IIJでは広報誌「IIJ.news」を隔月で発行しています。本blogエントリは、IIJ.news連載コラム「インターネット・トリビア」を転載したものです。IIJ.newsはご希望者へ郵送でお送りしています。また、IIJ WebではPDF版をご覧頂けます。
IIJ.news vol.152 もくじ
- ぷろろーぐ「梅雨時の憂鬱」 鈴木 幸一
- Topics 進化するメッセージング・テクノロジー
- メッセージング・テクノロジーを取り巻く環境
- 今さら聞けない！メールの基礎知識 その1 メール配送の仕組みとそれを悪用したサイバー攻撃
- 今さら聞けない！メールの基礎知識 その2 あなたのメールが迷惑メールとして扱われる前に
- 迷惑メール対策活動の広がりとJPAAWG設立の意義
- 大規模メールシステムの構築
- 業務アプリケーションに進化する ビジネスチャットツール
- 人と空気とインターネット: 新たなブルーオーシャンを目指して
- Technicval Now: 白井データセンターキャンパス 稼働開始
- インターネット・トリビア: プロトコルの安全性 ※この記事で掲載
- グローバル・トレンド: ジャカルタのMRT
- ライフ・ウィズセーフ: 10年にわたる負け戦
それぞれの記事はIIJ.news PDF版でお読み頂けます。
インターネット・トリビア: プロトコルの安全性
インターネット上で通信を行なう際には、それぞれの目的に合わせて、決められた通信手順（プロコトル）を使います。Telnet、SMTP、POP3、HTTPといったプロトコルは、インターネット初期から現在まで広く使われているものです。そのため、これらのプロトコルは、今の常識からすると、ずいぶん“ゆるい”設計になっています。
例えば、電子メールの送信・配送に使われるSMTPは、送信の際、送信者の確認がなく、誰でも他人のメールアドレスを「送信者」に設定して送信可能でした。こうした“ゆるさ”を突くかたちで送信者を騙ったメールが大量に送られる事態が頻発し、今日の迷惑メール問題へと発展しました。
また、これらのプロトコルは全般的に通信の中身を保護するという考え方に乏しく、インターネット上で通信の内容や、場合によってはパスワードそのものが第三者にも見られかねない構造になっています。
さて、現在ではこのような“ゆるい”プロトコルだと、不正利用に対抗することがむずかしくなっているため、安全性強化のための改良が図られています。その主なポイントは、通信の暗号化による盗聴対策、利用者・サーバ双方のなりすましを防止するための認証の強化などです。ただし、プロトコルによってその実現方法はさまざまです。
一つの方法は、プロトコル自体を新規に作り直すことです。ネットワーク経由でコンピュータを操作するためのTelnetプロコトルは、同じ目的を持ったsshというプロトコルで代替されています。sshは、通信自体を暗号化して盗聴対策を行なうとともに、コンピュータや利用者がなりすまされていないかを確認するための強固な認証システムを備えています。sshはTelnetと全く異なるプロトコルであり、接続のためのプログラムも全く異なるものが使われています。
別の方法として、既存のプロトコルを生かしたまま、暗号化や接続先の認証機能を強化する方法もあります。例えば、メールの受信に使われるPOP3では、通信中にやり取りされる命令群はそのままにして、その命令をSSL・TLSといった安全な通信を行なうための別のプロトコルで送受信することで暗号化を実現しました。この方式は、新しいプロトコルへの置き換えに比べて、従来使っていたソフトウェアを生かしたまま、小規模な改修で安全性を高めることができます。
ただ、プロトコル自体を置き換えてしまったり、小規模な改修では安全性を向上させることがむずかしい場合もあります。SMTPは利用者からのメールの送信だけでなく、メールサーバ同士の中継にも使われていますが、メールサーバは世界中に存在し、相互に中継を行なっているため、新しいプロトコルに全面的に置き換えることは困難です。そのため、中継用のプロトコルは従来のままとし、メール送信時の通信を分離し、そちらに対して認証機能と暗号化が導入されました。これによってメール送信時の不正にはある程度対抗できるようになりましたが、メールサーバ同士の中継部分は従来のままなので、中継部分に横入するようなかたちの不正には対抗できませんでした。結局、中継部分についてはプロトコルの改善ではなく、一般利用者がサーバに接続できなくなるようなフィルタリングを施すことと、中継されたメールが正当なものかどうかを確認するための別の手法を用意することで、不正対策が図られています。
安全性が十分でない“ゆるい”プロトコルは、置き換えや改良が行なわれるべきですが、もともとのプロトコルの設計や利用様態によっては、それが困難なこともあります。そうした制約があっても、互換性を保ちながら安全性を高める試みが続けられています。