Last Updated 2001/1/15
SSLとSSHはもう使えない?という記事を翻訳しました。

●Security INDEXへ

★TOP INDEXへ

SSHとSSLの終わり?

元ネタはこちら

by Kurt Seifried

December18,2000

先日、dsniff2.3がリリースされた。なぜこれが重要なことなのか?
dsniff2.3を使うと、極めてポピュラーなプロトコル、SSLとSSHの欠点を利用することができる。
SSLとSSHは大量のネットワークトラフィックを保護するために使用される。オンライン銀行での金融取引、株の取引サイトから極めて重要なデータを持つホストに管理者がアクセスする、などのケースに使われることが多い。

SSHとSSLの両方とも暗号化公開鍵を使用しているが、そこに弱点がある。
その弱点を突かれた攻撃に遭った場合、(防御策は)ユーザが正しい判断を下せるかどうかにかかってきてしまうが、ほとんどのユーザはどのように対処していいかについて充分な知識がない。やはりユーザは間違った決断を下してしまうのだろうか?何度私達はユーザに、メールされた実行ファイルを開かないように、と言ったことか(苦笑)。

■暗号化公開鍵

インターネットを通じてセキュアで暗号化されたコネクションを確立するのに、1つ問題点がある。
どのような手段を取るにしても、あなたはある時点で公のコネクション、敵のネットワークかもしれないところと接続しなければならないということだ。
理想的なのは、2つのホストが様々な認証プロセスを用いてコネクションを確立する時に、公開鍵をお互いに交換することだ。(中でもDiffie-Hellmanは非常にポピュラーだ。)それぞれのホストは、他のホストの鍵を受け取る。残念ながら、このプロセスは、公のセキュアでないネットワークを通して行われるので、鍵の交換をアタックされる可能性がある。

例えば?
この例は単純化し過ぎるかも知れないが、基本的に合っている?
アリスというユーザがボブというサーバと話をしたいと思っている。
そして、チャーリーは、アリスのセッションを盗聴したいと思っている。そうすれば、彼はアリスのメールが読めるようになるからだ。アリスはボブに接続し始める。チャーリーはこれを盗聴する。

チャーリーはアリスのふりをして、ボブと会話する。その一方で、チャーリーは、ボブのふりをしてアリスと話をする。アリスが送った公開鍵を、チャーリーが途中で取る。そして、チャーリーは彼の公開鍵をボブに送る。ボブは彼の公開鍵をアリスに送る。そしてそれをまたチャーリーが取る。
チャーリーは、彼の公開鍵をアリスに送る。

ここで、アリスが彼女の秘密鍵を使ってサインする。そして、ボブの公開鍵を使って、ボブに対するデータを暗号化する。すると、その時アリスは実際にはチャーリーの公開鍵を使っているだろう。ということは、チャーリーは暗号化されたデータを復号化=解読できるということだ。
チャーリーはデータを受け取り、彼の秘密鍵を使って暗号を解除し、アリスの署名を取り、彼の秘密鍵を使ってデータに署名をし、ボブの公開鍵を使ってデータを暗号化する。そしてそれをボブに送る。
というわけで、アリスはボブとセキュアな方法で直接彼と話していると思い込んでいる。
実はチャーリーがコミュニケーションの間をモニターして、内容を改ざんしているにもかかわらず。
これは、チャーリーがアリスのユーザ名とパスワードを取得できるというだけでなく、彼のコマンドを挿入することができるということを表している。
ボブもアリスと同じ状態にあり、なんとも嬉しいことに、チャーリーがメインのハードドライブをフォーマットしようとしたとしても気付かないでいる。

公開鍵の問題はとても基礎的であるため、チャーリーのような方法はたくさんある。
SSLでは、最も一般的な解決策は、署名された証明書を使用することだ。
サーバには公開鍵を含んだ証明書があり、サーバ名等の情報も入っている。この情報の証明書は、信用できる第3者(VeriSignのような)の秘密鍵によって署名される。信用できる第3者の鍵は、普通はブラウザに組み込まれている。もしアタッカーが、ブラウザを攻撃でき、証明書を改ざんできるとしたら、暗号化される前に情報をリダイレクトできるのだろうか?
ユーザが、暗号化されたセッションをサーバと確立しようとする時、サーバが送った証明書は確かに有効であるということを証明できる。

残念ながら、この等式には欠けているものがある。SSLが、ユーザに対してサーバ認証を要求する時、通常サーバに対する認証はユーザのオプションである。
個人的な証明書を持っているユーザはほとんどいないため、サーバに対してアイデンテティを証明できるのは、極めて稀なことである。攻撃に対するコネクションをオープンにしている。
同じような一般的な問題がSSHにも存在する。
証明書の代わりに、SSHは単に秘密鍵と公開鍵を使っている。
そして、それらは一般的に署名されないので、アタッカーにとってコネクションを途中で傍受するのは、簡単なことである。
もしあなたがホストに接続するのが初めてで、サーバの公開鍵をローカルに持っていない場合、あなたは賢いとは言えない。もしあなたが、サーバの公開鍵を持っている場合、"Warning:server's key has changed. Continue?"「警告:サーバーのキーが変わりました。続けますか?」という警告を受け取るだろう。ほとんどのユーザはYesと打つ。
私は去年、SSLと他の認証プロトコルについていくつかの記事を書いた。
最後にURLの一覧があり、どのようにしてアタッカーは攻撃を可能にしたのかということについて討論をした。残念ながら、どちらもあらかじめコネクションが確立されていないかぎり、(サーバがユーザのパスワードを知っている、または、信用できるCAから署名された証明書を使っている)どんな認証システムも途中でアタックされてしまうという点で、疑わしいと言えよう。(人々がよいシステムを使っていても)

■対応策は?

なぜこの問題は解決されないのか?署名されたキーや証明書を使わずに?何か別の安全な方法で安全な通信コネクションを作成する?二つのパーティーの間で安全な通信コネクションを実現するためには、お互いを信用しないことだ。(それはつまり、お互いに自分が怪しいものではない(笑)ということを証明できない、ということである)多くのこうした固有の問題を解決べく実装されたような新しいキー交換アルゴリズムもあるが、ほとんどのアルゴリズムは、ユーザー(の行動)をサーバー側でログ取りすることを目的としている。従って、サーバークライアントの両方がそれぞれのユーザー名とそれに関連したパスワードを知ることになるか、さもなくば確認することにもなってしまう。
残念ながらこうしたプロトコル(手順)はSSLのトランザクションではうまくいかない。というのもSSLのユーザーには、自分が何者であるのか証明できない=適正な証明書を持たないユーザーが大部分であるからだ。(重要な情報を送受信する際には、ほとんどの場合に人々はSSLでの通信を求められるが、SSLを使っていないケースもかなり多い)

もっと悪いことに、現代のネットワークの根本的な部分はセキュアではなく、セキュリティなど考えもしなかった2、30年前にデザインされたプロトコルを使っている。低レベルプロトコルであるARP(Address Resolution Protocol、LAN上のMACアドレスとIPアドレスの変換に使われる)などは、セキュリティを考慮した機能を一切実装していない。もっと話を広げると、TCP/IPもUDPも暗号化と認証の実装を一切持っておらず、といってIPSecが広まるまでにはまだまだ相当時間がかかると思われる。DNSも基本的に安全ではない。やろうと思ったら誰でも嘘のDNS情報を流すことができ、その情報を確かめるすべも無い。DNSSECが現れ始めつつあり、.milドメインでは導入を予告しているので、その問題は何とか解決されるかも知れないが。

■dsniff

dsniffはDugSongによって書かれた洗練されたプログラムパッケージで、tcpdumpといった他の標準的なユーティリティーと合わせて使えば、トラフィックデータを分析できるようにネットワークをモニターしたり通信の宛先を書き換えたりすることができる。多くのパケットスニファーでもネットワークをモニターすることはできるが、このツールのように宛先を書き換えたり、暗号化されたデータを解読したりすることはできない。dsniffは数種のレベルでネットワークトラフィックの宛先を書き換えることができる。まずローカルなネットワーク。ハブやスイッチのどちらを使っていたとしても、arpspoofを用いて他のマシンのIPアドレスをハイジャックすることができる。スイッチがセキュアなものでarpパケットを無視できたとしたら、今度はmacofを使って大量のMACアドレスによってDOS攻撃を仕掛けることができる。スイッチの中にはMACアドレスデータがあふれるような事態になってしまったら、ハブとしての機能しかなさないものがあるので、ターゲットになるネットワークを無事にモニターできる、というわけである。

dnsspoofユーティリティーを使えばDNS応答を偽ることができるので、任意のIPアドレス(自分の管理化にあるものなど)に通信先を無理やり変えてしまうこともできる。tcpkillを使えば、コネクションを閉じろ、という偽のパケットを使って、ターゲットのマシンのTCPコネクションをブロックできる。管理下にあるマシンに対してトラフィックを流るようにしたあとは、ネットワークトラフィックから正確なパスワードや、メッセージや、ファイルなどを盗聴するツール群を使うことができる。dsniffの最新2.3バージョンを使えば、SSH(バージョン1)と(上記議論で検討したような弱点を持つ)SSLのコネクションを横取りし、モニターすることができる。dsniffに同梱されるツールは以下のとおり。

こうしたツール類は便利なソースパッケージで公開されていて、攻撃者は簡単に入手&コンパイルできる。こうしたツールのうちほとんどのものは、他のソースやお手製コードでも実現されている。しかし、今でもそれらのツールは取って来て使うことは難しく、そのことがSSLとSSHを少しだけ延命させていると言えよう。

■これについてあなたは何ができるのか?

この問題を無視するのも一つの考え方だが、それも長続きはしないだろう。SSHとSSLに関する抜本的な再構築が行われない限り、この問題を「解決」する手段はほとんどない。最良の手段は、攻撃者がどんな姿勢とやり方で攻撃を行うのかについて、ユーザーに教え込むことだ。ラボを作って実験環境を構築し、そこでこうした盗聴ソフトウエアのデモをユーザーや管理者に対して行って、自分たち自身のパスワードを見せてやって注意を払うように促すことも一つの方法だろうが、その場合事前に許可を得て、前もって警告しておくことを忘れないことだ。

ネットワークのセキュリティを全面的に見直すこともまた良い考えだ。攻撃者がネットワークに入れなければ、内部者資格を使った多種多様な攻撃を使うことができないからだ。もし重要な通信にSSLを使っているのであれば、CA(認証局)を構築し(またはアウトソースのCAを利用し)、スマートカード・リーダーと同じようにSSLの証明書をいちいちユーザーに発行して、安全にそれをインストールさせることだ。

SSHに関するいちばん簡単な解決法はバージョン1を止めることだ。バージョン2に移行することはそれほど難しいことではないし(OpenSSHがサポートしている)、(全てではないが)ほとんどのフリーのクライアントソフトウエアはバージョン2でも同じように動作する。ワンタイムパスワードの仕組みを利用することもできる。セキュアなトークンを使って通信するとリスクは最小限になるものの、セッションをハイジャックされる危険性は残される。そして、おそらくSSH1をSSH2に移行するよりも難しい。

しかし、誰かがdsniffをSSH2対応にするのは時間の問題であろう。そうなると、さらに低レベルの(DNSSECのような)セキュアなプロトコルを導入すべきであろう。DNSSECは攻撃者による偽のDNS応答を阻止するだろう(偽のARPを使ってローカルネットワークを騙すことはそれでもまだ可能であろうだが)。

その他のオプションとしてはIPSecを使って、ワークステーションやサーバーにも強制的にそれを使用させる、というものがある。強力な認証システムを使えば、攻撃者がトラフィックを偽造したり盗聴したりすることは非常に難しくなるだろう。

■サマリ

願わくばこのことがDNSSECやIPSecなどのセキュアなネットワークプロトコルの普及に役立って欲しいものだ。だれかが新しい数学的発見を行って、それを使ってセキュアな認証プロトコルを作った結果SSLやSSHの二の舞にはならずに済んだ、というようなことはありそうもない。今この時点で、セッションレベルでの暗号化はあなたがたの問題を解決する万能薬なんだろうか?いや、それは他のソリューションと同じく新しい問題を引き起こしているだけである。あきらかに、古い問題よりも新しい問題の方が解決するのはずっと難しい傾向にあるが、それでもまだ、解決不可能ではないのである。

■関連リンク

dsniff
http://www.monkey.org/~dugsong/dsniff/

Is SSL dead?
http://www.securityportal.com/closet/closet19990930.html

SSL Redux
http://www.securityportal.com/closet/closet19991007.html

SRP - A Secure Alternative for Authentication
http://www.securityportal.com/closet/closet19991208.html

The Death of Unencrypted Connections?
http://www.securityportal.com/closet/closet20000614.html

IPSec - We've Got a Ways to Go (Part I)
http://www.securityportal.com/closet/closet20000719.html

IPSec - We've Got a Ways To Go (Part II)
http://www.securityportal.com/closet/closet20000726.html

Ten Risks of PKI
http://www.counterpane.com/pki-risks.html

●Security INDEXへ

★TOP INDEXへ