Torプロジェクト、Rustへの移行を進行中

 (itsfoss.com)
4 ポイント 投稿者 GN⁺ 2025-12-14 | 2件のコメント | WhatsAppで共有
  • Torネットワークの中核コードが、従来のC言語からRustベースのArtiへ移行しつつある
  • 既存のCコードには、バッファオーバーフロー、use-after-free、メモリ破損などの脆弱性が存在する
  • 新バージョンArti 1.8.0は、回路タイムアウトの再設計によって予測可能なパターンを排除し、追跡リスクを低減する
  • onionサービス運用者がCベースのTorからArtiへ鍵を自動移行できる新コマンドが追加された
  • 今回の移行は、セキュリティと安定性の向上に向けたTorプロジェクトの重要な技術的前進である

Arti 1.8.0の主な変更点

  • 今回のリリースの中核は、**回路タイムアウトの再設計(circuit timeout rework)**の適用

    • 従来のTorの*Circuit Dirty Timeout(CDT)*は、単一タイマーで回路の終了時点を制御していた
    • この方式は予測しやすく、トラフィック監視者がパターンを識別できる可能性があった
    • Arti 1.8.0では、使用量ベースのタイムアウトと個別タイマーを導入し、回路が新しい接続を受け入れるときやアイドル状態のときにランダムな時点で終了するよう変更された
    • これにより、**フィンガープリンティング(fingerprinting)**のリスクを低減する

  • 新たに**実験的コマンド arti hsc ctor-migrate**を追加

    • onionサービス運用者は、**制限付き検索鍵(restricted discovery keys)をCベースのTorからArtiのキーストア(keystore)**へ移行できる
    • これらの鍵はクライアント認証に使用され、新コマンドは手動作業なしの自動移行をサポートする

  • 追加の改善点

    • ルーティングアーキテクチャ、プロトコル実装、ディレクトリキャッシュ対応、ORポートリスナー設定など、多数の内部コンポーネントを改善
    • 詳細な変更内容は、Arti 1.8.0の公式変更ログで確認できる

Rust移行の背景

  • Torネットワークは2000年代初頭からC言語ベースで運用されてきた
  • しかしCのコードベースでは、メモリ安全性の問題によりセキュリティ脆弱性が継続的に発生していた
  • そのためTorプロジェクトは、Rustのメモリ安全性を活用したArti再実装プロジェクトを進めている
  • ArtiはTorの機能をRustで再実装し、セキュリティ・安定性・保守性の強化を目指している

技術的意義

  • Rustへの移行は、Torの匿名性保証の仕組みを根本から強化する方向にある
  • 予測可能な回路動作の排除と鍵管理の自動化は、ユーザープライバシー保護水準の向上に寄与する
  • Artiの継続的な更新は、CベースTorの段階的置き換えを加速させる兆候と評価されている

関連記事

2件のコメント

 
GN⁺ 2025-12-14
Hacker News の意見

  • 最近 EFF の Cover Your Tracks を試してみたところ、Tor ブラウザで JS を無効化した状態だけが完全にフィンガープリンティング耐性ありと判定された。
    JS を有効にした Tor でさえ「部分的にのみ」耐性があると評価され、Firefox は JS を無効にしても良い結果が出なかった。かなり怖い結果なので、他の人の実験結果も気になる

    • このツールは フィンガープリント保護の測定方法に欠陥がある。ランダム化を使う保護はむしろ低く評価し、ビニング方式だけを高く評価する。
      逆に fingerprinting.com/demo のように持続性だけをテストするツールにも問題がある。
      本当の危険信号は、両方のテストで失敗する場合だ
    • macOS の Safari でテストしたところ、「Web トラッキングに対する強い保護」という結果を得た。
      ただし Tor ブラウザは確かに目立つものの、このテストだけで Tor ユーザー同士の フィンガープリント識別が容易だとは言い切れない
    • Tor ブラウザは キャンバスサイズの丸めのような方法でフィンガープリントのバケットを広げようとしている。結局、避けられない最大のバケットは「Tor ユーザー」そのものだ
    • Debian でデフォルト設定の Tor ブラウザをテストしたところ、8.24 ビットの識別情報が出た。
      セキュリティレベルを上げるほどむしろ識別ビットが増え、JS を完全に無効化すると再び減る。
      つまり、JS の無効化が最も高い匿名性を提供する

  • Mozilla が Firefox の Rust 化（oxidizing） をもっと進めてくれていたらよかったのにと思う。Rust エコシステムにもプラスだったはずで残念

    • それでも Chrome チームは今も Rust 導入を進めている
    • Mozilla が Rust 開発者を大量解雇した後も、Firefox コードの Rust 比率は 12% 以上に増えている。Chromium は 4% 未満で相対的に少ない。
      もし Rust が Mozilla の「秘密兵器」のままだったら、かえって Rust の普及は遅れていたかもしれない
    • Servo プロジェクトの失敗は Rust の問題ではなく、Mozilla 内部の限界によるものだと思う

  • Rust を使うことが彼らの問題解決に役立つなら、合理的な選択だと思う。
    言語はプロジェクトやチーム、問題に応じて使い分ける道具だ

    • こうした「言語移行期」の話よりも、依存関係の最適化や性能改善のような話のほうが面白いことが多い
    • 元のブログは C を非難していなかったのだから、わざわざ持ち出す必要はないと思う
    • メモリ安全な言語が セキュリティ面で技術的に優位なのは自明の事実だ。
      これは Rust 信者の主張ではなく、医師やパイロットがチェックリストを拒んでいた時代と同じような抵抗の問題だ
    • Rust は今回のケースには向いているが、たいていの UI プロジェクトには不向きだ。
      UI では素早い反復と GC が重要で、性能の重要度は低い。Rust で UI を書くとメンテナンス地獄になりかねない
    • 「すべてを Rust に書き直そう」という姿勢は好きではないが、Tor の場合には Rust が適した道具だ。
      Tor は セキュリティと性能の両方が重要なマルチスレッド環境だからだ。
      Zig も代替にはなり得るが、まだ成熟していない。Tigerbeetle のように 決定的動作（determinism） を重視するアプローチも興味深い

  • Tor プロジェクトへの最大の不満は 速度低下だ。Rust に移したからといって速くなるとは思えない

    • Onion ルーティングには プライバシーと性能のトレードオフがある。原因の大半はネットワーク遅延だ
    • Tor が遅いのはコードより ノード数不足のせいだ。新バージョンはより安全になるだけで、速くはならない
    • トラフィックが地球を二周するような構造なので、物理的に遅延が生じる。結局は 光速の限界だ
    • Tor は 匿名性確保用であって、動画ストリーミング用ではない
    • 高速な匿名ネットワークを作るのは非常に難しい。それでも最近の Tor は昔よりずっと速くなっており、onion 内部だけで活動すれば匿名性は高まる

  • 今回の Rust 移行は Zcash Community Grants の支援で行われた。暗号資産 R&D でも良い結果が出ることはある

    • 金は金にすぎないという意味で、Pecunia non olet（金に匂いなし）という言葉を思い出す。
      ただし暗号資産は尿よりひどいかもしれない、という冗談交じりの比喩も添えていた

  • Tor の exit ノード運用時の法的リスクが心配だ。ホワイトリスト方式でのみ許可する方法はあるのだろうか

    • Tor 公式ブログの exit ノード運用ガイド を参照するとよい。
      可能なら 組織名義での登録が推奨され、より安全に支援したいなら relay の運用 のほうがよい
    • 法的な注目を避けたいなら bridge を運用するのも方法だ。
      あるいは guard/middle relay を回せばネットワークに大きく貢献できる
    • exit ノードは難しいが、Linux ISO の torrent や OpenMap のタイルサーバーをホスティングする形で帯域を寄付することもできる。
      ただし一部の中国 ASN はブロックすべきだ。偽のダウントラフィックが多い

  • Rust 導入はまるで 古い要塞の木の柱を鋼鉄に置き換える過程のようだ。
    Tor の C ベースコードは何十年にもわたるセキュリティ上の妥協と性能上の痕跡を抱えているため、段階的な Rust 化が最も現実的な安全確保の方法だ。
    核心は「全面的な書き直し」ではなく、メモリ非安全領域の縮小にある。
    リスクの高いパース処理、暗号化、プロトコル境界部分だけを Rust に移せば、Tor はさらに堅牢になるだろう。
    今後 Rust ベースの pluggable transport や ハイブリッドランタイムへ発展するかもしれない点も興味深い

  • 実はこの決定は最近の話ではない。Tor は 2020 年に Rust ベースの Arti プロジェクトを始め、2022 年に Arti 1.0 を発表している。
    C コードベースを段階的にリファクタリングするのは難しいと判断し、Rust の 開発速度・移植性・コントリビューター流入に満足しているという。
    最近でも Arti changelog によれば活発に開発が続いている

    • Arti は ライブラリとして他のアプリに組み込めるよう設計されている。
      たとえばメッセージングアプリが別途 Tor デーモンなしでネットワークを利用できるようになる。こちらのほうが大きな変化だと思う
    • タイトルが大げさだという意見もある。Tor チームは長い時間をかけて慎重に進めてきた
    • このリンクは元記事よりずっと良い参考資料だ。「なぜ Rust なのか」という議論を事前に封じるほど戦略が明確に見える
    • Rust は C より OS 間の移植性が高いのか、という疑問も出ている

  • Tor は単なる概念ではなく、プロトコル（onion routing）とネットワーク、そして参照実装をすべて含む名前だ。

    • Onion routing がプロトコルで、Tor はその上のネットワークおよび実装だ。
    • Tor は実際にダウンロード可能な 製品であり、複数の構成要素から成っている。
    • 「Tor を Rust で書き直す」という表現は間違いとは言えない

  • Tor を Fil-C でコンパイルすればメモリ安全性をタダで得られるのでは、という冗談交じりの提案があった

    • ただしこの移行は Fil-C 登場以前から始まっていたプロジェクトだった