TOR と I2P

11 件のメッセージ BitcoinTalk madhatter, サトシ・ナカモト, The Madhatter, BitcoinFX, riX, fergalish 2010年1月16日 — 2010年4月27日
madhatter 2010年1月16日 14:22 UTC 原文 ·

こんにちは、

また一つアイデアを思いついた。

TOR と I2P のシードを持てるようにできたらとても良いと思う。例えば、TOR ネットワーク内の.onion アドレスで BT を実行できる。クライアントが BT を TOR に接続し、.onion アドレスからシードして接続ピアとして使用できるだろう。(I2P についても同様で、.i2p サービスとして BC を実行できる)

このような形でいくつかのノードをセットアップし、トンネル情報をこのフォーラムに投稿するかもしれない。すでに多くの I2P と TOR のノードを運用しているので、BC を追加するのは非常に簡単だ。

システムのプライバシーを向上させるために、BC を TOR および I2P と互換性のあるものにするというアイデアを支持する。つまり、車輪の再発明をする必要はないのだ。BC を強化するために使える数千ものミックスネットワークノードがすでに存在している。

よろしく!

しばらくそれについて考えていた。.onion アドレスのバックエンドサポートと接続機能を追加してから、そこから進めていきたいと思う。

.onion アドレスを作成するにはユーザーがいくつかの手順を踏まなければならないため、何かに使われている.onion アドレスはあまり多くない。TOR を設定して.onion アドレスを生成し、TOR を再起動し、生成されたアドレスで設定する。おそらくこれは意図的なもので、TOR がファイル共有プログラムに十分に自動化された形で統合できないようにしているのだろう。

The Madhatter 2010年1月24日 20:52 UTC 原文 ·

ああ、その点では I2P の方がずっと自動化しやすい。手動で.onion をいくつか設定して、シードとして使えるようにリストに投稿することはできる。最小限の手間で Tor に結びつけられる、常時稼働のノードを持っているからな。

俺は以前は熱心な Tor 推進派だったが、I2P を使い始めてからは、いろいろな点でずっとずっと優れていることが分かった。最大の改善点はスピードだ。😉 ただ、Java で書かれているのが残念だな。

サトシ・ナカモトの投稿(2010年1月20日 22:05 UTC)

しばらくそれについて考えていた。.onionアドレスのバックエンドサポートと接続機能を追加してから、そこから進めていきたいと思う。

.onionアドレスを作成するにはユーザーがいくつかの手順を踏まなければならないため、何かに使われている.onionアドレスはあまり多くない。TORを設定して.onionアドレスを生成し、TORを再起動し、生成されたアドレスで設定する。おそらくこれは意図的なもので、TORがファイル共有プログラムに十分に自動化された形で統合されないようにするためだろう。

BitcoinFX 2010年2月1日 21:36 UTC 原文 ·

俺も Tor のリレーと出口ノードを運用していて、Bitcoin と Tor の統合について同じようなアイデアを持っていた。

Tor は設定を正しく編集すれば非常に高速になりうる。遅いサーバーへの接続を制限し、可能な限り最速のノードだけを使えばいい。俺はまた、「問題のある」インターネット国にあるノードもブロックするのが好きだ。そういう場所は接続も遅い傾向があり、全体的なプライバシーもいくぶん向上する。さらに、Unnamed、ididnteditheconfig、名前が気に入らないサーバー、不安定なサーバーもブロックしている。

この設定例はリレー/出口ノードではない個人利用にのみ適している。ただ、P2P には最適だ 😊

AvoidDiskWrites 1

ExcludeNodes SlowServer,{sd},{pk},{tn},{ae},{by},{in},{bh},{th},{ye},{mm},{eg},{sg},{ma},{cu},{qa},{sa},{by},{md},{tm},{tr},{et},{jo},{sy},{om},{ir},{az},{uz},{kz},{kg},{af},{cn},{bd},{vn},{ng},{gh},{ro},{lb},{ru},{iq},{ly},{ve},{zw},{my},{mo},{kr},unnamed,ididnteditheconfig …etc.

StrictEntryNodes 1

EntryNodes (http://trunk.torstatus.kgprog.com/index.php?Fast=0 から高速なエントリおよび権威サーバーを選択)

StrictExitNodes 1

ExitNodes (http://trunk.torstatus.kgprog.com/index.php?Fast=0 から高速な出口のみを選択)

Tor が自動的に回路を切り替える時間や、その他のカスタム設定を変更するのもいい考えだ https://www.torproject.org/tor-manual.html

参考になれば幸いだ 😉

BitcoinFX 2010年2月1日 22:08 UTC 原文 ·

さて、Tor を使って疑似匿名の暗号「Bitcoin 銀行」実験をセットアップしてみた。😄

標準の 9050 socks ポート「デフォルト設定」を使えばほぼ成功した。つまり、Tor を通じて他の Bitcoin ノードへの接続は確保できた。しかし、様々な問題と複数の警告メッセージに遭遇した。

「Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via polipo or socat) instead.」

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

最終的に Privoxy と Stunnel(そちらの方が慣れているので)を使って修正した。ただし、polipo と Stunnel でも可能だ。

しかし、ポート 8333(Bitcoin の「デフォルト」として想定通り)と 6667(間違っていなければ IRC ポートだ!?)について、時折警告が出る。

Tor 経由で Bitcoin に接続すると、Tor が [scrubbed]アドレスへの「欠落した」接続を確立しようとして、繰り返し出口ノードを変更する。最初は Tor の出口がポート 8333 や 6667 をブロックしているためだと思ったが、ほとんどの場合そうではなかった!

Tor 経由の他の P2P アプリケーションは、接続できない IP アドレスを「無視」でき、「警告」なしに動作を続行できる。しかし、Bitcoin はブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならない! したがって、Bitcoin ノードが 1 つだけ稼働している IP 範囲が Tor 出口ノードをブロックしている場合、これは常にそうなるのだろうか?

これは多くの理由で問題がある。😕

riX 2010年2月2日 22:36 UTC 原文 ·
BitcoinFXの投稿(2010年2月1日 13:08 UTC)

「あなたのアプリケーション(ポートxxxxでsocks5を使用)はTorにIPアドレスのみを提供しています。DNS解決を自分で行うアプリケーションは情報を漏洩する可能性があります。代わりに Socks4A(例:polipo や socat経由)の使用を検討してください。」

Bitcoin は IP アドレスを使っていて、ホスト名は使っていないので、DNS は不要だ。Tor は bitcoin が Tor の内部 DNS を通さずに IP に接続しようとしているため、通常の DNS を使っていると判断してしまう。

BitcoinFXの投稿(2010年2月1日 13:08 UTC)

しかし、ポート 8333(Bitcoin の「デフォルト」として想定通り)と 6667(間違っていなければ IRC ポートだ!?)について、時折警告が出る。

Bitcoin はポート 8333 を使っている。Tor のポート 9050 を通してリレーしているとしてもだ。😛 6667 は IRC だ。Bitcoin はノードリストの配布に IRC サーバーを使っている。(Bitcoin を動かしている別のコンピューターの IP を知っていれば、-connect オプションを指定してノードリストの使用を回避できる。)

BitcoinFXの投稿(2010年2月1日 13:08 UTC)

しかし、Bitcoinはブロックを見逃していないか確認するために全てのノードに接続しようとしなければならない!

いや、最長のブロックチェーンのコピーを持っている限り、たった 1 つのノードに接続されていれば十分だ。

BitcoinFX 2010年2月3日 15:31 UTC 原文 ·

了解、ありがとう riX。

つまり、Bitcoin が少なくとも 1 つのノードに接続されれば、-connect オプションで 6667 の警告を排除できるわけだ。

Bitcoin は何らかの「ピア交換」や DHT を使っているのだろうか? これでも Tor の「出口」警告が止まらず、そのため Tor が接続のために新しい「出口」ノードを試行し続ける必要がある問題は解決しないようだ。(これは Tor にとって問題であり、Bitcoin ではないが 😉)「しかし、Bitcoin はブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならないのでは?」というのは本当はそういう意味だった。表現が不正確だった。

I2P の方が Bitcoin ユーザーの匿名性を高める実装としてはるかに簡単な解決策に思える。 http://forum.i2p2.de/viewtopic.php?t=3946&sid=213e3cd998db98c4511675ecbba17af4

JonDonym もテストしている。http://anonymous-proxy-servers.net/ (有料サービスのみ socks 対応!)ただし、paysafecards を受け付けており、現在 Bitcoin と交換で購入できる。😄

プロキシポート 9050 を使用する場合、IRC サーバーがすべての TOR 出口ノードを BAN しているため、おそらく常に失敗するとわかっているので、IRC への接続は 1回だけ試行し、その後諦める。別のポートを使用している場合、通常の古いプロキシである可能性があると判断し、徐々に間隔を長くしながら IRC への再試行を続ける。Polipo や Privoxy は使用しないでほしい。これらは HTTP フィルターおよびキャッシュであり、変更を加えると Bitcoin のメッセージを破損する可能性がある。Bitcoin は再接続によって克服しようとしているのかもしれない。ポート 9050 を使用してほしい。

riX が言うように、「Tor には IP アドレスしか渡していない。DNS を行うアプリは…」という警告は心配する必要はない。Bitcoin はプロキシモードではまったく DNS を使用しない。

Bitcoin は Tor 経由で IRC に接続できないため、現在どのノードがオンラインかわからず、最近確認されたすべてのノードを試す必要がある。接続試行をできるだけ節約しようとするが、起動時に素早く接続し、切断された場合に素早く再接続したいという要望もある。最後に接続に成功してからの時間が長いほど、接続試行の頻度を下げるアルゴリズムを使用している。例えば、24時間前に確認されたノードの場合、接続試行の間隔は 5時間だ。少なくとも 2 つの接続があれば、1 週間以上前のものは試行せず、5 つの接続があれば 24時間以上前のものは試行しない。

riX 2010年2月4日 12:41 UTC 原文 ·

負荷がそれほど高くないなら、IRC サーバーからのノードリストを http や ftp 経由でミラーリングするのも一案だろう。

fergalish 2010年4月20日 14:26 UTC 原文 ·

tor で隠しサービスをセットアップしようとしていて、torrc に以下を追加した:

HiddenServiceDir /some/directory HiddenServicePort 8333 127.0.0.1:8333

ただ、bitcoin を 127.0.0.1:8333 だけにバインドしたいのだが、「netstat -lp」を見るとすべてのインターフェースでリッスンしているようだ。これをどう指定すればいいのか、簡単には見つからなかった。

何か提案はあるか?

fergalish 2010年4月27日 09:38 UTC 原文 ·

bitcoin を localhost:8333 だけにバインドする方法について、誰か答えを持っていないか?それから、外部 IP の代わりに torland アドレスをブロードキャストさせるにはどうすればいいだろうか?