web-dev-qa-db-ja.com

TLS v1.1の主な脆弱性は何ですか？

TLS v1.1の主な脆弱性は何ですか？実際、RFCはv1.1の脆弱性について説明していません。また、 RFC 5246 のセクション1.2に記載されている説明を除いて、新しいプロトコル1.2に変更するように押し付けたものもありません。

私は実装の脆弱性を意味するのではなく、プロトコル自体の問題のみを探していることに注意してください。

tlsknown-vulnerabilitiesvulnerability
29
melostap

TLS 1.1 には「実際の」セキュリティ問題はありません TLS 1.2 で修正されています。ただし、変更および改善があり、 "修正"と見なすために引数を使用できます。主に：

  • TLS 1.1のPRFは、MD5とSHA-1の組み合わせに基づいています。 MD5とSHA-1はどちらも、暗号化ハッシュ関数として壊れています。ただし、それらが壊れる方法はTLS 1.1のPRFを壊しません。 TLS 1.1のPRFには既知の弱点はありません（SSL 3.0とTLS 1.0のPRFにも弱点はありません）。それにもかかわらず、MD5とSHA-1は「悪い報道」です。 TLS 1.2は両方をSHA-256で置き換えます（まあ、実際には他のハッシュ関数でもかまいませんが、実際にはSHA-256です）。

  • TLS 1.2では、GCMのように 認証済み暗号化モード を使用できます。これは、これまで多くの欠陥の原因となってきた、より伝統的なCBC暗号化モードを置き換えることができます。 適切に実装されていますCBC暗号化はまだ問題ありません。ただし、CBC暗号化を適切に実装することは言うよりも簡単だと思われます。 GCMを正しく取得することは、より容易に達成可能な目標のようです。

  • TLS 1.2はTLS_RSA_WITH_AES_128_CBC_SHAのサポートを義務付けていますが、TLS 1.1はTLS_RSA_WITH_3DES_EDE_CBC_SHAのみを必要としました。したがって、TLS 1.2を使用する場合、AES暗号化が使用可能であるという「保証」があります。 （これは実際には完全に真実ではありません。「アプリケーション固有のプロファイル」がそれ以外に義務付けていない限り、保証は保持されます。また、クライアントとサーバーの両方がサポートしている場合にのみAESを取得します。 TLS 1.1と1.2のどちらを使用しているかに関係なく使用できます。

要約すると、TLS 1.2をサポートするようにサーバーにパッチを適用し、TLS 1.1よりも優先するようにサーバーを構成することは悪い考えではありませんが、実際の欠陥はありません修正が必要なTLS 1.1では、TLS 1.2への切り替えが必須または推奨されます。 TLS 1.2採用の主な動機は、新しくて光沢のあるものに対する通常のパブロフの渇望です。

27
Tom Leek

TLS 1.0を使用することは非常に悪い考えであり、かなり安全ではありません。 POODLEd、BEASTed、その他のパディング-Oracledも可能です。他の多くのCVEの弱点がまだ適用されており、TLS 1.0をオフにしない限り修正できません。

TLS 1.0の問題から半分は解放されていますが、TLS 1.1に固執することは悪い妥協です。ただし、どちらのプロトコルも現在不可欠な最新の暗号モードを提供していないため、最新の暗号化方法はここでは機能しません）

CBC暗号がオンでRSAがオンのTLS 1.2は、接続が完全に安全であるかどうかに関係なく、一種の宝くじです。これは、暗号が接続のどちらの側に実装されているかによって異なります（サーバー<-> Clientbrowser）。

現在推奨されるopmode：CBC暗号なしのTLS 1.2（つまり、プレーンなRSAハンドシェイクもオフ）は、処理が改善され、TLS 1.2が登場して以来廃止されたすべてのものを除外しているため、TLS 1.3のみが安全です。

（3DESおよびRC4暗号を含む他のすべての安全でない64ビットがすでに無効になっていると想定）

6
Bernd P