TLS 1.3を有効にしました。 なぜあなたも同じことをしなければならないのか

TLS 1.3を有効にしました。 なぜあなたも同じことをしなければならないのか

年の初めに、2018 年から 2019 年のインターネットの問題とアクセシビリティに関するレポートが発表されました。 すでに書いたTLS 1.3 の普及は避けられないということです。 少し前に、私たち自身もトランスポート層セキュリティ プロトコルのバージョン 1.3 を展開し、データの収集と分析を経て、ようやくこの移行の機能について話す準備が整いました。

IETF TLS ワーキング グループの議長 書きます:
「要するに、TLS 1.3 は今後 20 年間、より安全で効率的なインターネットの基盤を提供するはずです。」

開発 TLS 1.3 10年という長い年月がかかりました。 私たち Qrator Labs は、業界の他の企業とともに、最初の草案からプロトコル作成プロセスを綿密に追跡してきました。 この間、最終的に 28 年にバランスの取れた導入が容易なプロトコルの光を見るために、ドラフトの 2019 バージョンを連続して作成する必要がありました。 TLS 1.3 に対する市場の積極的な支持はすでに明らかであり、実績のある信頼性の高いセキュリティ プロトコルの実装が時代のニーズに応えています。

Eric Rescorla 氏 (Firefox CTO および TLS 1.3 の単独著者) によると レジスターとのインタビューで:

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


並行して、TLS は IETF ワーキング グループで終了します RFCの準備、古いバージョンの TLS (TLS 1.2 のみを除く) が時代遅れで使用できないことを宣言します。 おそらく、最終的な RFC は夏の終わりまでにリリースされるでしょう。 これは、IT 業界に対するもう XNUMX つのシグナルです。暗号化プロトコルの更新を遅らせるべきではありません。

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

TLS 1.2 以降何が変わりましたか?

インターネット協会のメモ:
「TLS 1.3 はどのように世界をより良い場所にするのでしょうか?

TLS 1.3 には、安全な接続を確立するためのハンドシェイク プロセスの簡素化など、特定の技術的利点が含まれており、クライアントがサーバーとのセッションをより迅速に再開できるようになります。 これらの対策は、接続セットアップの遅延と弱いリンクでの接続失敗を減らすことを目的としており、暗号化されていない HTTP 接続のみを提供することを正当化するためによく使用されます。

同様に重要なことは、SHA-1、MD5、DES、3DES、AES-CBC など、以前のバージョンの TLS での使用がまだ許可されている (ただし推奨されていない) いくつかのレガシーで安全でない暗号化およびハッシュ アルゴリズムのサポートが削除されることです。新しい暗号スイートのサポートを追加します。 その他の改善点には、潜在的なトラフィック盗聴者への手がかりの量を減らすためにハンドシェイクの暗号化された要素が増えたこと (たとえば、証明書情報の交換が暗号化されるようになった) や、特定のキー交換モードを使用するときの転送秘密性の改善が含まれます。たとえ将来、暗号化に使用されたアルゴリズムが危険にさらされたとしても、常に安全性を維持する必要があります。」

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

すでにお読みになったかもしれませんが、プロトコルの開発中に そしてその後も、IETF TLS ワーキング グループ内 深刻な矛盾が生じた。 個々の企業 (金融機関を含む) は、現在組み込まれているプロトコルに対応するために、独自のネットワークを保護する方法を変更する必要があることが明らかになりました。 完全な前方秘密.

これが必要となる理由はドキュメントに記載されています。 スティーブ・フェンター著。 20 ページのこの文書では、企業が監視、コンプライアンス、またはアプリケーション層 (L7) DDoS 保護の目的で帯域外トラフィック (PFS では許可されていない) を復号​​化する必要があるいくつかの例について言及しています。

TLS 1.3を有効にしました。 なぜあなたも同じことをしなければならないのか

私たちには規制要件について推測する準備ができていないことは確かですが、当社独自のアプリケーション DDoS 軽減製品 (ソリューションを含む) 開示を必要としない 機密情報や機密情報など)は、PFS を考慮して 2012 年に作成されたため、クライアントとパートナーは、サーバー側の TLS バージョンを更新した後にインフラストラクチャに変更を加える必要がありませんでした。

また、導入以来、トランスポート暗号化に関する問題は確認されていません。 公式には、TLS 1.3 の運用準備が整っています。

しかし、次世代プロトコルの開発には依然として問題が残されています。 問題は、IETF におけるプロトコルの進歩は一般的に学術研究に大きく依存しており、分散型サービス妨害攻撃の緩和分野における学術研究の状況が悲惨であることです。

したがって、良い例は次のとおりです 4.4セクション 次期QUICプロトコルスイートの一部であるIETF草案「QUIC Manageability」では、「[DDoS攻撃]を検出および軽減する最新の方法には、通常、ネットワークフローデータを使用した受動的な測定が含まれる」と述べられています。

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

同様に、DDoS 軽減ハードウェア ベンダーが TLS 1.3 の現実にどのように適応するかはまだわかりません。 帯域外プロトコルのサポートは技術的に複雑であるため、アップグレードには時間がかかる場合があります。

研究を導くための適切な目標を設定することは、DDoS 軽減サービス プロバイダーにとって大きな課題です。 開発を開始できる領域の XNUMX つは、 SMART研究グループ IRTFでは、研究者が産業界と協力して、困難な業界に関する自身の知識を磨き、研究の新たな道を模索することができます。 また、すべての研究者を温かく歓迎します。DDoS 研究または SMART 研究グループに関する質問や提案については、次の URL で連絡できます。 [メール保護]

出所: habr.com

コメントを追加します