リレーの認証と堅牢化

前回のお知らせ以降、main ブランチに4つの変更が入りました。クライアントとリレーが受け入れるものを絞り込む変更です。研究のページの数値は、これまでと同じ予備的な計測のままです。

リレーの鍵をアンカーで検証する

クライアントは、署名付きのバンドルからだけリレーの鍵を受け取ります。バンドルは、認証局が発行した証明書と、リレー自身の署名鍵で署名されたディスクリプタです。クライアントはチェーンのすべてのリレーをトラストアンカー（認証局の公開鍵）で検証し、ひとつでもエラーがあればチェーンを作りません。未検証の鍵に切り替えることはありません。

証明書は、クラスタの外で jimichi enroll が発行します。認証局の鍵は1回の発行のために作られ、すぐに解放されます。リレーは起動時に署名鍵をメモリ内に作り、その鍵はプロセスの外に出ません。証明書は、リレーのプロセスごとに一度だけ導入されます。

なぜ重要か：クライアントがリレーの鍵を取得するときに鍵をすり替えられることへの対策です。

チェーン確立のセルは一度しか開かない

リレーは、自分が開いたチェーン確立のセルごとにタグを、鍵が生きているあいだ覚えていて、コピーを破棄します。元のチェーンが閉じたあとでも同じです。タグの数には上限があり、満杯になったリレーはタグを忘れる代わりに、新しいチェーンを拒否します。

なぜ重要か：そうしないと、コピーが同じホップの鍵をもう一度作り、同じ鍵のもとでカウンタがゼロからやり直されてしまいます。

カウンタは厳密に連続し、回線ごとに異なる

セルのカウンタは、チェーンの回線ごとに別の値を取ります。リレーがセルを受け入れるのは、カウンタが直前に受け入れたものよりちょうど1大きい場合だけです。コピー、欠落、順序の入れ替えはチェーンを閉じ、そのセルは先へ進みません。

なぜ重要か：回線ごとに異なるカウンタは、セルのヘッダーからフローを結び付けることへの対策の一部です。また、再送されたセルを転送すれば、能動的な観測者にタイミングの目印をただで与えてしまいます。

リレーの制限

ハンドシェイク、チェーン確立、書き込みには期限があり、チェーンはアイドルタイムアウトのあとと存続時間の終わりに切断されます。接続を受け入れるか拒否するかは、接続を受けた時点で、鍵合意の前に決まります。ひとつのアドレスが得られるのは、回線、ハンドシェイク、チェーン確立の割り当て分までです。計測環境では、ネットワークポリシーにより、各セル用ポートには直前のホップからの接続だけが届きます。

なぜ重要か：応答しない相手が枠を占有できるのは期限が切れるまでで、ひとつのアドレスがすべての枠を取ることはできません。

これで解決しないこと

チェーンの層には、依然として隣のリレーに対する前方秘匿性がありません。
リレー間の回線が認証されるまで、リレーは相手がリレーかクライアントかを区別できません。
リレーのディレクトリはなく、失効の仕組みは証明書の期限切れとリレーの再起動のほかにありません。
リレーの制限を超えるサービス拒否は、防いでおらず、計測もしていません。

全体の一覧は限界のページと適用範囲（英語）にあります。形式と検証の順序はアーキテクチャ（英語）に、脅威と対策は脅威モデル（英語）にあります。公開済みのアドバイザリは、リポジトリの security advisories のページにあります。