レイテンシベースのProof-of-Workシステムは、人気の隠しTorサービス（.onion Webサイト）に対するDDoS攻撃を防止できますか？
私はここにある興味深い記事を読んでいました： http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-703.pdf
それは「怠惰なスーザン：仕事の証拠としての愚かな待機」と題されています。
それはセクション3.1.1で以下を提案しました：
サーバーがクライアントの要求にdelay（d）メッセージで応答するシステムをストローマンとして考えます。ここで、dはクライアントが通信を続行する前に遅延する必要がある時間です。dティック後にクライアントが応答しない場合、サーバーは単に要求をドロップします。少なくともdティックの遅延後にクライアントが応答した場合のみ、サーバーはクライアントのリクエストを処理します。クライアントによる以前の要求は無視されるか、さらに悪い場合、サーバーがクライアントを切断します。後者の手法をSYN Cookie [9]（§3.1.2）のバリアントとして安全に実装する方法については後で説明します。
この手法は、クライアントをIPアドレスで区別することが不可能であるため、tor hiddenサービスの背後から実装することは不可能だと思います。
考え？
あなたが引用した記事は、SYNパケットに遅延システムを適用しています。これは TCPハンドシェイク の最初のステップです。攻撃者にとって SYNフラッド 攻撃は魅力的です IPスプーフィング とうまく機能するため、攻撃者はサーバーからの応答パケット（SYN + ACK ）、その後、攻撃者は偽の送信元アドレスを使用できるため、「隠されたまま」になります。これは実際にはTorの隠しサーバーには当てはまりません。なぜなら、定義上、攻撃者はサーバーの実際のIPアドレスを知ることができないからです。実際、Torを介してサーバーにアクセスする場合、クライアントはいくつかの連続したルーターを介してのみサーバーと通信し、実際に隠しサーバーと通信するルーターは攻撃者のマシンではありません（または、少なくとも、私たちはそう望んでいます）。 SYNフラッドはありません。
（または、より正確には、攻撃者は任意のTorリレーノードをSYNフラッドできますが、どのリレーノードが実際に特定のターゲットサイトであるかを知ることはできません。）
レイテンシの原則は、より高いレベルで適用される可能性があります。メールの場合に存在します。これは Greylisting と呼ばれます。最初の接続時に、メールの送信者は一時的に拒否され、後で再試行する必要があることが通知されました。それが数分（または数時間）後に戻ってきた場合にのみ、メールは正規のものとして受け入れられます。これは、スパマーがメールの送信を記憶するためのリソースを割り当てないため、戻ってこないことを前提としています。
これはWebコンテキストに変換され、サーバーによって計算されたシークレットトークンを含む特別なHTTP応答の形式になり、応答に含まれるため、サーバーはそれが「同じ」であることを認識します。クライアント」以前より。サーバーに多くのメモリを割り当てずにこれを行うと、トリッキーになる可能性があります（日付、カウンター、およびトークンの [〜＃〜] mac [〜＃〜] をエンコードすると役立ちます）。ただし、大きな問題が残っています。このシステムにはクライアントの協力が必要です。攻撃者が協力することに依存することはできません...
待ち時間ベースのシステムは、サーバーが特定のクライアントがいつ戻ってくるかを知ることができる限り、またこれが新しいクライアントである場合にも機能します。これは両方の方法で機能する必要があります。戻るクライアントは、以前と同じクライアントであることを証明できなければなりません（上記の「シークレットトークン」で実行できます）が、できない実際にリピーターのクライアントである場合、まったく新しいクライアントになりすますことができます。 Torのプライバシー機能はそれを効果的に防ぎます。実際、接続が「新しいクライアント」または「以前と同じクライアント」であると明確に識別できた場合、クライアントの追跡は簡単すぎます。
したがって、Torは、遅延ベースのシステムを含む、クライアント追跡に依存するアンチDDoSシステムと実際に互換性がないと言えます。