SASEとTLS 1.3（パート1）：TLS 1.3に「対応」とは

TLSは、Webサイトやクラウド サービスとの安全な通信に必要な最重要プロトコルであり、ベンダーはSASE（セキュア アクセス サービス エッジ）市場の開拓に熱心であればあるほど、TLSを大規模に実装する能力を備える必要があります。それには、SASEの”セキュリティ クラウド”向けコンピューティング インフラストラクチャ、ネットワーク インフラストラクチャも、同様に高度に設計する必要があるだけでなく、TLSそのものについても、細心の注意を払う必要があります。

TLS 1.3はTLSの最新バージョンであり、完成してから既に2年以上が経過しています。TLS 1.3には大きな利点が複数あること、また、しばらくの間はさらに新しいバージョンのTLSはでてこないであろうと考えられているため、多くのセキュリティ ベンダーが「TLS 1.3対応」を掲げているのは自然な流れと言って良いでしょう。しかし注目すべき点は、「対応」という概念がいかにあいまいかということです。そこで本記事では、TLS 1.3がSASEおよびいずれSASEとなるシステムが採用される場面、TLS 1.3「対応」が意味する内容、これらがエンタープライズ セキュリティにとって重要な理由について簡潔に説明します。

TLS 1.3の重要性

TLS 1.3について時間をかけて考えたことのある人はほとんどいないでしょうし、このテーマについて強い思いがある人も少ないことを前提とすると、「このプロトコルってそんなに重要？」という疑問が当然のごとく湧いてくると思います。しかし、TLS 1.3はセキュリティに間違いなく貢献しており、また、Webサイトの重要箇所で使用されているため、その重要性については確かな根拠があるのです。 

TLS 1.2からのアップデートは比較的少ないものの、これらの変更は、最近注目を集めている攻撃の多くを排除·軽減するために重要です。セキュリティとパフォーマンスに関するTLS 1.3の変更点については、他のさまざまなブログでまとめられています。深刻な攻撃を1つ排除することも重要ですが、TLS 1.3を採用すれば、それを超える成果を得ることができます。

SSL Labsの統計によれば、TLS 1.3はSSL/TLSのベストバージョンとして、Alexa 150K（世界で最も有名なWebサイトのトップ150,000）の25%で採用されています。TLS 1.3は広く普及していると言っても過言ではないでしょう。

このように、TLS 1.3の重要性に疑問の余地はありません。では、TLS 1.3は、SASEシステムのどこに採用されているのでしょうか？

TLS 1.3が採用される場面

SASEおよびSASEたり得る製品では、TLS 1.3に対応すべき場面が基本的には3つあります。プロキシ、トンネル、そして管理コンソールです。 

最初はTLSプロキシの機能で、これは最重要のケースと言って良いでしょう。信頼性の高いセキュリティ プロキシは、クライアント/サーバー間のTLS通信を効果的に仲介し、暗号化されているトラフィックを復号し、検査できます。信頼性の高いセキュリティ プロキシでTLS 1.3に対応することは非常に重要で、対応できない場合はプロキシそのものの使用によりセキュリティが事実上低下してしまうことがあります。このような場合、本来はTLS 1.3で実行できるクライアント/サーバー間の通信に対し、その代替手段として、脆弱性があることがわかっているTLS 1.2を使用することになります。

TLS 1.3が重要となる2つめの場面は、トンネル内、例えばゼロ トラスト ネットワーク アクセス（ZTNA）製品や機能などです。TLS 1.3をトンネル トランスポートとして使用することは良いことですが、その重要性はプロキシの場合よりも低くなります。これは、通信を行うトンネル エンドポイントの両端が、セキュリティ ベンダーにより制御されているためです。これはプロキシの場合では実現が不可能であり、トンネルを使用する場合の特徴です。TLS 1.2はTLS 1.3よりも安全性の低いプロトコルですが、脆弱な暗号化方式や同様にローカルでの変更を削除することで、TLS 1.2の特定のインスタンスを”強化”できます。プロキシの場合ではこれとは異なり、通信するエンドポイント システムの脆弱性を判断する手段がありません。 

SASEおよびSASEたり得るシステムでTLS 1.3の機能が重要となる3つ目のケースは、管理コンソールとの通信です。権限を持つユーザーは管理コンソールを使用してポリシーを設定し、インシデントを分析します。そのため、リスクにさらされるデータの内容は非常に重要なものになる場合がありますが、セキュリティ クラウドによりプロキシおよびトンネリングされるデータ量と比較した場合はそのデータ量は非常に少ないものです。管理コンソールとの通信の場合、通信を行うエンドポイントの両端は組織のセキュリティ チームによって制御されます。そのためこの場合でも、ユーザーが数多くのクラウド サービスと通信する場合では不可能だった手法で、TLS 1.2を”強化”できます。 

「弊社の製品はTLS 1.3に対応しています」とは

TLS 1.3に「対応」した製品にTLS 1.3トラフィックを送信しても大丈夫であるということは、誰もが納得するあたりまえのことでしょう。ですが、これは解釈の幅が広い文言であり、特に、”大丈夫”という意味がそれぞれ異なる場合は、その違いは顕著に現れます。プロキシの場合にTLS 1.3に「対応」することが意味する内容には、（少なくとも）3つの定義が考えられます。また、そのうち実際にプロトコルを実装する必要があるものは1つだけです。3つの選択肢はそれぞれ、”真のTLS 1.3対応”、”ダウンネゴシエーションによる対応”、”バイパスによる対応”と呼ぶことができます。 

真のTLS 1.3対応

まず「真の」対応について説明しましょう。プロキシがTLS 1.3に対応しているとされている場合に、ほとんどの人が期待するものであり、また、Netskopeがプロキシとして実装しているものです。ここで定義される「真にTLS 1.3に対応した」プロキシは、クライアントとサーバーが「TLS 1.3のみ」を要求する場合でも、TLS 1.3を使用した高度なセキュリティ機能を提供します。TLS 1.3はTLS 1.2よりも優れた暗号化機能とハンドシェイクの方法を備えており、セットアップがより安全で高速です。これが、クライアントとサーバーがこの新しいプロトコルを使うべき明確な理由となっています。 

TLS 1.3通信を使用することがクライアントとサーバーにより明示されている場合にそれを使って高度なセキュリティ機能を提供するためには、製品にTLS 1.3を必ず実装する必要があります。これは、きわめてシンプルです。 

ダウンネゴシエーションによる「対応」

では、ほとんどのTLSクライアントとサーバーがそうですが、クライアントとサーバーの制約がもう少し緩い場合を考えましょう。クライアントとサーバーが「TLS 1.2を受け入れている」場合に完全なセキュリティ機能を実行するプロキシは、「ダウンネゴシエーションによりTLS 1.3に対応」していると言えます。プロキシはクライアントからTLS 1.3接続リクエストを受信します。ですが、それはTLS 1.2にネゴシエートされ、その後TLS1.2接続がサーバーに対して開かれます。これが、この手法の基本的な「トリック」で、実質的には、プロキシに追加されたこの「対応」は、TLS 1.3リクエストを認識し、”大丈夫、うまくやっておきます！”というレスポンスをクライアントに送信しているだけです。それ以外の点では、TLS 1.2とまったく同じ状況です。 

このダウンネゴシエーションによるアプローチは、厳密な意味での真のTLS 1.3対応より劣ることは明らかです。では、ダウンネゴシエーションの良い点と悪い点を考えてみましょう。悪い点は、接続のセキュリティがプロキシによってこっそりダウングレードされてしまうことです。クライアント/サーバー間の接続はもともとTLS 1.3接続であったにもかかわらず、すべてTLS 1.2接続として処理されます。良い点としては、安全性で劣るこのトラフィックに対しても、プロキシによりセキュリティ機能が実行されることが挙げられます。

バイパスによる「対応」

3つ目の定義はどうでしょうか。TLS 1.3トラフィックがプロキシにより処理されていない場合、そのプロキシは、「バイパスによりTLS 1.3に対応」していると言い、「クライアントまたはサーバーがTLS 1.3の使用を要求している」場合、セキュリティ機能はまったく実行されません。この奇妙な「対応」の場合、プロキシはTLS 1.3を、バイパスする対象として認識します。 

ダウンネゴシエーションによる場合と同様、バイパスによるアプローチが厳密な意味での真のTLS 1.3対応より劣ることは明らかです。ここでも、バイパスによる良い点と悪い点を見てみましょう。良い点として、このアプローチではダウンネゴシエーションによるアプローチのように、クライアントとサーバーの通信のセキュリティが勝手にダウングレードされることはありません。クライアントとサーバーは、引き続き推奨のTLS 1.3を介して通信します。悪い点として、このアプローチの場合、プロキシのセキュリティ機能がバイパスされることで通信に対して影響を及ぼさなくなります。この場合、TLS 1.2にダウングレードされる場合よりもさらに悪い結果になる可能性があります。

また、ダウンネゴシエーションとバイパスを組み合わせて使用する場合もあります。この場合、クライアントがTLS 1.3を使用してプロキシに接続すると、プロキシがサーバーに対するTLS 1.2接続の可否を確認します。TLS 1.2接続を開ける場合、プロキシは接続をダウンネゴシエーションします。開けない場合、接続をバイパスします。

選択肢のまとめ

以下の表は、プロキシの実装における選択肢、およびサーバーがTLS 1.2を受け入れる場合とTLS 1.3を要求する場合について、それぞれ対応する結果をまとめたものです。クライアントは、すべての接続でTLS 1.3接続を開始します。

Only the top row for “True TLS 1.3” works correctly, with full functionality, for both kinds of servers. All the other entries involve a weakening of the protocol, a bypassing of security functionality, or the complete failure of the client/server connection. It’s perhaps a little hard to believe that anyone would really describe the last three rows as “supporting” TLS 1.3, but that kind of exaggeration is common when marketers get carried away. In Part Two, we’ll get specific about Netskope and some competitors, identifying how each company’s proxy implements (or fails to implement) true TLS 1.3.