TLS（1.0、1.1、1.2）のみがサポートされている場合、TLS_FALLBACK_SCSVは役に立たないのですか？
サーバーがダウングレード攻撃を防ぐためにTLS_FALLBACK_SCSVをサポートしていない場合、ssllabsはA +（最高）の評価を与えません。しかし、私が疑問に思っているのは、サーバーが正当に3つの最新バージョンのTLSのみをサポートしている場合、それは本当に役立つのでしょうか。そのため、ダウングレードではTLS 1.0が実現されますが、これは古いブラウザをサポートするのに十分と言っていいほどです。
そして、サーバーがサポートしている場合はさらに興味深いです。 TLS 1.2のみの場合、この保護は完全に役に立たないか、またはここで何かがわかりませんか？
格付けメカニズム全体は、実際のセキュリティよりも宣伝と広報です。優れたセキュリティが必要な場合は、詳細に注意し、内部でどのように機能するかを理解する必要があります。良い成績が必要な場合は、良い成績を得るために必要なことは何でもすべきです。 SSL Labsの「A +」は、レポートの最後に追加する非常に気の利いたものですが、本当に確かなセキュリティを備えているとは言えません。 「A +」を持つことは、「私はA +を持っている」と言えることと同じです。
SSL/TLSハンドシェイクの原則は、クライアントとサーバーがサポートされる最大バージョンをアドバタイズすることです。そのため、選択されたバージョンは、クライアントとサーバーの両方がサポートする最新のものです。このプロパティは、アクティブな攻撃者がクライアント（サーバー）とサーバーの両方がサポートするバージョンのハンドシェイクを（リアルタイムで）即時に破ることができない限り保持されます。例えば。クライアントとサーバーはSSL 3.0からTLS 1.2までのすべてのバージョンをサポートできます（TLS 1.2は内部的には「SSL 3.3」です）。SSL3.0ハンドシェイクもアクティブな攻撃者によってすぐに破壊されないほど堅牢であるため、攻撃者はダウングレードを強制できません- -そのハンドシェイクには、アドバタイズされた最大バージョンが含まれます。
...クライアントが実際にサポートしているバージョンよりも低いバージョンを再接続してアドバタイズしている、何かばかげている場合を除きます。既存のクライアントは、クライアントがサーバーと通信する必要があるため、サーバーと通信する必要があるため、クライアントがサーバーが認識した最も高いバージョンよりも大きいバージョンをアドバタイズすると、クラッシュ/切断されます。通常、クライアントが「SSL 3.42」と発声し、サーバーが「SSL 3.17」までしか認識していない場合、サーバーは「SSL 3.17を使用します」と応答します。 SSL 3.0以降のバージョンに関する標準とドキュメントは、その主題に関して常に非常に明確でした。しかし、開発者たちはまだそれを間違っていました。一部のサーバーは、「SSL 3.42」を受信すると、その場で単純に削って死んでしまいます。
したがって、おそらく無能なサーバーに対処するために、クライアントは、接続エラーが発生した場合に自分自身を自動調整する習慣をとっています。これが TLS_FALLBACK_SCSV の出番です：これは追加のメカニズムであり、暗号スイートを装ってハンドシェイクに密輸されているため、クライアントはサーバーに「私は馬鹿ではありませんがサーバーとして、これらのバグの多いサーバーの1つになり、不自然なタイミングで爆破する場合に備えて、単純にClientHelloを送信しています。」.
クライアントが自動ダンビングを適用し、TLS_FALLBACK_SCSVをサポートしない場合、ダウングレード攻撃を防ぐためにサーバーができることは何もありません。攻撃者は、アドバタイズしようとする接続を強制終了するだけで、クライアントに古いプロトコルバージョンを使用させることができます。何か新しいもの。ただし、クライアントとサーバーがTLS_FALLBACK_SCSVをサポートしている場合は、ダウングレードの試みが検出されます。
この長いプリアンブルは、質問に答えるためのコンテキストを取得するためだけのものでした。基本的に、サーバーがTLS_FALLBACK_SCSVをサポートしていない場合、クライアントがTLS_FALLBACK_SCSVをサポートしていたとしても、アクティブな攻撃者は強制的にダウングレードできます。これは、TLS 1.0、TLS 1.1、およびTLS 1.2をサポートしている場合、これには理由があるという意味での問題です。利用可能な場合はTLS 1.2を使用することを推奨し、攻撃者はそれを防ぐ方法があれば、これは成功した攻撃であるstricto sensuです。攻撃者は、攻撃されていない好ましい状況とは異なる状況を強制することができます。
しかし、これは結果が深刻であることを意味するものではありません。 TLS 1.0にはいくつかの既知の欠点があり、基本的に2種類の攻撃に煮詰められます。
TLS 1.0ではCBCベースの暗号スイートを使用して、攻撃者が次のレコードのIVを予測できるという事実を利用するために、choose-plaintextを使用するBEASTのような攻撃。
パディングOracle攻撃は、たとえば、着信レコードの処理におけるわずかなタイミングの違いに依存しています（「 ラッキー13攻撃 と記述されています）。
TLS 1.1は第1の種類を修正し、レコードごとに予測不能なIVを使用します。 2番目の攻撃に対して、TLS 1.2は、パディングをまったく必要としないAEAD暗号スイートを提供するため、Oracleのパディングを回避できます。ただし、どちらの種類の攻撃も、CBCベースの暗号スイートに「1/n-1スプリット」を使用することにより、および一定時間のMAC計算をそれぞれ使用することにより、「純粋な」TLS 1.0で効率的に軽減できます。
したがって、ifクライアントは1/n-1分割を行うために十分に開発されており、サーバーは定数でMACを計算するために十分に開発されています時間、次にTLS 1.0を使用すると発生します、私たちが知る限り、修正が必要なセキュリティの問題はありません。 TLS_FALLBACK_SCSVを実装するクライアントとサーバーは必ずしも最新であり、実装の推奨により「おそらく」最新であるため、すべてが正しく実行され、安全なTLS 1.0を実行できる可能性が高いです。
ただし、TLS_FALLBACK_SCSVをサポートするサーバーは、SSL LabsからA +を取得するためにのみサポートしている可能性があり、SSL Labsは定数-時間の計算。
要約すると：TLS_FALLBACK_SCSVをサポートしていないことは、クライアントとサーバーがTLS 1.0をどの程度適切に実装しているかに応じて、必ずしも深刻な問題ではありません（SSL 3.0をサポートしていないため、最も明白な問題をすでに回避しています）。ただし、適切な実装は保証されず、TLS_FALLBACK_SCSVをサポートしないことは、必ずしも脆弱性でなくても、正式には脆弱性です。弱点を攻撃者が完全な悪用に変えることができないということは、それが存在しないことを意味しません。
いずれの場合も、セキュリティが必要であるため、TLS_FALLBACK_SCSVを実装しません。 A +が必要なため、TLS_FALLBACK_SCSVを実装します。そうしないと、多くの人に「A +」グレードはその意味で無意味であり、それを取らない余裕があることを説明するのに膨大な時間を費やすことになります。長期的には、オオカミと遠吠えしないと高すぎる。