今すぐに誰にでもできる三つのこと:
- 私達のTorネットワークを成長させるためにサーバを運用する ことをご検討ください。
- あなたの友人にも伝えてください！彼らにもサーバを運用し、またはヒドゥンサービスを 運用するように、そして彼らの友人にそれを伝えるように伝えてください。
- 私達は資金とスポンサーを探しています。もしあなたがTorの目的に賛同なさるなら、 Torの開発に対してより深くサポートするために貢献してください さらに、もしあなたがコミュニケーションの安全性を望んでいる会社、NGO、機関、その他の組織を ご存知なら私達に知らせてください。
補助アプリケーション
- 匿名になろうとしているときに、これに反してDNSリクエストがその内容を ローカルの盗聴者に"リーク"してしまわないようにするよい方法を探しています。 (アプリケーションがSOCKSプロキシに到達する前にDNS解決を行うために起こることです。)
- tsocks/dsocks アイテム:
- tsocksパッチを当て、新たな子プロジェクトを管理する必要があります。 もし必要なら私達が新プロジェクトをホスティングします。
- Torのmapaddressコマンドをコントローラインターフェースから使えるように するためDug Songの"dsocks"プログラムにパッチを当てる必要があります。
- tsocksとdsocksのどちらがインストールされているのかを検知し、 適切にそれらを呼び出すtor化スクリプトを作る必要があります。 このためには、恐らくインターフェースを統一したうえで、それらの間で コードを共有するようにするか、またはどちらか一方を完全に捨て去ること も必要になるかも知れません。
- サーバを運用している人々はよく私達に対して、一日のうちのある時間帯だけに ある帯域レートを適用し、残りの時間帯には別の帯域レートを適用したいという 要望をしてきます。これをTorの内部で制御するよりも、 Tor制御インターフェースを通じて動作し、帯域レートを変更するための設定を 行う小さなスクリプトがあったほうがいいでしょう。恐らくそれはcronから実行されるか、 または適当な時間だけsleepした後に動作する(こちらの方がより移植性があるでしょう) ものになると思われます。どなたかこのスクリプトを書いてください。そしたら私達は それをcontrib/に加えます。それは Tor GUIコンペテション でもよいエントリになります。
- Torは 特定の出口ノードから出ることが出来ますが、出口の国だけを指定して 自動的にノードを決めることも出来なければなりません。最善の方法は、 Blossomディレクトリをも取得することとし、それを安全に取得する Blossomクライアントをローカルで実行する(Torを通してそのシグネチャをチェックして) .country.blossomホストネームを中断してうまく動くようにすること です。
- 地理位置データについて言えば、誰かがTorサーバの位置を表す世界地図を 描く必要があります。ネットワークが成長し変更されるにつれ情報が自動的に アップデートされるものなら、なお良いです。残念ながら、 これを実現する最も簡単な方法は、全てのデータをGoogleに送信して地図を描いて もらうことになってしまいます。この方法がプライバシーに与える影響はどの程度の ものでしょうか？あるいは他にもっといい選択肢があるでしょうか？
ドキュメント
- Torユーザがjavascript、java、activex、flashなどを無効にしていない場合に、 匿名性を失わせる攻撃に晒される可能性があると聞いています。ユーザがこのような リスクを管理することを容易にするプラグイン(FirefoxのNoScriptプラグインのような) がどこかにないでしょうか？この場合のリスクとは正確に言ってどのようなもの なのでしょうか？
- Privoxyの機能の全てを肩代わりするFirefox 1.5+向けのプラグインのセットは 存在するでしょうか？
- Matt Edmanが彼の作ったTorコントローラ Vidalia のためのドキュメントおよびhow-toを書くのを手伝ってください。
- Torを使用するために使用できる私達のプログラムリストにあるプログラムを使ってみて結果を報告してください。
- 私達は動的に接続を遮断してそれをTorを通して送信することについてのよりよい ドキュメントを必要としています。私達の新しいTransPort機能のよりよい使用法に ついてもそうですが、tsocks (Linux), dsocks (BSD),freecap (Windows) がよい候補として挙げられるでしょう。
- Torの有用なインターフェースとなりうるプログラムの巨大なリストがあります。 どのプログラムがどういった状況で使えるでしょうか？それらをテストして 結果を報告してください。
- ウェブページおよびドキュメントを他の言語に翻訳するのを手伝ってください。 手伝ってくださる方は翻訳ガイドライン をご覧ください。すでに翻訳があるフランス語およびスウェーデン語の メンテナンスを助けてくれる方も募集していますー 翻訳ステータス概要 をご覧ください。
- 私達のSSLSVN リポジトリ のルート証明書をcacert から取得するのがいいかどうかについて誰か案内してくれませんか？
コーディングとデザイン
- TorサーバがWindows XP上でうまく動きません。Windows上では、 Torは非ページプールメモリを使用する標準のselect() システムコールを使います。これは、中規模のTorサーバが非ページプールメモリ を喰い潰してしまい、 大混乱とシステムクラッシュを引き起こすことを意味します。恐らく代わりに オーバーラップIOを使用しなければならないでしょう。解決策の一つは、 libevent にWindows上でselect()ではなくオーバラップIOを使用する方法を教え、 Torを新しいlibeventインターフェースに適合させることでしょう。
- Torサーバは扱うセル毎にそれをストアアンドフォワードする必要があるため、 数十メガバイトのメモリをただバッファのためだけに消費することに なります。バッファをいつ収縮／拡張させるかについてのよりよい ヒューリスティクスが求められています。恐らくそれはLinuxカーネルの バッファデザイン(一枚岩のバッファではなく、多くの小さなバッファを 互いにリンクさせている)をモデルとすべきと思われますが、どうでしょうか？
- 私達は、「このIPアドレスはTorの出口サーバですか？」の質問に答える 正式なメインサイトを必要としています。それはウェブインターフェースおよび DNSBLスタイルのインターフェースを含む、複数のインターフェースを提供し なければなりません。それはTorのディレクトリ情報のローカルミラーを 運用することによって最新の回答を提供するようにすることも考えられます。 間違いやすいのは、出口サーバであるかどうかの問いに対する答は必ずしもbooleanでは ないということです: したがって、実際には「このIPアドレスは、私のIPアドレス :ポートに向かって出てくる可能性のあるTor出口サーバなのか？」を問わなければ ならないことになります。DNSBLインターフェースは恐らく毎分数百もの クエリを受信することになるでしょうから、何か賢いアルゴリズムが求められ ます。もしそれが出口ノードをいちいちアクティブにテストしてどのIPアドレスから それが出てくるのかを知ることができればなお良いです。 詳細はこちら。
- Torサーバは時にクラッシュし、それが動いているコンピュータが ネットワークから脱落し、あるいはその他のアクシデントに見舞われます。 Torサーバのオペレータの幾人かは、彼らのTorサーバが元気に稼働しているか どうかを定期的にチェックしてもしそうでない場合には警告のメールを送信 してくれるような、「通知」サービスに合意することに興味を示しています。 どなたか、幾つかのcgiスクリプトと幾つかのウェブページを書いてある種の wgetハックをセットアップし、さらに／もしくはNagiosのようにより複雑なモニタリング を行ってみませんか？その最初のバージョンは、単にディレクトリポート をチェックするもの、例えば、キャッシュされたネットワークステータス ページを見て正しいIPアドレスおよびポートを調べたら次にそれを "/tor/server/authority"ページで問い合わせるといった具合で結構です。
- 最新のTor、Polipo or Privoxy、 Firefox、 Gaim+OTRその他が収録された LiveCDがあれば素晴らしいと思います。ここに二つの取り組みがあります: 一つはセキュリティ関係者がその安全性に付いて意見を形成するに十分な 、システムおよび選択についてのドキュメント整備です。もう一つは、Anonym.OS のように早々に廃れてしまわないように、容易にメンテナンスをする方法を 見出すことです。そのCDイメージがsmall-form-factor CDの一つに適合する ものならなおさら良いです。
- LiveCDイメージに関連して、私達は直感的に安全で十分なドキュメントが 付いたTorおよび補助アプリケーションを収録したUSBイメージの製作に取り組む 必要があります。ここで最も難しいのは、どういった設定が安全かを決定し、 その決定をドキュメント化し、容易にそれを維持していけるようにすることです。
- 私達おすすめのTorグラフィカルフロントエンド Vidaliaは、あらゆる種類の 開発作業を必要としています。
- 抗ブロッキングデザインの設計を実際に 始めなければなりません。その作業には、デザインを具体化し、Torの多くの様々な 部分を変更しVidaliaを Torの新しい機能をサポートするように変更して実際に配備できる ように準備することが含まれます。
- 私達はエンドツーエンドトラフィックコンフォメーション攻撃を研究する ための柔軟なシミュレーションフレームワークを必要としています。 多くの研究者が、彼らの「この攻撃はうまくいくだろう」あるいは「ある防御方法が 大いに有効に違いない」という直観を証明するためにアドホックなシミュレータを 早くも設計しています。すべての人々がその正当性を知ることが出来るように 十分にドキュメント化されオープンであるようなシミュレータを作成することが できないでしょうか？これには多くの新たなリサーチが必要となるでしょう。 コンフォメーション攻撃のこのタスクの研究側の詳細については 下のエントリをご覧くださいー時期は未定ですが、 それが完了した時には文書を書くのを手伝ってもらえると思います。
- 私達はPolipo 対Privoxyの計測研究を必要と しています。Polipoは、Torに起因するスローダウンを計算に入れても、 実際にPrivoxyよりも際立って速いのでしょうか？その計測結果はLinuxでも Windowsでも同じでしょうか？またこれに関連して、PolipoはPrivoxyよりも より多くのウェブサイトを正しく扱うことができるのでしょうか、あるいは その逆でしょうか？Windowsのような普及したプラットフォーム上でのそれらの 安定性について、何か問題はないでしょうか？
- 上のことに関連して、Polipo がWindows上で安定して機能するように移植するのを助けてくださいませんか？
- 私達は分散テストフレームワークを必要としています。すでにユニットテストは ありますが、Torネットワークを起動させ、それをしばらくの間使用し、少なくとも それの一部分が稼働していることを検証できるようなスクリプトがあれば 素晴らしいと思います。
- Mike PerryがTorFlowライブラリ (TODO) を作成していますが、これを助けてあげてください:これは Tor制御プロトコル を使用して、Torに対して様々な方法で回路を形成するように指示し、その パフォーマンスを計測し、異常を検知しようと試みるpythonライブラリです。
- Tor 0.1.1.xおよびそれ以降のバージョンはOpenSSLを利用したハードウェア 暗号処理アクセラレータのサポートが含まれています。まだ誰もそれを テストしていません。誰かこれをテストしてどんな具合かを私達に 報告してくれませんか？
- "ファジング" を使ってTorに対してセキュリティ分析を実行してください。 世の中に私達が望んでいるような用途に向いた良いファジングライブラリが あるかどうか調べてください。もしあなたのおかげで新しいリリースを 出すことが出来たら、その貢献は大いに感謝されるでしょう。
- TorはトランスポートにTCPを、接続の暗号化にはTLSを使用しています。 これは簡単で良い実装なのですが、それはある接続上で一つのパケットがドロップ されるとその接続上のすべてのセルが遅延してしまうこと、従って TCPストリームしかサポートできない理由がある、ことを意味します。 私達が未だにUDPトランスポートへ移行していない理由のリストがありますが、 このリストがもし今よりも短くなるのなら素晴らしいことです。 この他にも、提案中の TorとUDPの仕様がありますーもしこれに誤りが含まれていたら 私達に知らせてください。
- 目的アドレスにIPv6アドレス(出口ノードにおいて)をサポートできるように なるのもそう遠い話ではありません。もしIPv6に強い関心がおありなら、 おそらくまずここから始めるがよいでしょう。
- これらのうち、何か気に入らない点がありますか？詳細は Tor開発ロードマップ をご覧ください。
- あなたのアイディアがここに載っていない？たぶんそのアイディアが 何であっても私達はそれを必要としています。私達にコンタクトを取って 尋ねてみてください。
リサーチ
- "ウェブサイトフィンガープリント攻撃": 数百におよぶ人気のあるウェブサイトのリストを作成してそれらのページを ダウンロードし、サイト毎に"シグネチャ"のセットを作ります。その上で、 Torクライアントのトラフィックを監視します。あるクライアントが データを受信したのを観察したら、すばやくどのサイト(もし件のリストに 該当するものがあれば)にアクセスしたのかを訪れたのかの推測を 試みるのです。第一に、この攻撃は配備済みのTorコードベースに対して どの程度有効なのでしょうか？次にこれに対する防御について 考えてみましょう: 例えば、Torのセルサイズを512バイトから 1024バイトに変更する、 ディフェンシブドロッピングと同様のパディングテクニックを採用する、 あるいはトラフィック遅延を加えることが考えられます。 これらの対策を採用して防御に成功した場合、その影響はどれくらいで、利便性は どの程度(何か適当な測定基準を用いて)の影響を被ることになるでしょうか？
- "エンドツーエンドトラフィックコンフォメーション攻撃": アリスおよびボブの地点でトラフィックを監視することにより、 トラフィックシグネチャを比較することで同じストリームを監視している ことに確信を持つことができます。これまでのところ、Torはこの 攻撃のついてはやむを得ないことでどのような場合でもこれは些細な ことに過ぎないと考えてきました。そもそも、それは本当に可能な 方法なのでしょうか？敵が勝利を確信するまでにいったいどのような 種類の、どれだけ多くのトラフィックが必要となるのでしょうか？ 攻撃をスローダウンさせるようなシナリオ(例えば転送量が少ないとか) があるのでしょうか？トラフィックパディングまたはトラフィック シェイピング手法は他の手段より有効でしょうか？
- "ルーティングゾーン攻撃": ほとんどの資料では、アリスとその入口ノードとの間 (および出口ノードとボブとの間)は、あるグラフ上の 単一のリンクと捉えられています。しかしながら、実際にはこのパスは 多くの自律システム(AS)を横断することになり、 同じASが入口パスと出口パスとの両方に出現することは稀です 。残念ながら、アリス、入口ノード、出口ノード、ボブの四者ともが 危険であると予測するためには、インターネットルーティングゾーン全体を ダウンロードしてそれに対して高価な操作を加えなければなりません。 単一の/8ネットワーク内で同じIPアドレスを避けるというようなケースに 関する実地の概算は存在しないでしょうか？
- 他の地理的多様性に関連したリサーチ質問は、効率的な回路を選択する こととランダムな回路を選択することとの間のトレードオフについて 言及しています。匿名性を"著しく"損なうことなく特に遅い回路を 捨てる方法について書かれたStephen Rollysonの ポジションペーパーをご覧ください。この論証についてはさらに多くの 作業と思索が必要ですが、非常に有望と思われます。
- Torは、サーバが非対称の帯域幅を持つ場合(ケーブルないしDSL)にはあまり うまく機能しません。Torは各ホップ毎に個別のTCPコネクションを 張るので、入力バイトが順調に到着する一方で出力バイトが床にこぼれて しまっていると、TCPのプッシュバック機構はこの情報を入力 ストリームに対してちゃんと返送することができないのです。 恐らく、Torは自身で出力パケットの多くがドロップされている場合にこれを 検出して、入力ストリームに対してレート制限をすることでこれを 調整するべきでしょうか？まず控えめなレート制限を掛け、そこから 徐々にレートを上げて行き、ロストパケットが出た時点で戻し、また繰り返す ーといったビルドアップ・ドロップオフ手法を想像できます。 私達は、これをネットワークでシミュレートして設計を助けてくれる 適当な方を探しています;さらに／またはパフォーマンス低下の限度を 知る必要があり、このことをUDPトランスポートを再考慮する動機と したいと考えています。
- 関連する話題として、輻輳制御の問題があります。現在の私達の デザインは負荷の高い使用に耐えうるものなのでしょうか？恐らく、 私達は固定ウィンドウサイズよりも可変ウィンドウサイズを試して 見るべきでしょうか？SSH スループット実験を見る限りうまく行っているように見えますが。 私達は測定して調整する必要があるでしょう。そして結果が良ければ より徹底した調査をすることになるでしょう。
- 遠く離れた国々に住む人々がその国のファイアーウォールにブロック されることなくTorを使うことができるようにするためには、数百の リレーだけでは足りず、数万のリレーを可能にする方法が必要です。 トップに"自由のためのTor"ボタンを持ったTorクライアントGUIを想像 することができます。そのボタンを押すと、ポートが開かれて数KB/sの トラフィックがTorネットワークに中継されるわけです。(数KB/sは 迷惑な量ではないはずですし、彼らは出口ノードになるわけではないので 悪用の問題もあまりありません。)しかし、それらのボランティア クライアントのリストを善き住民たちにどうやって国レベルの ファイアーウォールに遮断されない、自動化された方法で 配布することができるでしょうか？恐らくは人的信頼関係上の 仕事が必要となることでしょう。私達の 初期抗ブロッキングデザインドキュメントおよびその FAQエントリをご覧ください。その後、 anonbibの抗検閲に関するセクション
- Tor回路は一度に一ホップずつ構築されるので、理論的には二番目のホップ であるストリームを回路から離脱させ、三番目のホップでもまた別のストリーム を離脱させ、以下同様にすることが可能です。これはあるサーバから見ることの できる出力ストリームを分割することになるので良い方法だと思われます。 しかし、各ストリームについて安全性を確保しようということになると、 私達の現在の理論によれば、安全な"最短の"パスは少なくとも3ホップの長さを 持っている必要があるため、残りはさらに長くなってしまいます。この パフォーマンス／セキュリティのトレードオフを検討する必要があります。
- Torサーバやディレクトリサーバに対してDoS攻撃を仕掛けることは そんなに難しいことではありません。クライアントは正しい答を得られずに 頭を悩ますでしょうか？他のアプローチもあるでしょうか？もしこれを 現在のTorプロトコルとの後方互換のまま修正できたらなお良いです。