LUCKY 13のような既知の攻撃に対して安全なCBCベースの暗号スイートはありますか？

Question

https://mozilla.github.io/server-side-tls/ssl-config-generator/ で最新のプロファイルを選択すると、次の4つの暗号スイートも有効にすることが推奨されていることがわかります。

ECDHE-ECDSA-AES256-SHA384（= TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384）
ECDHE-RSA-AES256-SHA384（= TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384）
ECDHE-ECDSA-AES128-SHA256（= TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256）
ECDHE-RSA-AES128-SHA256（= TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256）

インターネットのさまざまなソースによると、CBCベースの暗号スイートを使用している場合、LUCKY13のような攻撃が可能です。（例 TLS 1.3がAES-CBCを落とした理由）

私の質問は次のとおりです。MozillaはCBCベースの暗号スイート以上を明確に推奨しているので、それらはLUCKY13に対して脆弱ではなく、既知のそのような攻撃に対して安全ですか？

Z.T. · Answer

いいえ、すべてのTLS CBC暗号スイートには同じ問題があります。ほとんどの古い実装と現在デプロイされている実装の一部（一部はパッチ不可能、一部はベンダーが研究者から連絡できないなど）には、lucky13またはプードル（両方ともあります）のバリアントがあります。多くの名前付きバリアント）。

Mozillaリストは、プードルの新しい亜種が発見される前からあり、SSLラボのテスターがすべてのCBC暗号スイートを「弱い」とマークしました。

CBC暗号スイートを正しく実装することは可能ですが、難しすぎます。それらを正しく実装する努力がなされた場合、GCMまたはCCMまたはChaCha20-Poly1305のサポートに努力を費やすほうがよいでしょう。

反対側がAEADをサポートできる場合は、AEADを使用する必要があります。反対側がAEADをサポートできない場合は、非常に疑わしく、CBCを徹底的にテストする必要があります。 TLSは、最初に反対側をテストしなくても安全であると想定されているため、CBCサポートを削除できる場合は、そうする必要があります。つまり、TLSバージョン1.2未満のサポートを終了します。

もちろん、ビジネス上の理由から、多くはCBC暗号スイートを長期間サポートすることを選択します。ビジネスはいつサポートを終了できますか？そのようなクライアントが実際に存在しない場合。ユーザーは、CBCしか実行できないクライアント（またはプロキシ）の使用をいつ停止しますか？そのようなクライアントが重要なサーバー（google、facebookなど）に接続できない場合。これには時間がかかります。

Chromeは、来年CBC暗号スイートを必要とするサイトの「安全でない」UIを表示する可能性がありますが、完全に削除します-おそらくそうではありません。 Googleのサーバーは安全ではないUIを表示できません-接続を許可するかどうかのどちらかなので、CBC暗号スイートとの接続を長期間許可すると思います（ただし、 published にアップグレードしてほしい） AEADおよびAEADでECDHEをサポートすることのみを約束します）。

Gilles &#39;SO- stop being evil&#39; · Answer

Lucky 13は、他に何を使用するかに関係なく、CBCを使用するすべての暗号スイートに適用されます。攻撃は、CBCとTLSでの使用方法のみに対するものであり、プロトコルが他に何をするかには関係ありません。

Lucky 13に対する防御策はいくつかありますが、どれも万能薬ではありません。

原則として、Lucky 13はTLSの実装に対する攻撃であり、プロトコル自体に対する攻撃ではありません。 Lucky 13から保護する方法でTLS CBCベースの暗号スイートを実装するのは可能です。問題は、そうすることが非常に難しく、パフォーマンスが大幅に低下することです。 OpenSSLの緩和策は攻撃から完全に保護し（パフォーマンスコストを支払います）（数回の試行があったことに注意してください）と思いますが、すべてのTLS実装がそうするわけではありません。これは、「ソフトウェアを更新するだけ」では問題が解決しない場合があります。
encrypt-then-MAC拡張は、発生する可能性のあるラッキーサーティーンまたはその他のCBCパディングOracleを完全に防御します。サーバーとクライアントの両方でサポートされている必要があります。問題は、すべてのTLS実装でサポートされているわけではなく、ほとんどのソフトウェアでは、「この暗号スイートは、EtMが有効になっている場合にのみ許可される」と言うように構成できません。
もちろん、最善の防御策は、すべてのCBC暗号スイートを無効にし、AEAD（TLS 1.2以上が必要）のみを使用することです。ただし、そこにあるすべてのクライアントとサーバーがAEAD暗号スイートをサポートしているわけではありません。インターネットでは、2017年半ばから2018年半ばに、AEAD（両側がAEADをサポートすることを意味します）を使用したTLS接続の割合が約85％停滞しました（出典： 年齢：TLS展開の縦断的研究 図2。測定値の収集方法については、§3を参照してください）。