現在、多くの方がHTTPやSMTPを始めとする様々なネットワークプロトコルを日常的に利用しています。しかしながら、代表的なプロトコルであっても、広く使われているからという理由だけで、それらを使用しており、それらのプロトコルが安全かどうか認識していない場合が多いです。そこで、ここでは、各プロトコルの安全性とリスクについて紹介します。
読み進める上で、もしからしたら普段使用しているのに、危険と紹介されるプロトコルが出てくるかもしれません。その場合、代替手段があるのならば、そちらを使用することを強く推奨します。
まず、次に挙げるメジャーな通信方法は、すべてそのままでは絶対的に危険です。
どれもあなたのパスワードが平文で通信されます。これは、あなたのパスワードをネットワーク上の悪意ある人が簡単に盗むことができることを意味します。次のセクションから各プロトコルについて細かく見ていきます。
メールを受信するためのプロトコルです。メールを受信するためにユーザ名とパスワードを使用しますが、これらは、平文で通信されます。
POP3で使用するパスワードをMD5ハッシュ化して通信する方式です。この場合、パスワードは暗号化されますが、それ以外のメールの内容は、平文で通信されます。
しかしながら、2007年4月IPAからMD5ハッシュに関する脆弱性が公表されました。本脆弱性はMD5ハッシュから理論的に元のパスワードを求めることができる脆弱性であり、現在では安全なプロトコルとみなすことが出来なくなりました。
POP3同様、メールを受信するためのプロトコルですが、POP3と違いメールはすべてサーバ上で管理されます。メールを閲覧･受信するためにユーザ名とパスワードを使用しますが、これらは、平文で通信されます。
SMTP AUTHは、メール送信時に認証を行うことにより、送信メールサーバがスパムメールの踏み台になるのを防ぐことができる方式です。SMTP AUTHには、主に次のようなの認証方式があります。
このうち、LOGINとPLAINは、平文で通信されます。CRAM-MD5は、APOP同様、パスワードはハッシュ化されますが、それ以外のメールの内容は平文で通信されます。
しかしながら、APOP同様、MD5ハッシュに脆弱性が見つかったため、現在では安全なプロトコルとみなすことが出来なくなりました。
ログイン時にユーザ名とパスワードを使用しますが、これらは、平文で通信されます。
ログイン時にユーザ名とパスワードを使用しますが、これらは、平文で通信されます。
前のセクションでは、平文で通信するのは危険と書きましたが、一体それがどれくらい危険なのかサッパリ判らないと思います。ここでは、実際のネットワーク上でどのような情報が流れているのかを提示します。
次のユーザ名とパスワードを使用して、FTPでログインを行います。
| 項目 | 値 |
|---|---|
| ユーザ名 | user1 |
| パスワード | mypassword |
上記アカウント使用して、クライアントからテストサーバに対してFTPでログインした時の通信内容を表示させたのが次の図です。(見やすいようにパケットを加工しています。)
ここで使用したプロトコルはFTPですが、前のセクションで挙げたプロトコルであれば、どれも同じように通信内容からユーザ名とパスワードを表示することができます。また、ここで行っている通信内容を表示するという行為は、特別なものでも何でもありません。ネットワークの仕組みを理解していれば、誰でもそれが当然であることを理解できるものです。
通信内容を見ることができるのは誰か？これを理解しなければリスク管理は行えません。通信内容を見ることができるのは、次の機器とその利用者です。
注目すべきは、2つ目と3つ目です。
2つ目は、あなたのすぐ近くでネットワークに繋がっている人の可能性を意味します。
3つ目は、ネットワーク的に遠くなるにつれ危険度が高くなることを意味します。その経路上のどれかに悪意のある機器、悪意のある人物に乗っ取られた機器があれば、そこであなたのパスワードが盗まれるからです。
その理由は、どれもネットワークがまだまだ未発達な時にできたプロトコルだからです。そして、安全な代替手段に変えないのは、相手サーバが対応していない場合や多くの場合利用者が簡単な古いプロトコルを手放そうとしないからです。安全なプロトコルには、安全に利用するための手間が掛かります。新しいソフトウェアを導入するのもその手間の一つです。しかし、一度導入してしまえば、多くの場合、古いプロトコルとほぼ同じ手間で利用することができます。
前者の場合はどうしようもありませんが、後者の場合は、せっかく安全にできる環境があるのだから、それを利用した方が良いです。前者の場合であっても、リスクを理解し、ネットワーク的に近いところからなど、使用する場所を限定すべきです。
また、覚えていて欲しいのは、紹介した代替手段が完全に安全ということはありえないということです。なぜならそれらの安全とは、現時点での安全であって、将来の世界で安全であるとは限らないからです。これは、コンピュータの処理速度が上がるに連れて暗号を解く速度が速くなるためです。将来もっと安全な通信手段が確立されているならば、それらに乗り換えるべきです。
このセクションでは、前のセクションで代替手段として提示したものを見ていきます。それぞれ、相手サーバがこれらの環境に対応している必要があります。
POP3にSSLもしくはTLSを組み合わせたものです。これらは、公開鍵暗号方式と共通鍵暗号方式を組み合わせたものです。この方式を用いた場合、メールサーバからクライアントマシン間のユーザ名・パスワード・メールの内容のすべてが暗号化されます。POP3形式のメール受信方法としては、現時点で最も安全な手段です。
IMAPにSSLもしくはTLSを組み合わせたものです。POP3S同様、メールサーバからクライアントマシン間のユーザ名・パスワード・メールの内容のすべてが暗号化されます。IMAP形式のメール受信方法としては、現時点で最も安全な手段です。
SMTP AUTH認証方式にSSLもしくはTLSを組み合わせた方式です。LOGIN、PLAIN、CRAM-MD5などのどの認証方式をとっていても、クライアントマシンからメールサーバ間のユーザ名・パスワード・メールの内容のすべてが暗号化されます。
POP3S、IMAPS、SMTPSは、クライアントマシンからメールサーバ間はメールの内容も暗号化されますが、メールサーバから送信先メールアドレスのメールサーバ間は、現時点では多くの場合、暗号化されません。これは現在稼働中の数多くのSMTPサーバがSMTPサーバ間の暗号化通信に対応していないためです。ただし、サーバ間の通信では、パスワードが通信されることはないため、SSL/TLSを用いることが重要なことは変わりません。
参考までに、現在、Internet Mail Consortium(IMC)で、世界中の人々が次世代メールプロトコルについて議論(要約)をしています。メールの送信者を詐称することを防げない仕様についても対策が議論されています。
また、現時点で行えるメールの内容を完全に暗号化する方法としては、PGPを用いるのが一般的です。
SSHは、公開鍵認証方式を用いたリモートシェルです。メールなどの古いプロトコルとの組み合わせではなく、Telnetとはまったく別のプロトコルを用いる別物です。認証や通信内容すべてが暗号化されます。リモートシェルを用いる方法としては、現時点で最も安全な手段です。
SCPは、SSHを用いたファイル転送方式です。SSH同様、FTPとはまったくの別物で、通信内容すべてが暗号化されます。FTPの代替手段として、ファイル転送を行う方法としては、現時点で最も安全な手段です。
参考までに、HTTPSを用いたファイルアップロードも安全です。
HTTPは、安全か危険か。今までの考え方で判断するならば危険です。HTTPSは、SSLで通信内容が暗号化されるので安全です。しかし、HTTP/HTTPSは、少し見方を変えて判断しなければなりません。
HTTPは、インターネットを利用する上で一番利用するプロトコルです。暗号化通信ではありませんが、多くの場合、暗号化される必要はないので、それを使用してもまったく問題はありません。しかし、もしあなたがオンラインショッピングや各種サービスを利用するのに個人情報やパスワードを入力必要がある場面で、そのサイトがSSLを用いた安全なHTTPSを使用していなければ、それは利用しない方が良いです。
掲示版への投稿パスワードなど、重要な情報を含まない場面では、HTTPであろうと入力しても問題は小さいです。その判断は、各自のリスク判断に委ねられます。
HTTPSは、SSLにより通信内容が暗号化される通信方式です。HTTPで延べた通り、個人情報やパスワードを入力する場面では、SSLが利用されていなければなりません。
それは、HTTPSが使われていたとしても、個人情報を入力した時点で、その情報が今後どのように扱われるのか不明だということです。最近ニュースなどで話題になっている通り、一度個人情報を登録するということは、その分、将来その個人情報が流出する機会が増えることを意味します。また、気軽にあなたのメールアドレスを登録すれば、その後、絶え間ない宣伝メールに苦しむ場合もあります。つまり、通信方式だけでなく通信内容自体の心配もしなければならないということです。
また、作りの悪いショッピングサイトなどでは、HTTPSで安全に個人情報を入力し商品を購入したにも関わらず、内容が暗号化されないメールで個人情報入りの購入確認メールを送ってくるサイトがあります。これでは、SSLにより、そのサイトが第3者機関に証明された成りすましサイトではないことは保証されても、あなたの個人情報は、まったく保証されていません。あなたがこのような個人情報を取り扱うサイトに携わるのであれば、このような点にも注意を払わなければなりません。
今回紹介しなかったプロトコルがまだまだたくさんありますが、それらを使用する上で次のようなリスクを総合的に判断し、利用するのが良いです。
相手サーバがそれに対応していなければ、相手サーバの管理者に危険性の指摘と安全な代替手段を要求するといった最終手段もあります。
また、完全に安全なものなどないと紹介しましたが、これは、より良く新しいものに敏感に柔軟に対応するのが完全な安全への近道だということです。
また、どんなに優れたプロトコルを利用していても、管理者や利用者がずさんにパスワードを管理すればまったくもって意味がありません。
最終的に一番重要なのは、より良く柔軟に進化し続ける開発者・提供者・利用者の意識です。
情報科学部で一般的に予めされているThunderbirdは、本記事で紹介したSSL/TLSに対応しています。Thunderbirdの使用方法については、別記事であるThunderbirdの設定方法とメールの書き方を参照して下さい。
本記事の内容が良く分からない場合は、HTTPSで暗号化されて提供されているWebmailのみを利用するもの良い手段だと思います。
また、使用しているメールクライアントソフトウェアがSSLに非対応である場合でも、stunnelというソフトウェアを利用することによりSSLを用いた通信が可能となります。詳細については、下記の記事を参照して下さい。
