Lucky Thirteen TLS攻撃はどの程度実用的/重要ですか？
私は この記事 が呼び出されているTLSに対する新しい攻撃について説明していますLucky Thirteen。 HTTPS接続に対する反復可能なMitM攻撃を許可すると主張しています。
実際に実行するのはかなり非現実的であると説明されています。
- Tweakを試行するたびに、TLSセッションが終了します。これは、顕著で時間がかかる場合があります。
- 調整を徹底的に行うには、調整された各セッションの同じパケット位置に同じプレーンテキストが必要です。
- 著者は、信頼できる結果を得るために統計的に有意な十分なタイミングデータを生成するために、216回の調整の完全なセット（つまり、800万回のTLSセッション）を27回繰り返す必要がありました。
しかし、それが HTTPSに対する実用的で反復可能な攻撃 になる可能性があると考える他の声があるようです。
私は考えていた：
- ラボ環境から既知のLANに持ち込むこと、または既知のLANからWANに持ち込むのはどれほど難しいでしょうか。
- ソフトウェアを必ずしも制御できない場合、この攻撃を防御するのはどれほど難しく、どの程度必要ですか。タイミング攻撃を回避するためにHTTPS応答をランダムにパディングして遅延させる方法はありますか？
- これは [〜＃〜] beast [〜＃〜] などのSSL/TLSに対する現在の攻撃とどのように相互作用しますか？増幅効果はありますか？
最も重要な：
- 今後の実装を検討する場合、この結果はどの程度重要ですか？
攻撃が2003年に最初に説明されたとき（タイミング分析による「悪いパディング」のOracle）、意図された攻撃シナリオは、サーバーに定期的に（たとえば1分に1回）接続して新しいかどうかを知る電子メールクライアント（たとえばOutlook Express）でしたメールが到着しました（ [〜＃〜] pop [〜＃〜] プロトコルを使用している場合、新着メールを通知できません。ポーリングする必要があります）。各接続は同じ認証フェーズで開始するため、ターゲットパスワードはストリーム内で確定的で再現可能な配置にあり、Outlook Expressはエラー報告が悪かったことで悪名高いため（つまり、無音であるか、または長期にわたって更新されるだけです）ユーザーが無視するように訓練されているエラーポップアップ）、それは攻撃のための良い設定でした。
重要なポイントは、そのような攻撃は（興味深いデータ）（パスワード）が復号化されるdecryptionポイントの近くで発生する必要があることです。メールサーバーのシナリオでは、これはクライアントではなくserverの近くにあります。
「ラッキー13」は2つの新しいデータポイントを追加します。
タイミング攻撃に対する一般的な防御策（つまり、パディングが間違っている場合、それが良かったかのように動作し、それでもMACを計算する）は少しリークする可能性があることを指摘します（「想定パディング」には正確な長さが含まれていないため） 「良いパディング」）。 2003年の最初の攻撃で約1ミリ秒の遅延が使用されていた場合、新しいリークは約1000倍短く、約1マイクロ秒です。
ラボ条件（ターゲットと攻撃者の間のスイッチが1つだけの100 Mbit/sイーサネット、数百万の対策）では、約1マイクロ秒までの対策が可能であることを示しています。
最初のポイントはもちろん興味深いものです。ただし、2番目のポイントにはこの根本的な欠陥があると主張します。if攻撃者がこれをターゲットに近づけると、他の多くの方法で勝つことができます。確かに、 タイミング攻撃 は、時間ベースのデータリークを通じて閉じたシステムから情報を抽出することです。私たちの暗号学者は暗号化レイヤーに集中する傾向があります。それは私たちの仕事であり、暗号化はすべて秘密の集中に関するものです。「鍵」は秘密の本質であり、非常に貴重です目標。ただし、暗号化の要点は機密dataとを保護することであり、機密データの処理により、タイミング。
完全なデータ処理スタックでは、SSL/TLSレイヤーは、低レベルのTCP/IPスタックと、機密データをさまざまな方法で使用する「アプリケーション」の間にとどまります。復号化はTLSで行われるため、TCP/IPレイヤーは暗号化されたチャンクのみを認識し、リークするものはありません。ただし、TLSレイヤーでリークが発生する可能性があるのみと考えるのは、過度に楽観的であり、途方もない態度に固執します。 完全なアプリケーションコードは、潜在的にタイミング攻撃に対して脆弱です。 TLS自体への攻撃はよりニュース価値がありますが、アプリケーションコードへの攻撃は破壊的な可能性がはるかに高いと私は主張します。
要約すると、「ラッキー13」攻撃は興味深いですが、あまり現実的ではありません。タイミング攻撃に関しては、TLSレイヤーは氷山の一角にすぎません。メタファーをさらに悪用するには、「ラッキー13」を心配することは、タイタニック号の腐食を心配することと少し似ています。抽象的な種類の有効な懸念ですが、ボートに関連する他の問題ほど緊急ではありません。
私はあなたに this 攻撃の良い説明を与えるマシュー・グリーンによる特定のブログ投稿を指摘します。特にこの引用。
しかし、これがTLSで機能する方法はありません！セッションを終了します！私がこれをデータグラムTLS（DTLS）への実際的な攻撃として、そしてTLS自体に対するより理論的な攻撃として説明したことを思い出してください。*これには理由があります。
その理由は、TLSには（DTLSではなく）もう1つの対策が含まれているためです。これは、まだ説明していない対策です（レコードが解読に失敗した場合（MACの誤りやパディングエラーが原因）、TLSサーバーはセッションを強制終了します。 DTLSはこれを行わないため、この攻撃の境界線は実用的です。 （ただし、実行には数百万のパケットクエリが必要です。）
標準のTLSの「セッションキル」機能は、攻撃者が何度も復号化を試行する必要があるため、Oracle攻撃のパディングを停止するように見えます。セッションを強制終了すると、攻撃者は1回の復号化に制限されます-直感的には、これで終わりです。
しかし、実際には、これは真実ではありません。
ご覧のとおり、Oracle攻撃のパディングに関する優れた点の1つは、（a）犠牲者がセッションを落とした後にセッションを再開する用意があること、および（b）シークレットを提供することを条件として、それらが異なるセッション（キー）で動作できることです。プレーンテキストは、各ストリームの同じ位置に表示されます。幸い、ブラウザーとHTTPSの設計により、これらの要件の両方を満たすことができます。ターゲットブラウザーが多くの接続を開始するようにするには、それを（JavaScript攻撃のように）SSLサーバーに繰り返し接続させるカスタムJavascriptをフィードします。 Javascriptはターゲットのウェブサーバーから取得する必要はありません-関連のないHTTPS以外のページで提供され、別のタブで実行される場合もあります。つまり、これはかなり実現可能です。 Morover、HTTP（S）プロトコルの設計のおかげで、これらの各接続にはHTTPストリームの既知の場所にCookieが含まれます。残りのストリームを復号化できない場合もありますが、通常、これらのCookieの値だけで誰かのアカウントに侵入する必要があります。したがって、このようなCookie攻撃に対する唯一の実用的な制限は、サーバーがこれらの接続をすべて再開するのにかかる時間です。 TLSハンドシェイクは高速ではなく、この攻撃はバイトあたり数万（または数百万）の接続を必要とする可能性があります。したがって、実際にはTLS攻撃にはおそらく数日かかります。つまり、慌てる必要はありません。
一方で、自己満足してはいけません。著者は、近い将来にTLS攻撃を実現可能（TLSの場合）の領域に取り込む可能性のあるいくつかの巧妙な最適化を提案しています。
あなたが尋ねる：
ラボ環境から既知のLANに持ち込むこと、または既知のLANからWANに持ち込むのはどれほど難しいでしょうか。
攻撃には非常に小さなタイミング差の測定が含まれるため、ラボ環境の外で悪用することは少し難しい場合があります。
ソフトウェアを必ずしも制御できない場合、この攻撃を防御するのはどれほど難しく、どの程度必要ですか。タイミング攻撃を回避するためにHTTPS応答をランダムにパディングして遅延させる方法はありますか？
エンドユーザーがこの攻撃を防御するためにできることはほとんどないようです。システム管理者は、SSL実装を更新し、RC4暗号スイート（一時的な手段として）に切り替え、AES-GCMのようなAEAD暗号スイートを使用することで、これを軽減できます。
これは、BEASTなどのSSL/TLSに対する現在の攻撃とどのように相互作用しますか？増幅効果はありますか？
攻撃の背後にいるチームのように 推奨 攻撃は、BEASTスタイルのテクニックと組み合わせることで強化できます。
今後の実装を検討する場合、この結果はどの程度重要ですか？
理論的には攻撃は新しいものではありません。MACを適用する前に必ず暗号化する必要があるのは 常識 です。
防御に関しては、Linuxでは次のようなことができます。
tc qdisc add dev eth0 root netem delay 3ms 1ms
Kaminskyの2012 Black Ops presenstation で説明されているように、タイミング攻撃に対する基本的な防御策としてネットワークインターフェイスにランダムな遅延を追加します。
もちろん、そこにはパフォーマンスのトレードオフがありますが、多くの場合、数ミリ秒は取るに足らないものです。