TLS 1.3には大きなメリットがありますが、暗号化がより包括的になることで、悪意のあるトラフィックの検出や暗号化されたトラフィックに潜む攻撃に対する防御が難しくなります。これは実際の脅威であり、最近のF5 Labsの調査によると、マルウェアの68%が暗号化されたトラフィックに潜んでいることがわかっています。更新されたプロトコルで得られるパフォーマンスの向上を維持しながら必要な可視性を確保するために、新たなアプローチが必要となるでしょう。

TLS 1.2と1.3の比較：期待できる改善点

TLS 1.3には、TLS 1.2と比べて大きな改善点がいくつかあります。プロトコルの脆弱なオプション部分が削除され、完全前方秘匿性（PFS）の実装に必要なより強力な暗号がサポートされ、ハンドシェイク プロセスが大幅に短縮されました。

加えて、TLS 1.3の実装は比較的、シンプルです。TLS 1.2で使用したものと同じ鍵を使用できます。クライアントとサーバーの両方がサポートしていれば、クライアントとサーバーの間で自動的にTLS 1.3のハンドシェイクがネゴシエートされます。また、主なブラウザのほとんどが最新のバージョンでデフォルトでこれを行います。

TLS 1.3のセキュリティにおけるメリット

TLS 1.2は依然として安全に導入できますが、注目されているいくつかの脆弱性によってプロトコルのオプション部分や旧式の暗号が悪用されています。TLS 1.3では、これらの問題のあるオプションの多くが削除され、現在のところ既知の脆弱性のないアルゴリズムのみをサポートしています。

IETFは、DES、AES-CBC、RC4、その他一般的にあまり使用されていない暗号を含む、PFSをサポートしないすべての暗号をTLS接続から削除することを選択しました。また、「再ネゴシエーション」と呼ばれる機能も削除されました。この機能によって、すでにTLS接続のあるクライアントとサーバーが新しいパラメータをネゴシエートしたり、新しい鍵を生成したりすることができます。再ネゴシエーションを排除することで、攻撃の可能性がなくなります。

TLS 1.3のプライバシーにおけるメリット

また、TLS 1.3ではデフォルトでPFSも有効になっています。この暗号化技術は、暗号化されたセッションの機密性をさらに高め、2つのエンドポイントのみがトラフィックを復号化できるようにします。PFSを使用すると、第三者が暗号化されたセッションを記録し、後でサーバーの秘密鍵にアクセスできたとしても、その鍵を使用してセッションを復号化することはできません。

TLS 1.3のパフォーマンスにおけるメリット

パフォーマンスの面では、TLS 1.3は接続確立のハンドシェイクからのラウンド トリップ全体が排除されるため、暗号化のレイテンシが半分に短縮されます。別のメリットとしては、前に訪れたサイトにアクセスする場合に、最初のメッセージでサーバーにデータを送信できるようになりました。これは「ゼロ ラウンド トリップ タイム」（0-RTT）と呼ばれています。これらの機能強化と効率的な最新の暗号アルゴリズムによって、TLS 1.3ではTLS 1.2を上回る高速化が実現されます。

TLS 1.3がネットワークとセキュリティに与える影響

これだけのメリットがあって、何が問題なのでしょうか？よい質問です。PFSでは、エンドポイント（Webユーザーとアプリケーション サーバー）のみがトラフィックを復号化できます。しかし、おそらく皆さんは次世代ファイアウォール、侵入検知システム（IDS）、マルウェア サンドボックスなど、ネットワークからの悪意のあるトラフィックを検知するために設計されたソリューションを1つ以上導入しているでしょう。また、ホストするアプリケーションの前にWebアプリケーション ファイアウォール、IDS、または分析ソリューションを配置している場合もあります。これらのソリューションはすべて、ユーザーと、ユーザーが接続しているアプリケーションやWebサイトの間に配置されているため、通常は暗号化されたトラフィックを認識しません。

セキュリティ検査ツールの中には復号化機能を持つものもありますが、これは多くの場合、ツールのパフォーマンスを低下し、ネットワーク アーキテクチャを複雑にしてしまいます。また、やみくもにすべてを復号化すると、プライバシー規制違反を生じる可能性があります。

特筆すべきは、一部のセキュリティ専門家はリプレイ攻撃の可能性を理由に、0-RTT機能に憤慨しています。また、TLS設定で0-RTTを有効にしないと、そもそも実装の動機となったパフォーマンスの向上のほとんどを失いかねません。

WebアプリケーションにTLS 1.3を展開する時期に来ているのでしょうか？

現時点でTLS 1.3を実装するかどうかは、要件や動機次第です。1.3をサポートしていないブラウザもあり、ユーザー エクスペリエンスを悪化させる可能性があります。さらに、再ネゴシエーションのような潜在的に脆弱な機能を削除し、アプリケーションのTLS 1.2設定にPFSを使用すれば、セキュリティとプライバシーの面でTLS 1.3と同じメリットをすべて得ることができます。パフォーマンス向上の可能性に関しては、0-RTTを無効にして苦労しても報われない可能性があるので、これがアプリケーションに当てはまるかどうかを十分にテストする必要があります。

どのような決断をするにしても、前のバージョンのTLSがすぐになくなるわけではありません。Googleの発表によると、2020年までにTLS 1.0と1.1が廃止予定となっているので、TLS 1.2の使用はしばらく続くでしょう。また、一部のポイントツーポイントのAPI接続を除いて、アプリケーションへのユーザーの接続を切断しないようにするために、しばらくの間はTLS 1.2（および場合によっては1.1）のサポートを継続する必要があるでしょう。

TLSによって、暗号化された脅威を認識できない状態にしてはならない

TLSのバージョンにかかわらず、ビジネスを保護するためには、暗号化された脅威の可視化が必要です。パケット検査が可能なSSL/TLSベースの復号化デバイスは、暗号化されたトラフィックの傍受と、ネットワークに出入りする信頼できないTLSトラフィックの復号化、検査、再暗号化が可能ですが、それだけではまだ十分ではありません。

セキュリティ チームやネットワーク運用担当者は、復号化ゾーンの設定が簡単ではないことに気付いています。彼らは、セキュリティ スタック全体で復号化/暗号化を管理するために、手動のデイジーチェイニングや面倒な設定に頼らなければならないことがよくあります。そのうえ、例外がたくさんあることもわかっています。

F5® SSL Orchestrator®は可視性を提供しますが、他社製品と一線を画している理由は、リスクと動的なネットワーク状況に基づいてサービス チェーンにポリシーベースのトラフィック ステアリングを提供するオーケストレーションにあります。SSL Orchestratorは、SSL/TLSとHTTPの両方のフル プロキシとして機能するため、インテリジェントな決定を行って、インバウンドとアウトバウンドのトラフィックをセキュリティ スタック内の検査ツールの任意の組み合わせに誘導することができます。

インバウンドとアウトバウンドの暗号化要件がどれほど複雑であっても、SSL Orchestratorは検査ソリューションに可視性を取り戻し、ネットワークとアプリの安全性を高めることができます。