今すぐに誰にでもできるいくつかのこと:
- 私達のTorネットワークを成長させるためにリレーを運用する ことをご検討ください。
- あなたの友人にも伝えてください！彼らにもリレーを運用し、またはヒドゥンサービスを 運用するように、そして彼らの友人にそれを伝えるように伝えてください。
- もしあなたがTorの目的に賛同なさるなら、 Torの開発に対してより深くサポートするために貢献してください 私たちはより多くのスポンサーも求めていますー もしあなたが匿名性/プライバシー/コミュニケーションの安全性を望んでいる 会社、NGO、機関、その他の組織を ご存知なら私たちに知らせてください。
- 私たちはより多くのTorのよいユーザ例および使用例 探しています。もしあなたがこのページにまだ書かれていないようなシナリオや目的の ためにお使いなら、もし差し支えがなければそれを私たちにも知らせて頂けると幸いです。
補助アプリケーション
- 匿名になろうとしているときに、これに反してDNSリクエストがその内容を ローカルの盗聴者に"リーク"してしまわないようにそれらを遮断するするよい方法を探しています。 (アプリケーションがSOCKSプロキシに到達する前にDNS解決を行うために起こることです。)
- tsocks/dsocksアイテム:
- tsocksパッチを当て、新たな子プロジェクトを管理する必要があります。 もし必要なら私達が新プロジェクトをホスティングします。
- Torのmapaddressコマンドをコントローラインターフェースから使えるように するためDug Songの"dsocks"プログラムにパッチを当てる必要があります。 これによって接続前に一通り名前解決を行う作業をTor内部で無駄にせずに済みます。
- tsocksとdsocksのどちらがインストールされているのかを検知し、 適切にそれらを呼び出すtor化スクリプトを作る必要があります。 このためには、恐らくインターフェースを統一したうえで、それらの間で コードを共有するようにするか、またはどちらか一方を完全に捨て去ること も必要になるかも知れません。
- リレーを運用している人々は私達に対して、一日のうちのある時間帯だけに ある帯域レートを適用し、残りの時間帯には別の帯域レートを適用したいという 要望をしてきます。これをTorの内部でコーディングするよりも、 Torコントローラインターフェースを通じて動作し、帯域レートを変更するための設定を 行う小さなスクリプトがあったほうがいいでしょう。UnixおよびMac用のものは すでにあります(それはbashとcronを使用しています)が、Windowsユーザについては 依然として解決が求められています。
- 地理位置データについて言えば、誰かがTorリレーの位置を表す世界地図を 描く必要があります。ネットワークが成長し変更されるにつれ情報が自動的に アップデートされるものなら、なお良いです。残念ながら、 これを実現する最も簡単な方法は、全てのデータをGoogleに送信して地図を描いて もらうことになってしまいます。この方法がプライバシーに与える影響はどの程度の ものでしょうか？あるいは他にもっといい選択肢があるでしょうか？
支援運動
- Creative Commonsライセンスの下、コミュニティのロゴを作ってすべての人々がそれを使用し またそれを変更できるようにすること。
- 世界中のユーザグループミーティングで使用できるようなプレゼンテーションを作成すること。
- あなたが推薦するTorの使い方についてのビデオを作成すること。これは一部ですでにSeesmicで 作成が始まっています。
- 「自由のためにTorを使おう！」といったような、 単一のまたはいくつかの主題についてのポスターを作成する。
ドキュメント
- Matt Edmanが自身の作ったTorコントローラ Vidalia のためのドキュメントおよびhow-toを書くのを手伝ってください。
- Torを使用するために使用できる 私達のプログラムリスト にあるプログラムを使ってみて結果を報告してください。
- 私達は動的に接続を遮断してそれをTorを通して送信することについてのよりよい ドキュメントを必要としています。私達の新しいTransPort機能のよりよい使用法に ついてもそうですが、tsocks (Linux), dsocks (BSD),freecap (Windows) がよい候補として挙げられるでしょう。
- Torの有用なインターフェースとなりうるプログラムの巨大なリストがあります。 どのプログラムがどういった状況で使えるでしょうか？それらをテストして 結果を報告してください。
- ウェブページおよびドキュメントを他の言語に翻訳するのを手伝ってください。 手伝ってくださる方は翻訳ガイドライン をご覧ください。検閲が行われている地域に住む多くのTorユーザのために、 特にアラビア語またはペルシア語の翻訳を特に必要としています。
Good Codingプロジェクト
これらのプロジェクトのうちのいくつかがGoogle Summer of Code 2009用のよいアイディアになると思われる かも知れません。私たちはそれぞれのアイディアについて、それがTorプロジェクト 全体にとってどの程度役に立つか(優先順位)、それを実現するために どの程度の作業を要すると予想されるか(作業レベル)、どれだけの手掛かりから 作業を始めなければならないか(スキルレベル)、私たちの中心的開発者たちのうちの誰がそれに助言をしたらいいかに よってラベル付けを施しました。もしこれらのアイディアのうちの一つまたは いくつかが有望だと思われた方は、分りにくい用途を送り付けるよりもむしろ あなたの計画について議論を交わすためにご連絡ください。 あなた自身のプロジェクトのアイディアを提案してくださっても構いません。その方が 往々にして最善の用途となることが多いものです。
-
Linux/Mac OS X向けTorブラウザバンドル
Priority: High
Effort Level: High
Skill Level: Medium
Likely Mentors: Steven, Andrew
TorブラウザバンドルにはTor、Firefox、Vidaliaユーザインターフェース(そして オプションでPidgin IM)が含まれます。コンポーネントは安全に操作できるように 予め設定されており、インストール先のOS上でほんの少しの依存性しか持ちません。 そのためこのバンドルはWindows上でTorを利用するための方法のうちで最も 使いやすくて人気のあるものとなっています。
しかしながら、LinuxやMac OS Xのためのこれと同等のパッケージは今のところ存在 していません。そこでこのプロジェクトではこれらのプラットフォームのためにTor ブラウザバンドルを実装することになるでしょう。この作業には、Vidalis(C++)および 恐らくはFirefox(C)にも変更を加え、可搬性を評価するために一定の範囲のOSバージョン についてランチャを作成してテストすることが含まれるでしょう。
生徒諸君はLinuxまたはMac OS Xのうちのどちらかまたは両方でのアプリケーション 開発に習熟していなければならず、C/C++およびシェルスクリプトに慣れ親しんで いなければならない。
このプロジェクトの一部にはTorブラウザバンドルの利便性テストー理想を言えば 私たちがターゲットとしている層におけるーが含まれるかも知れません。 それはバグフィクスないし新機能の方面で何が必要とされているのかを知るのに 大いに役立つでしょう。当面のところこれは非公式のものとしておきますが、 より構造化されたプロセスとするほうがよいでしょう。 -
私たちのウェブサイトのための翻訳wiki
Priority: High
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Jacob
Torプロジェクトはここ数年の間、ボランティアが私たちのアプリケーションを 他の言語に翻訳するのを助けるウェブベースのツールをセットアップするために 作業を続けてきました。最終的に私たちはPootleに行きあたりました。これを 使えば、Vidalia、Torbutton、Torcheckのためのウェブベースの翻訳エンジンを 使えるようになります。しかしながら、Pootleは"po"形式のファイル内の文字列 しか翻訳できない一方、私たちのウェブサイトはwmlファイルを使用しています。 このプロジェクトは私たちのwmlファイルをpo文字列へと変換および逆変換する 方法を見付けてそれらがPootleによって扱えるようにすることについてのものです。 -
Torネットワーク全体のステータスを追跡記録するのを助ける
Priority: Medium to High
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Karsten, Roger
時間を追ってネットワークの健康状態を追跡記録し、それをグラフ化等する 自動化されたシステムを完成させられたら素晴らしいことです。 このプロジェクトの一部には、ネットワークの健康状態と成長を評価する よりよい指標を考案することが含まれるでしょう。ネットワークの平均 稼働時間は増加しているか？今月は先月に比べていくつのリレーがGuardステータス と認められているか？新しく参加したリレーと停止されたリレーとの交代数は？ 定期的に人々が短時間のスナップショットを収集するようですが、本当に 興味深くなってくるのはこれを時間経過を追ってデータポイントを記録し 始めたときなのです。
データはTorFlowの Tor Network Scannerで各リレーが公開しているサーバデスクリプタから、 もしくはその他のソースから収集することができます。 時間経過に伴う結果はTor Statusのウェブページに 統合することもできるでしょうし、個別のままでおくこともできるでしょう。 Tor Statusページについては、Rogerの Tor Status要望リストを見てみてください。 -
Torの検閲に抵抗する能力を向上させる
Priority: Medium to High
Effort Level: Medium
Skill Level: High
Likely Mentors: Nick, Roger, Steven
Tor 0.2.0.xシリーズは国家や組織による検閲に対して抵抗力に関して 著しい進歩 を遂げています。しかし、Torは依然としてその反検閲の設計のいくつかの 部分についてよりよいメカニズムを必要としています。例えば、 現在のTorは同時に単一のアドレス/ポートをリッスンすることしか できません。 この制限に対処する提案がなされていますが、これについてはまだ作業が 必要です。これによってクライアントは 任意の与えられたTorに対して複数のアドレスおよびポートで接続することができる ようになります。もう一つの（ずっと難しい)反検閲プロジェクトは、Torをより スキャニングに対して抵抗力のあるものにする試みです。現在の時点では、 攻撃者はTorのプロトコルに従いそれらに対して接続を試みるだけで Torブリッジ を識別することができます。この問題を解決するには、ブリッジはポートスキャニング ツールでコンタクトされたときには ウェブサーバの ように振る舞い(HTTPまたはHTTPSで)、ユーザがブリッジ固有の鍵を与えない限り ブリッジとして振る舞うことがないようにすることが考えられます。
このプロジェクトには多くの調査や設計が含まれます。大きな挑戦のうちの一つとして、 攻撃者が設計を知った後でもなお攻撃に耐えうるようなアプローチを特定してうまくそれを 作成したうえで、検閲に対する抵抗力と利便性および堅牢性とをトレードオフすることが あります。 -
Torをチューンアップしよう！
Priority: Medium to High
Effort Level: Medium to High
Skill Level: High
Likely Mentors: Nick, Roger, Mike, Karsten
現在のところ、Torリレーは自身の帯域幅を測定して報告し、Torクライアントは ある程度この帯域幅に基づいてどのリレーを使用するかを選択しています。 このアプローチは、 リレーが自身の帯域幅について嘘をつく攻撃に晒される危険を有しています; この問題を解決するために、Torは現在のところ、すべてのリレーが提供する 帯域幅に対して信用する上限値を設定するようにしています。これは限定的な 修正に過ぎず、用意する帯域容量の無駄です。そのかわりに、Torはおそらく より分散的なやり方ー恐らくはSnaderとBorisovによる "A Tune-up for Tor"の文書に述べられているように、より分散的なやり方で帯域を計測すべき でしょう。この文書の結論を再調査してそれがどの程度実際に配置された Torに適合するか検証し、Torネットワークにあまり多くの交信オーバーヘッドを 課すことなくその結果を彼等の提案に取り込むための良い方法を 見付けるために、現時点でのテストコードを使用することができます。 -
Windows上のPolipoを改良する
Priority: Medium to High
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Martin
Polipo をWindowsに移植するのを手伝ってください。取り組むべき課題の例としては 以下のようなものが挙げられます: 1)ネームサーバに非同期に問い合わせ、システムネームサーバを探索し、 netbiosおよびdnsのクエリを管理する能力 2)イベントおよびバッファをネイティブに管理すること(Unix系OSではPolipoは ramの25%まで使用するのがデフォルトですが、Windowsでは設定次第です)。 3)何かGUIによる設定および報告のためのツールのようなものが必要です。 それが右クリック可能なメニューオプション付きのシステムトレイアイコン を持っていればなお良く、さらにそれがクロスプラットフォーム互換なら なおさら良いでしょう。 4)ソフトウェアがWindowsのレジストリを使用し、"C:\Program Files\Polipo" のようなWindowsの正しいディレクトリの位置を扱うことを可能にすること。 -
Thandyパッケージをダウンロードするためのトーレントに基づいたスキームを実装する
Priority: Medium to High
Effort Level: High
Skill Level: Medium to High
Likely Mentors: Martin, Nick
Thandy はTorおよび関連するソフトウェアのアップデートを支援する、比較的新しいソフトウェアです。 現在のところこのソフトウェアを使用しているユーザは非常に少ないのですが、私たちは 将来的にはすべてのTorユーザにThandyを使用してもらいたいと思っています。 Torをアップデートすべき日にサーバをクラッシュさせないために、私たちは新しい パッケージを効率的に配布する新しい方法を必要としています。libtorrentを使用することが解決策 として考えられます。もしあなたがその他のよい考えをお持ちでしたら、それは素晴らしいことです -是非私たちにそれを教えてください！
私たちはまた、ミラーサーバを含めるよい方法を調査する必要があります。できればそれは、 パッケージを配布するのを助ける簡単な方法によるべきでしょう。 -
Torコントローラステータスイベントインターフェース
Priority: Medium
Effort Level: Medium
Skill Level: Low to Medium
Likely Mentors: Matt
ユーザが知りたいと思う幾つかのTorの内部ステータスの変化があります。 例えばユーザが自分のTorをリレーとしてセットアップしようとしている 際、Torがそのポートが外部から到達できないことを検知した場合には、 ユーザに警告を発するべきです。現在のところ、ユーザが得られるものは Vidaliaの'メッセージログ'内の二行のログメッセージだけですが、 ユーザは何かがまずいことになっているという通知を受け取っていないため、 それを見過ごしてしまう傾向があります。ユーザが実際にそのメッセージ ログを見た場合でも、初心者ユーザにとってその多くはほとんど意味を なさないでしょう。
Torはそういったステータスの変化をVidaliaに知らせる能力を持っており、 最近になってそれらのイベントの幾つかをサポートする実装をしました。 しかしユーザが知らされるべきステータスイベントはまだ多く残っており、 私たちは実際にそれらをユーザに対して表示するよりよいUIを必要と しています。
このプロジェクトの目的はそうすると、Torのステータスイベントをユーザに 対して表示するUIを設計し実装することにあるということになります。 例えばVidaliaのトレイアイコン上に、ユーザに彼等が見るべき新たな ステータスイベントを警告する小さなバッジを付けることが考えられる でしょう。アイコンをダブルクリックすると、最近起こったステータスイベント がわかりやすい用語でまとめられたダイアログが表示され、そこには ユーザが修正可能な場合には否定的なイベントに対する対処法が提示される、 といった具合です。むろんこれは一例にすぎませんから、他のアプローチを 提案することは自由です。
このプロジェクトを遂行する人物は良いUIデザインおよびレイアウトが出来、 いくらかのC++開発経験がなければいけません。QtおよびQtのデザイナを 経験済みならそれはとても役に立つでしょうが、必須というわけでも ありません。このプロジェクトには非技術者ユーザでも理解できなければ ならないヘルプドキュメントを少し書くことが含まれることになりそう なので、英文を書く能力が多少あればそれも役に立つでしょう。 私たちは新しい光るアイコンを幾つか欲しい/必要としているので、 グラフィックデザイン/Photoshop fuが使えればなおよいでしょう。 -
私たちのユニットテストプロセスを改良する
Priority: Medium
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Nick, Roger
Torにはまだまだテストが必要です。これは多方面にわたる作業になります。 手始めに、私たちのユニットテストがカバーする範囲ーとりわけ ユーティリティ関数以外の領域におけるーを大幅に増やさなければ なりません。これには、グローバルスコープからロジックを切り離すために Torのいくつかの部分について大規模なリファクタリング が必要になるでしょう。
さらに、私たちのパフォーマンステストを自動化する必要があります。 私たちはすでに私たちのregular integrationを自動化しテストコードを コンパイルするためのbuildbotを持っています(Windowsでそれを セットアップしてくれる方が必要ですが)が、私たちのネットワーク シミュレーションテスト(TorFlow にある)をより最近のTorのバージョンに合わせてアップデートし、 単一のマシンまたは複数のマシン上でネットワークテストを起動して 自動的に異なる役割におけるマシンのパフォーマンスの変化をテストすることが 出来るように設計する必要があります。 -
独立したTorクライアント実装の復活を助けてください
Priority: Medium
Effort Level: High
Skill Level: Medium to High
Likely Mentors: Karsten, Nick
TorのクライアントをJavaで実装するアプローチのうちの一つ、例えば OnionCoffee プロジェクト を復活させ、Android上で動くように しましょう。手始めとして既存のコードを移植してAndroid環境でそれを 実行することになるでしょう。次に、そのコードが v3ディレクトリプロトコル のようなより新しいバージョンのTorプロトコルをサポートするように アップデートしなければなりません。さらに、Torのヒドゥンサービスに アクセスしさらにはそれを提供する機能をもサポートするなら行き届いたもの になるでしょうが、それは必須というわけではありません。
これにあたる開発者はJavaの暗号APIを含む新しいJavaコードを理解してそれを 書くことができなければなりません。Cのコードを読めるならそれも役に立つ でしょう。既存のドキュメントを読み、それに基づいてコードを実装し、 ドキュメント化されていない項目があればドキュメントを改良していく意欲の ある方でなければなりません。このプロジェクトのほとんどの部分は コーディングに関するもので設計には少ししか関係しません。 -
Torbuttonの新機能
Priority: Medium
Effort Level: High
Skill Level: High
Likely Mentors: Mike
Torbutton Flysprayの節の よい機能のリクエストにいくつかあります。特に、 '新しいID'をVidaliaに組み込む 、 複数のクッキーjarおよびIDを管理する方法 、 クッキーがクリアされる場合に 特定のクッキーを保存する 、 よりよいリファラースプーフィング , 正しいTorステータスの報告 、そして "tor://"および"tors://"URLはすべて、もし実現できれば面白い機能です。
この作業はJavascriptの独立したコーディングとXUL ファンの世界になり、Torの中身とはそれほど関係しないものになるでしょう。 -
新しいThandyの機能
Priority: Medium
Effort Level: Medium
Skill Level: Medium to High
Likely Mentors: Martin
Windowsおよびその他のOSのためのTor関連ソフトウェアのアップデート補助の 追加的機能が必要です。考えられる機能としては以下のようなものが挙げられます: 1)認証付きHTTPSダウンロードのためのMeTooCrypto Python ライブラリ。 2)タイムスタンプシグネチャとアップデートに含まれるパッケージファイルとの間 の迂回レベルを追加する。or-devの"Thandy attacks / suggestions"を参照。 3)設定、ホスト、ユーザアカウント言語設定に基づき、 アップデート補助のロケールごとのインストールと設定をサポートする。 win32およびposix API全般の経験とPythonに習熟していることに加え、 Windowsコードページ、ユニコードおよびその他の文字セットに通じているとなお可。 -
遅いインターネット接続のシミュレータ
Priority: Medium
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Steven
多くのTorユーザは、狭い帯域幅、高いレイテンシ、高いパケットロスおよび再順序化を 伴う低質なインターネット接続を利用しています。ユーザ経験上、 Torはこういった接続に対してはよい反応を示しません。しかし、 問題を研究室で再現可能にせずしてこの状況を改善することは困難です。
このプロジェクトでは貧弱な接続を再現するシミュレーション環境を 構築して、それがTorのパフォーマンスに与える影響を測定することが できるようにすることになるでしょう。それ以外の要素としては、 使用可能な接続の条件が何かを決定し、Torのパフォーマンスを向上させる 変更の効果を測定するテストユーティリティが挙げられるでしょう。
使用するツールは研究者にお任せしますが、dummynet(FreeBSD)および nistnet(Linux)はこのプロジェクトがその基礎とすることのできる 有力なコンポーネントです。研究者はネットワークプログラミング/ デバッギングおよびTCP/IPに通じていなければならず、できれば Cと一つのスクリプト言語に慣れ親しんでいることが望まれます。 -
Vidaliaのネットワークマップを改善してより使いやすいものにする
Priority: Low to Medium
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Matt
Vidaliaの既存の機能の一つとして、Torネットワーク上のリレーのおおまかな 地理的位置をユーザに対して表示し、ユーザの行った通信がTorネットワークを 通っていくに従ってそのパスを描画する、ネットワークマップがあります。 マップは現在のところあまりインタラクティブではなく、そのグラフィックは かなり貧弱です。これに代えて、私たちはKDEのMarbleウィジットを実装して より品質の良いマップを提供できるようにし、双方向性を向上させてユーザが 個々のリレーをクリックしたり回路についての追加的情報を表示させることが 可能になりました。私たちは、ユーザが特定のリレーまたは一個以上のTor出口 リレーが存在している国をクリックして、「私の接続はここから出て欲しい。」 と言えるような機能を追加したいと考えています。
このプロジェクトにはまずVidaliaおよびMarbleウィジットのAPIに慣れ親しむこと が伴うでしょう。そののちにウィジットをVidaliaに統合しMarbleをカスタマイズ して私たちのアプリケーションにより適合するようにすることになるでしょう。 それは例えば回路をクリック可能にすること、キャッシュされたマップデータを Vidaliaの独自のデータディレクトリに格納すること、あるいはウィジットの ダイアログのうちのいくつかをカスタマイズすることなどです。
このプロジェクトを遂行する人物は、C++開発について十分な経験を有している 必要があります。QtおよびCMakeについての経験があればなおよいですが、 これは必須ではありません。 -
moniTorを誕生させる
Priority: Low
Effort Level: Medium
Skill Level: Low to Medium
Likely Mentors: Karsten, Jacob
Torリレーのためのtopに似た 管理ツールを実装します。こういったツールの目的は、その制御ポートを通じて ローカルのTorリレーをモニターし、実行しているマシンの有益なシステム情報 を盛りこむことです。このツールはtopがLinuxのプロセスに対してするのと 同様、実行中にそのコンテンツを動的に更新することになるでしょう。 この or-devの投稿をまず始めに読むといいでしょう。
これに興味をお持ちの方は、Torリレーを管理することおよびそれを制御ポートを 通じて調整することについて熟知しているかまたは学ぼうとする意欲があることが 必要です。最初のプロトタイプはPythonで書かれていますので、Pythonを書くこと についてのいくらかの知識があればそれも役に立つでしょう。 このプロジェクトはこういったツールに対する機能要求を同定することおよび そのインターフェースをデザインすることと、多くのコーディングを行うこととの 二つの部分に分けられます。 -
ThunderbirdにもTorbuttonと同等のものを
Priority: Low
Effort Level: High
Skill Level: High
Likely Mentors: Mike
ThunderbirdをTorとともに使いたいというユーザが増えていると聞いています。 しかしながら、それを実現するにはアプリケーションレベルにおける多くの課題 があります。例えば、Thunderbirdはデフォルトであなたのホスト名を送信する メールに出力してしまいます。いずれかの時点で私たちはTorbuttonに似た Thunderbird拡張を作成するための新たな行動を起こすべきでしょう。 -
中間レベルネットワークデバイスドライバ
Priority: Low
Effort Level: High
Skill Level: High
Likely Mentors: Martin
ブリッジを使用するネットワーキングのためにTorVMによって使用される WinPCAPデバイスドライバは、いくつかの無線および非イーサネットネットワーク アダプタをサポートしていません。win32および64ビット用の 中間レベルデバイスドライバの実装があれば、そういったネットワーク上で 通信を遮断したりルーティングしたりする道が開けます。 このプロジェクトはWindowsのカーネルデバイスドライバ開発およびテスティングの 知識と経験を必要とするでしょう。WinsockおよびQemuについてよく知っていれば それも役に立つでしょう。 -
新しいアイディアを出してください！
これらのうちのどれも気に入らない？ Tor開発ロードマップ を見てその他のアイディアを探してみてください。 現在の提案のうちのいくつかもまた、 開発者にとっては手短かに過ぎるかも知れません。
その他コーディングおよび設計に関するアイディア
- TorリレーがWindows XP上でうまく動きません。Windows上では、 Torは非ページプールメモリを使用する標準のselect() システムコールを使います。これは、中規模のTorリレーが非ページプールメモリ を喰い潰してしまい、 大混乱とシステムクラッシュを引き起こす ことを意味します。恐らく代わりに オーバーラップIOを使用しなければならないでしょう。解決策の一つは、 libevent にWindows上でselect()ではなくオーバラップIOを使用する方法を教え、 Torを新しいlibeventインターフェースに適合させることでしょう。 Christian Kingが2007年の夏にこれについての よい出発点 を作ってくれました。
- 抗ブロッキングデザインの設計を実際に 始めなければなりません。その作業には、デザインを具体化し、Torの多くの様々な 部分を変更しVidaliaを Torの新しい機能をサポートするように変更して実際に配備できる ように準備することが含まれます。
- 私達はエンドツーエンドトラフィックコンフォメーション攻撃を研究する ための柔軟なシミュレーションフレームワークを必要としています。 多くの研究者が、彼らの「この攻撃はうまくいくだろう」あるいは「ある防御方法が 大いに有効に違いない」という直観を証明するためにアドホックなシミュレータを 早くも設計しています。すべての人々がその正当性を知ることが出来るように 十分にドキュメント化されオープンであるようなシミュレータを作成することが できないでしょうか？これには多くの新たなリサーチが必要となるでしょう。 コンフォメーション攻撃のこのタスクの研究側の詳細については 下のエントリをご覧くださいー時期は未定ですが、 それが完了した時には文書を書くのを手伝ってもらえると思います。
- Tor 0.1.1.xおよびそれ以降のバージョンはOpenSSLを利用したハードウェア 暗号処理アクセラレータのサポートが含まれています。これはまだ簡単にしか テストされておらず、恐らくはバグが多く残っていることでしょう。 私たちはより厳密なテスティング、パフォーマンス分析、そして出来れば必要に応じて openssloおよびTorに対するコード修正を探し求めています。
- "ファジング" を使ってtorに対してセキュリティ分析を実行してください。 世の中に私達が望んでいるような用途に向いた良いファジングライブラリが あるかどうか調べてください。もしあなたのおかげで新しいリリースを 出すことが出来たら、その貢献は大いに感謝されるでしょう。
- TorはトランスポートにTCPを、接続の暗号化にはTLSを使用しています。 これは簡単で良い実装なのですが、それはある接続上で一つのパケットがドロップ されるとその接続上のすべてのセルが遅延してしまうこと、従って TCPストリームしかサポートできない理由がある、ことを意味します。 私達が未だにUDPトランスポートへ移行していない理由のリストがありますが、 このリストがもし今よりも短くなるのなら素晴らしいことです。 この他にも、提案中の TorとUDPの仕様がありますーもしこれに誤りが含まれていたら 私達に知らせてください。
- 目的アドレスにIPv6アドレス(出口ノードにおいて)をサポートできるように なるのもそう遠い話ではありません。もしIPv6に強い関心がおありなら、 おそらくまずここから始めるがよいでしょう。
- ウェブサイトのダイアグラム(例えば 概要ページの"Torはどうやって動くのか"の図) をGimpで手動で編集せずにそれをUTF-8のテキストに翻訳できるように、 ソースから生成する方法を必要としています。 私たちがウェブサイトを構築するときはいつでも翻訳が簡単で画像が複数の言語で 生成されるように、それをwmlファイルとして統合することができればよいでしょう。
- Incognito LiveCD のメンテナンス、改良、ドキュメントをどうやったらより簡単にできるでしょう？
リサーチ
- "ウェブサイトフィンガープリント攻撃": 数百におよぶ人気のあるウェブサイトのリストを作成してそれらのページを ダウンロードし、サイト毎に"シグネチャ"のセットを作ります。その上で、 Torクライアントのトラフィックを監視します。あるクライアントが データを受信したのを観察したら、すばやくどのサイト(もし件のリストに 該当するものがあれば)にアクセスしたのかを訪れたのかの推測を 試みるのです。第一に、この攻撃は配備済みのTorコードベースに対して どの程度有効なのでしょうか？次にこれに対する防御について 考えてみましょう: 例えば、Torのセルサイズを512バイトから 1024バイトに変更する、 ディフェンシブドロッピングと同様のパディングテクニックを採用する、 あるいはトラフィック遅延を加えることが考えられます。 これらの対策を採用して防御に成功した場合、その影響はどれくらいで、利便性は どの程度(何か適当な測定基準を用いて)の影響を被ることになるでしょうか？
- トラフィックシグネチャを比較することで同じストリームを監視している ことに確信を持つことができます。これまでのところ、Torはこの 攻撃のついてはやむを得ないことでどのような場合でもこれは些細な ことに過ぎないと考えてきました。そもそも、それは本当に可能な 方法なのでしょうか？敵が勝利を確信するまでにいったいどのような 種類の、どれだけ多くのトラフィックが必要となるのでしょうか？ 攻撃をスローダウンさせるようなシナリオ(例えば転送量が少ないとか) があるのでしょうか？トラフィックパディングまたはトラフィック シェイピング手法は他の手段より有効でしょうか？
- 関連する疑問:リレーやブリッジを運用することはこれらの タイミング攻撃に対する追加的防御となるのでしょうか？TLSリンクの内部を 見ることができない外部の攻撃者は確実に個々のストリームを識別することが できるのでしょうか？通信量を増加させることでこの能力を少しでも低減させる ことができるのでしょうか？クライアントリレーがキューを作成して中継している 通信のアップをわざと送らせ、そのキューを使用してクライアントの ダウンストリームも中継されたもののように見せかけるためにそのタイミングを 模擬するのはどうでしょう？この同じキューは、adaptive padding と同じ技術を用いて、しかし余分な通信を追加せず、クライアントの アップストリーム通信のタイミングにマスキングを施すのに使うことが できるかもしれません。このようにクライアントのアップストリーム通信に 間を置くことは、外部の攻撃者から見てタイミングを曖昧にする働きが あるでしょうか？非対称リンクの場合には戦略を調整する必要があるでしょうか？ 例えば非対称リンクの場合、その非対称的容量ゆえにクライアントの通信を 通常の通信から区別することが実際に可能になるのでしょうか？ それとも対称的リンクにおけるよりもそれが他の何らかの理由で より容易になるのでしょうか？
- MurdochとDanezisの Oaklandからの攻撃 05を現在のTorネットワーク上で再現してください。 あるノードはうまく動き他のノードではうまく動かない理由が分かるか どうかを確かめてください。(私の理論では容量に余裕のある速いノードは 攻撃に対してより抵抗力が強いことになります。)もしそれが本当なら、 RelayBandwidthRateおよびRelayBandwidthBurstオプションをいろいろ 試しながら、攻撃者からの通信を中継しつつクライアントとしても 使用されるリレーを動かしてみてください:RelayBandwidthRateを下げると 攻撃はより難しくなるでしょうか？実際の容量として正しいRelayBandwidthRate の比率はどれだけでしょう？そもそもそれは比率の問題なのでしょうか？ 私たちがそれに取り組んでいる一方で、より多くのリレー候補の集合が 攻撃側の誤診率や別の複雑さを増加させてはいないでしょうか？ (Torネットワークはかつてこの文書が書かれた当時と比較して、 現在だいたい2乗の規模になっています。) Don't Clog the Queueも必ずお読みください。
- "ルーティングゾーン攻撃":ほとんどの資料では、 アリスとその入口ノードとの間 (および出口ノードとボブとの間)は、あるグラフ上の 単一のリンクと捉えられています。しかしながら、実際にはこのパスは 多くの自律システム(AS)を横断することになり、 同じASが入口パスと出口パスとの両方に出現することは稀です 。残念ながら、アリス、入口ノード、出口ノード、ボブの四者ともが 危険であると予測するためには、インターネットルーティングゾーン全体を ダウンロードしてそれに対して高価な操作を加えなければなりません。 単一の/8ネットワーク内で同じIPアドレスを避けるというようなケースに 関する実地の概算は存在しないでしょうか？
- 他の地理的多様性に関連したリサーチ質問は、効率的な回路を選択する こととランダムな回路を選択することとの間のトレードオフについて 言及しています。匿名性を"著しく"損なうことなく特に遅い回路を 捨てる方法について書かれたStephen Rollysonの ポジションペーパーをご覧ください。この論証についてはさらに多くの 作業と思索が必要ですが、非常に有望と思われます。
- Torは、サーバが非対称の帯域幅を持つ場合(ケーブルないしDSL)にはあまり うまく機能しません。Torは各ホップ毎に個別のTCPコネクションを 張るので、入力バイトが順調に到着する一方で出力バイトが床にこぼれて しまっていると、TCPのプッシュバック機構はこの情報を入力 ストリームに対してちゃんと返送することができないのです。 恐らく、Torは自身で出力パケットの多くがドロップされている場合にこれを 検出して、入力ストリームに対してレート制限をすることでこれを 調整するべきでしょうか？まず控えめなレート制限を掛け、そこから 徐々にレートを上げて行き、ロストパケットが出た時点で戻し、また繰り返す ーといったビルドアップ・ドロップオフ手法を想像できます。 私達は、これをネットワークでシミュレートして設計を助けてくれる 適当な方を探しています;さらに／またはパフォーマンス低下の限度を 知る必要があり、このことをUDPトランスポートを再考慮する動機と したいと考えています。
- 関連する話題として、輻輳制御の問題があります。現在の私達の デザインは負荷の高い使用に耐えうるものなのでしょうか？恐らく、 私達は固定ウィンドウサイズよりも可変ウィンドウサイズを試して 見るべきでしょうか？SSH スループット実験を見る限りうまく行っているように見えますが。 私達は測定して調整する必要があるでしょう。そして結果が良ければ より徹底した調査をすることになるでしょう。
- 私たちの抗検閲の目標の一つとして、回線上のTorの通信を観察している 攻撃者が Torの通信を通常のSSLの通信と区別する ことを妨げることが挙げられます。明らかに私たちは完全で依然利用可能な ステガノグラフィをを得ることは出来ませんが、始めの一歩として数個の パケットを観察しただけで成果をあげてしまうような攻撃はすべてブロック したいと考えています。私たちがあまり検証していないままの攻撃としては、 Torのセルが512バイトであることから、回線上の通信が512バイトの倍数だろうと 推測するというものがあります。バッチングとTLSレコードのオーバーヘッド は回線上でこれをどれだけ曖昧にしてくれるでしょうか？1ビットのパディング でも大いに役立つのか、それともこれは我々が受容すべき攻撃なのでしょうか？
- Tor回路は一度に一ホップずつ構築されるので、理論的には二番目のホップ であるストリームを回路から離脱させ、三番目のホップでもまた別のストリーム を離脱させ、以下同様にすることが可能です。これはあるサーバから見ることの できる出力ストリームを分割することになるので良い方法だと思われます。 しかし、各ストリームについて安全性を確保しようということになると、 私達の現在の理論によれば、安全な"最短の"パスは少なくとも3ホップの長さを 持っている必要があるため、残りはさらに長くなってしまいます。この パフォーマンス／セキュリティのトレードオフを検討する必要があります。
- Torリレーやディレクトリサーバに対してDoS攻撃を仕掛けることは そんなに難しいことではありません。クライアントは正しい答を得られずに 頭を悩ますでしょうか？他のアプローチもあるでしょうか？もしこれを 現在のTorプロトコルとの後方互換のまま修正できたらなお良いです。
- Torbuttonのようなプログラムは、 あなたのブラウザのUserAgent文字列を全Torユーザ共通の 答えで置き換えることによってそれを隠蔽することを狙いとしています。 こうすることによって、攻撃者はヘッダを見てTorの匿名性集団を見破る ことが出来なくなります。それは非Torユーザにも広く使われている文字列を 選ぶようにしていますので、目立つことはありません。質問1:Torbuttonが 要求するFirefoxのバージョンへと定期的にアップデートするのにどれだけ 面倒な目に遭わなければいけないんでしょう？もし私たちがそれをあまりにも 頻繁にアップデートすれば、匿名集団が自ら露見してしまいます。しかし もしそれを十分頻繁にアップデートしなければ、すべてのTorユーザが Firefoxのかなり古いバージョンを運用すべきだと主張することで目立って しまうでしょう。これに対する答えは恐らく、ネット上で見られるFirefoxの バージョンによるでしょう。質問2:時々、人々がN個のUserAgent文字列を使いまわす ように依頼してくるのですが、このアプローチは役に立つ、悪い、無害のどれですか？ 考慮すべき点:クッキーおよびローテートしているUserAgentからTorbuttonユーザを 識別すること;特定のブラウザだけを攻撃する悪意あるウェブサイト; 質問1の答えがこの質問の答えに影響を与えるかどうか。
- 現在のところ、Torクライアントはある一つの回路を最初にそれが使用 された時点から10分間再利用しようとします。これは、回路拡張作業を多く し過ぎてネットワークがダウンしてしまうのを防ぐ一方で、クライアントが あまりに長い時間同じ回路を使い続けて出口ノード が有用なクライアントの変名のプロファイルを構築できてしまうことを防ぐ ことを目的としています。残念なことに、10分間という時間は、 特に複数のプロトコルからの接続(例えばIMとウェブブラウジング)が同じ回路に 押しつけられた場合には、恐らく長すぎます。ネットワークが必要とする 回路拡張の総合計数を固定化し、クライアントがストリームを回路に 割り当てるより効率的かつ/または安全な方法、またはクライアントがプリエンプティブ な回路を構築できる方法はないでしょうか？恐らくこのリサーチ項目は、 典型的クライアントがどんな接続を起動しようとするかについてのトレースを 収集して、現実に何を最適化しようとすべきかを把握することから 始める必要があるでしょう。
- 到達性を確保するためにいくつのブリッジリレーを知る必要があるでしょうか？ ブリッジの中に常時稼働していないものがいくつあるのかを測定する 必要があります。もし多くの非常時稼働ブリッジがある場合には、ブリッジ ユーザが接続を維持しやすくなるような方法があるでしょうか？
これらの問題について何か前進があったら 私達にお知らせください！