TLS 1.3が含まれています。 同じことをすべき理由





年の初め、2018-2019年の問題とインターネットアクセシビリティに関するレポートで、TLS 1.3の拡散は避けられないとすでに書いています。 少し前に、トランスポートレイヤーセキュリティプロトコルのバージョン1.3を展開し、データを収集して分析した後、この移行の機能について説明する準備ができました。



IETF TLSワーキンググループの議長は次のように書いています

「要するに、TLS 1.3は今後20年間、より安全で効率的なインターネットの基盤を提供するはずです。」



TLS 1.3の開発には10年かかりました。 Qrator Labsは、他の業界とともに、最初のプロジェクトからプロトコルを作成するプロセスを厳密に追跡しています。 この間、最終的に2019年に世界でバランスのとれた展開しやすいプロトコルが実現されるように、28の連続したドラフトバージョンを作成する必要がありました。 TLS 1.3の市場による積極的なサポートはすでに明らかです。実績のある信頼できるセキュリティプロトコルの実装は、時代の要件を満たしています。



Eric Rescorla(FirefoxのCTOおよびTLS 1.3の単独著者) によると、The Registerとのインタビュー

「これは同じキーと証明書を使用するTLS 1.2の完全な代替品であり、クライアントとサーバーは両方ともTLS 1.3をサポートしていれば自動的に通信できます」と彼は言いました。 「すでに優れたライブラリサポートがあり、ChromeとFirefoxにはデフォルトでTLS 1.3が含まれています。」


並行して、IETF TLSワーキンググループは、古いバージョンのTLS(TLS 1.2のみを除く)が廃止され、使用できないことを宣言するRFC準備を完了しています 。 ほとんどの場合、最終RFCは夏の終わりまでにリリースされます。 これはIT業界のもう1つのシグナルです。暗号化プロトコルの更新を延期すべきではありません。



TLS 1.3の現在の実装のリストは、最適なライブラリhttps://github.com/tlswg/tls13-spec/wiki/Implementationsを探している人のためにGithubで入手できます 。 明らかに、更新されたプロトコルを採用およびサポートすることは-そしてすでに-迅速な措置を講じることになります。 現代の世界で基本的な暗号化がどのようになったかを理解することは、非常に広く普及しています。



TLS 1.2と比較して何が変わったのですか?



インターネット協会からのメモから

「TLS 1.3はどのようにして世界をより良い場所にしますか?」



TLS 1.3には、安全な接続を確立するための簡略化されたハンドシェイクプロセスなど、特定の技術的利点が含まれ、クライアントがサーバーとのセッションをより速く再開できるようにします。 これらの手段は、暗号化されていないHTTP接続のみを提供する口実としてよく使用される、弱いチャネルでの接続遅延と失敗した接続の数を減らすように設計されています。



同様に重要なのは、SHA-1、MD5、DES、3DES、およびAES-CBCなどの以前のバージョンのTLSで引き続き使用が許可されている(推奨されませんが)いくつかのレガシーで安全でない暗号化およびハッシュアルゴリズムのサポートが排除されたことです。新しい暗号スイートのサポートを追加します。 その他の機能強化には、より多くの暗号化されたハンドシェイク要素(たとえば、証明書情報交換が暗号化される)が含まれ、潜在的なトラフィックインターセプターへのヒ​​ントの量を削減し、特定のキー交換モードを使用するときの前方秘匿性を改善して、常に通信が維持されるようにします「暗号化に使用されるアルゴリズムが将来危険にさらされる場合でも、安全です。」



最新のプロトコルとDDoSの開発



すでに読んだかもしれませんが、プロトコルの開発中およびその後でも 、IETF TLSワーキンググループで重大な矛盾が生じました。 個々の企業(金融機関を含む)が、現在プロトコルに統合されている完全な前方秘匿プロトコルに適応するために、自社のネットワークを保護する方法を変更する必要があることはすでに明らかです。



これが必要であるかもしれない理由はスティーブフェンターによって書かれた論文で概説されます。 20ページのペーパーでは、企業が帯域外トラフィック(PFSでは許可されていない)を解読して、規制要件を監視し、規制要件に準拠し、アプリケーションレベル(L7)でDDoS攻撃に対する保護を提供する場合の例をいくつか挙げています。







規制要件を議論する準備は完全に整っていませんが、適用されるDDoS攻撃を無効にする独自の製品(機密情報や機密情報の開示を必要しないソリューションを含む)は、PFSを念頭に置いて2012年に作成されたため、クライアントおよびパートナーに変更はありませんTLSのサーバー側バージョンをアップグレードした後、インフラストラクチャは必要ありませんでした。



また、実装時から、トランスポート暗号化に関連する問題は確認されていません。 公式:TLS 1.3は本番環境で使用する準備ができています。



ただし、次世代プロトコルの開発にはまだ問題があります。 通常、IETFでのプロトコル開発の進展は科学研究の結果に大きく依存するという事実から成り、分散型サービス拒否攻撃を無効化する業界の学術研究の状態は非常に嘆かわしいです。



したがって、良い例はIETFドラフトのセクション4.4 「QUIC Manageability」です。これは、将来のQUICプロトコルスイートの一部です。「DDoS攻撃を検出および無効化するための最新の方法には、通常、ネットワークフローデータ。



実際、後者は実際の企業環境では非常にまれであり(インターネットプロバイダーに部分的にしか適用できません)、実際の世界ではほとんど「一般的なケース」ではありませんが、通常はテストによってサポートされない科学出版物に常に表示されますアプリケーションレベルの攻撃を含む、潜在的なDDoS攻撃の全範囲。 後者は、少なくともTLSのグローバル展開により、ネットワークパケットとフローの受動的な測定では明らかに検出できません。



同様に、DDoS中和装置のメーカーがTLS 1.3の現実にどのように適応するかはまだわかりません。 帯域外プロトコルのサポートは技術的に複雑なため、アップグレードには時間がかかる場合があります。



研究の正しい目標を設定することは、DDoS中和サービスプロバイダーにとって大きな課題です。 開発を開始できる分野の1つは、IRTFのSMART研究チームです 。そこでは、研究者が業界と協力して、問題の業界に関する独自の知識を磨き、新しい研究の方向性を見つけます。 また、もしあれば、すべての研究者を温かく歓迎する準備ができています-DDoS研究に関連する質問や提案、またはrnd@qrator.netの SMART研究グループにご連絡ください。



All Articles