世界はに移動しています TLS 1.3、これはとても良いことです！ この記事では、 TLS 1.3、およびその新機能の有効性に関する議論。
トランスポート層セキュリティ
トランスポート層セキュリティ、または TLSは、コンピュータネットワークを介して交換されるデータを保護する暗号化プロトコルです。 TLS として有名になった S in HTTPS。 すなわち、 TLS ネットワーク攻撃からWebユーザーデータを保護するために使用されます。
TLS 前任者のより安全な代替品として設計されました セキュア·ソケット·レイヤー （SSL）。 何年にもわたって、セキュリティ研究者はSSLに影響を与える脆弱性の山を発見し、IETFが設計する動機となった TLS それらを軽減するための努力で。
皮肉なことに、以前のバージョン TLS 危険な脆弱性の影響も受け、最終的には TLS 1.2（つまり、業界の専門家が推奨するデフォルトのバージョン）。
既知のプロトコルの脆弱性の大部分は、 TLS 1.2ですが、このレベルのセキュリティは、欠陥のある設計の上に一連のパッチを適用した結果です。
応答として、 TLS 1.3は、モダンで安全なものをきれいに設計するために、ゼロから作成されました TLS プロトコル。 XNUMX年後のテストで、ようやく承認され、現在ではデフォルトのインターネットセキュリティ標準に近づいています。
TLS バージョンとそれぞれのRFCドキュメントは、以下のリストにあります。
- TLS 1.0は次のように公開されました RFC 2246 in 1996
- TLS 1.1は次のように公開されました RFC 4346 in 2006
- TLS 1.2は次のように公開されました RFC 5246 in 2008
- TLS 1.3は、提案された標準として RFC 8446 2018インチ
どのように古い TLS バージョンは機能しますか？
の利点について効果的に議論する TLS 1.3、私たちは最初に何歳かについて話さなければなりません TLS バージョンは機能します（機能しません）。
TLS ハイブリッド 暗号システム、つまり両方を使用する 非対称の （公開鍵）および 対称の （パスワード/フレーズベース）暗号化。 これは、に起因するものです 非対称暗号 対称的な同等物よりも桁違いに遅い。
その結果、 TLS は公開鍵のみを使用するため、クライアントとサーバーは対称鍵を安全に交換できます。 その後、この鍵を使用して以降のすべての通信を暗号化し、非対称暗号化によるパフォーマンスのオーバーヘッドを回避できます。
TLS 1.2は、複数の鍵交換アルゴリズム（RSA、DHなど）と、いくつかのアルゴリズム（別名 暗号）メッセージの暗号化と復号化に使用されます。 この大量の代替オプションでは、クライアントとサーバーがネゴシエートする必要があるため、すべての関係者が同じ TLS パラメーター。
この交渉は、次のプロトコルで標準化されています。 握手。 よくわからない場合は、 この記事 をご覧ください。
だから何が悪いの TLS 1.2？
しかし TLS 1.2はほとんどの場合に問題なく動作することが証明されていますが、何年にもわたるパッチと改訂の後に提供されるセキュリティとプライバシーの全体的なレベルに懸念があります。
ただし、セキュリティ上の考慮事項は別として、 TLS 1.2は、不要なパフォーマンスとネットワークオーバーヘッドも課します。
TLS 1.2のセキュリティ問題
長年にわたり、研究者（および攻撃者）は多くの脆弱性を発見しました TLS 鍵交換アルゴリズム、暗号、デジタル署名などの1.2コンポーネント。 これらのいくつかは、あなたが聞いたことがあるかもしれない実装バグでした。 ハートブリード or ベルセルク。 ただし、一部はプロトコルの脆弱性でした。つまり、以前の設計上の誤った決定を悪用しています。 TLS バージョン（つまり、以前 TLS 1.2）。
実装やその他のバグの大部分は修正されましたが TLS 1.2、残念ながら、プロトコル設計の脆弱性は、ソフトウェアパッチだけでは修正できません。 結局のところ、IETFはそのためにハンドシェイクプロトコルを完全に再設計する必要がありました。 TLS 1.3.
について多くの懸念がありました TLS セキュリティ、しかし最も影響力のあるもののXNUMXつは、 TLS 1.2（およびSSLを含む以前のすべてのバージョン）は、ハンドシェイクプロトコル設計の欠陥により、ダウングレード攻撃に対して脆弱です。 すなわち、 TLS 1.2は、ハンドシェイクの整合性を保護するためにデジタル署名を使用しません。 署名は、暗号スイートネゴシエーションの後でのみ、ハンドシェイクの一部を保護します。
結果として、攻撃者は同じコンピューターネットワーク（空港のwifiなど）で発生するサードパーティの暗号スイートネゴシエーションを操作し、安全でない暗号の使用を強制できます。 その後、その脆弱な暗号を解読し、会話全体への不正なアクセスを獲得する可能性があります。
TLS 1.2パフォーマンスの問題
これらのセキュリティ上の考慮事項に加えて、 TLS 1.2は多数を交渉する必要があります TLS パラメータは、HTTPS（または他の TLS 保護された）通信。
TLS 1.2の4ステップハンドシェイクでは、最初に暗号スイートを選択し、次に証明書と対称鍵（または鍵共有）を交換するために、XNUMX回の往復交換が必要です。
これは、 TLS 確立される接続、 XNUMXつの追加トランザクション サーバーが必要です。 結果として、 TLS 接続には、（暗号化されていない）HTTPよりも多くの帯域幅と電力が必要です。これは、低電力と帯域幅の消費が厳しい制約であるモノのインターネット（IoT）アプリケーションにとって特にコストがかかる可能性があります。
TLS 1.2プライバシーの問題
最後に、 TLS 1.2は、Webユーザーのプライバシーを侵害することで批判されています。
すなわち、 TLS として知られている拡張機能を提供します サーバ名表示 またはSNI。 SNIでは、サーバーのホスト名を初期SSLハンドシェイクに含めることができます。 この拡張機能は仮想ホスティングに使用され、サーバーは同じIPアドレスとポートで複数のドメインにサービスを提供し、ドメインごとに異なる証明書を提示できます。
In TLS 1.2、SNIが送信される 暗号化されていない、そのため、HTTPSを使用しているにもかかわらず、ネットワーク攻撃者はこの情報を漏洩し、ユーザーがアクセスしたWebページを追跡できます。
どのように TLS 1.3すべてを修正しますか？
TLS 1.2（およびそれ以前のバージョン）は、下位互換性の維持に重点を置いていました。 以前のバージョンに基づいて構築された各バージョンは、間に発行された脆弱性を排除しようとするマイナーリビジョンを備えています TLS バージョン。
残念なことに、これはまた、プロトコル設計の誤った決定（たとえば、保護されていないハンドシェイク）が新しいバージョンにも継承されたことを意味します。
TLS 1.3は、適切なセキュリティ設計を支持して、下位互換性を放棄します。 ゼロから設計されており、（まだ互換性はありませんが）と同様の機能を提供します。 TLS 1.2、ただしパフォーマンス、プライバシー、セキュリティが大幅に改善されています。
TLS 1.3セキュリティ
の核となる信条 TLS 1.3は単純です。 新しいバージョンでは、 Diffie-Hellman （DH）鍵交換、削除されました。 TLS 1.3では、一連の試行済みのDHパラメータも定義されているため、サーバーとパラメータをネゴシエートする必要がありません。
そのうえ、 TLS 1.3は、CBCモードやRC4暗号などの不要または脆弱な暗号をサポートしなくなりました。 これらの暗号は攻撃を受けやすいことが知られていますが、ほとんどの場合まだサポートされていました TLS レガシー互換性のための実装。 幸いなことに、ダウングレード攻撃の最近のラッシュは初期に影響を与えています TLS バージョンは、IETFにそのような暗号を完全に削除する動機を与えました TLS 1.3.
加えて、 TLS 1.3では、サーバーが暗号ネゴシエーションを含む全体のハンドシェイクに暗号で署名する必要があります。これにより、攻撃者はハンドシェイクパラメータを変更できなくなります。 この意味は TLS 1.3は、以前に影響を受けたダウングレード攻撃にアーキテクチャ的に影響されない TLS バージョン。
最後に、署名自体も呼ばれる新しい標準を実装することによって改善されました RSA-PSS。 RSA-PSS署名は、以前に採用された署名スキームに影響を与える暗号攻撃の影響を受けません TLS バージョン。
TLS 1.3のパフォーマンス
セキュリティの向上に加えて、パラメータのセットが減り、ハンドシェイクが簡素化されました。 TLS 1.3は、全体的なパフォーマンスの向上にも貢献します。 鍵交換アルゴリズムはXNUMXつだけ（焼き付けられたパラメーターを使用）であり、サポートされている暗号はほんの一握りであるため、 TLS 1.3チャネルは以前のバージョンよりもかなり少ないです。
また、 TLS 1.3は、新しいハンドシェイクプロトコルをサポートしています。 1-RTTモード。 1-RTTでは、サーバーが使用するパラメータをかなり確実にすることができるため、クライアントは最初のハンドシェイクメッセージでDHキーシェアを送信できます。 サーバーがそれらをサポートしないまれなケースでは、クライアントが別の構成を送信するようにエラーを生成する可能性があります。
最初にパラメータをネゴシエートしてから鍵または鍵シェアを交換する代わりに、 TLS 1.3では、クライアントが TLS （以前に行われたXNUMXつではなく）往復トランザクションがXNUMXつだけのチャネル。 これは、クライアントがサーバーと通信するために必要な処理、電力、およびネットワークリソースに大きな累積的な影響を与える可能性があります TLS 1.3.
パフォーマンスの最適化はここで止まらず、別の TLS 1.3と呼ばれる機能 0-RTT再開モード。 ブラウザがサーバーに初めてアクセスして、正常に完了したとき TLS ハンドシェイク。クライアントとサーバーの両方が事前共有暗号化キーをローカルに保存できます。
ブラウザが再びサーバーにアクセスした場合、ブラウザはこの再開キーを使用して、暗号化されたアプリケーションデータを最初のメッセージでサーバーに送信できます。 最初のハンドシェイクが必要ないため、これは暗号化されていないHTTPと同じレイテンシです。
いくつかのセキュリティがあったことに注意すべきです 懸念 過去の0-RTTモードについて。
TLS 1.3のプライバシー
過去の過ちから学び、 TLS 1.3は、 SNI情報を暗号化します。 この拡張機能を正しく使用すると、攻撃者がリモートサーバーのドメイン名を漏洩することが防止されるため、HTTPSユーザー履歴を追跡する方法がありません。 この機能は、以前のバージョンのインターネットユーザーよりも優れたプライバシーをインターネットユーザーに提供します TLS.
結論
一方、 TLS 1.2はこれらすべての年の間に立派に役立ってきました、 TLS 1.3は、おそらくより安全で効率的です。 TLS 1.3は、実験的なブラウザ実装で広範囲にわたってテストされており、現在は置き換える準備ができています TLS 選択したネットワークセキュリティプロトコルとして1.2。 出版 TLS 1.3は、すべての人にとってより高速で安全なインターネットに向けた大きな一歩です。
SSL.comをお選びいただきありがとうございます。 より安全な インターネットは 優れた インターネット。
