SASEとTLS 1.3（パート2）：ベンダー選定の注意点

パート1では、SASEのサービスにおいてTLS 1.3への対応に関係するそれぞれ3つの場面を見てきました。重要性の高い順から、プロキシ、トンネル、そして管理コンソールです。また、ベンダーが「TLS 1.3に対応」する際、その方法には3種類あることもお伝えしました。品質が高い順に、「真の対応」「ダウンネゴシエーションによる対応」「バイパスによる対応」となります。 

TLS 1.3は完成してから既に2年が経過しており、また使用するメリットが高いにも関わらず、プロキシにおける真のTLS 1.3対応を未だに提供していないセキュリティ ベンダーが存在しているのは驚くべきことです。そうしたベンダーがTLS 1.3に対応しているという誤った情報を公言する人もいるため、余計に気を付けなければなりません。根拠に乏しく、事実が脚色されていると言わざるを得ませんが、営業トークとして耳にすることもあるでしょう。

ここでは有名なベンダーをいくつか挙げ、各社における対応についてお話ししていきます。

既にお伝えしている通り、Netskopeのサービスにおいては、プロキシで真のTLS 1.3対応を行っています。Netskopeのほかにも、同様に真のTLS 1.3に対応しているベンダーを少なくとも6社確認していますが、セキュリティ ベンダーに求められる期待に応えているに過ぎないので、当然のことと言えるでしょう。むしろ驚くべきは、未だTLS 1.3に真の対応をしていない、もしくは、しばらく対応する見込みがないベンダーがいるという点です。 

例えばZscalerは、「ダウンネゴシエーションとバイパス」の組み合わせを採用しています。つまり、TLS 1.3を要求された場合に必ずしも接続を遮断しないため、クライアントとサーバーは通信を続けることが可能です。しかし実際には、TLS 1.3での接続ではセキュリティ処理が行えないため、新たな接続要求を受ける度に、TLS 1.3による接続とセキュリティ処理のどちらを断念するか、クラウド側が判断しているというわけです。 

TLS 1.3を使うユーザーが、Zscalerを介してTLS 1.2を用いるサービスに接続を試みた場合は、接続は都度ダウングレードされます。しかし、こうしたユーザーがTLS 1.3を要求するサービスに接続しようとすると、接続はその都度完全にバイパスされるため、Zscalerのセキュリティ検査を通らないということになります。別の方法がないわけではありません。このような場合、Zscalerは復号不可能なトラフィックとしてこの接続をブロックすることもできます。セキュリティが実行されないという点は変わりないのですが、状況によってはブロックする方がよい場面もあるでしょう。いずれにしても、「セキュリティを遮断する」か「サービスを許可しない」の2択のみという状況が好ましくないということは、明白にご理解いただけるのではないでしょうか。）  

Symantec WSSは、現時点ではダウンネゴシエーションのみの戦略であると見てとれます。互換性を維持するため、ほとんどのサーバーはTLS 1.2に対応しており、一般的な状況ではSymantec WSSもZscalerと同様に動作すると考えられます。クライアントが単独で接続する場合に比べ、そのパフォーマンスもセキュリティも低下しますが、それでもクライアントはサーバーへの接続を継続でき、Symantec WSSのセキュリティ処理も引き続き実行されます。しかし、サーバー側がTLS 1.2のネゴシエートを拒否した場合、クライアントとサーバーがお互いにTLS 1.3を使用しているのにもかかわらず、接続できないという事態に陥ってしまいます。こうした状況を鑑みると、Symantec WSSはセキュリティ強化どころか生産性の低下を引き起こしてしまっていると言えるでしょう。 

概ね確実に言えることは、今名前を挙げたベンダーも、最終的にはこうした課題を解決するだろうということです。実際、あなたがこの記事を読む頃にはすでに解決済みかもしれません。そうすると、今お話ししている内容は見当違いになるでしょうか？いいえ、そのようなことはありません。驚くほど時間がかかっていることに変わりはないからです。私たちが初めて競合数社のサービスにこうした脆弱な点を見つけたのは、2019年12月初旬のことです。この時、NetskopeはすでにTLS 1.3に対応していました。当然すぐに動きがあるだろうと考えていましたが、今はもう2020年10月です。TLS 1.3の実装など、実のところ大して重要でないと考えるベンダーもいるのかもしれない、とも思い始めました。彼らはTLS 1.3を実装する代わりに、パート1でお伝えしたような方法で「対応」してきたのでしょう。 

どこから情報を得るべきか

ベンダーがTLS 1.3へどのように対応しているか、どうすれば見極められるでしょうか？本記事およびパート1からもわかる通り、聞けばすぐにわかるというほど単純ではありません。

アプローチとして最も確実なのは、関心のある製品を実際に使ってみることです。簡単に調べる方法を1つお教えしましょう。Firefoxを使い、当該サービスのプロキシを介してfacebook.comにアクセスしてください。ツール>ページ情報>セキュリティの順に進むと、そこでブラウザの接続に関する詳細情報を見ることができます。 

• TLS 1.3による接続が、プロキシベンダーの証明書で保護されていることが確認できるでしょうか。これが確認できれば、トラフィックがプロキシを通過する際、TLS 1.3が使われているということになります。 
• 接続がTLS 1.2となっている場合、これはプロキシがダウンネゴシエーションされたということを意味します。 
• 接続はTLS 1.3となっているものの、Facebookの証明書で保護されているようであれば、プロキシによってバイパスされたと考えられます。

次に参考となり得るのはベンダーのサポート サイトですが、いくらか調査が必要となるかもしれません。ZscalerもSymantecも、TLSの対応に制限があることを認めてはいるものの、それを明示しているわけではないからです。Zscalerのサポートサイトには現在対応しているプロトコルが列挙されていますが、ここにTLS 1.3は含まれていません。また、Symantec WSSの製品を扱うBroadcomのサポート サイトでは、ブラウザでTLS 1.3を無効にする方法を説明し、この問題に対処しています。 

ベンダーのコーポレート ブログ、あるいは第三者のウェブサイトはどうでしょうか？少なくとも経験上、そのようなサイトの情報はクオリティが著しく低いように思います。例えばZscalerのコーポレート ブログには、TLS 1.3に関して長文の記事が掲載されています。ZscalerがTLS 1.3に対応していないことについて、記事の中で実際に断言はしないものの、暗にほのめかそうという意図が伺えます。丁寧に読めば記事が決して間違っていないということがわかりますが、実直なコミュニケーションという観点から見れば模範的ともいえないでしょう。

同様に興味深いのが、Brian Deitch氏が2018年に投稿したブログです。ZscalerがTLS 1.3に全面的に対応していると主張していますが、これは誤った情報です。投稿の内容は概ね老舗のITベンダーに対する不満で、的を射ている部分もあります。しかし2020年現在、Zscalerが「未だに」TLS 1.3に対応していないという事実を踏まえると、この著者の見解になにかしらの不備があったと考えざるを得ません。 

Symantecのコーポレート ブログにも同じような事象が見られます。DoHに関する投稿があり、制御の強化に向けてTLS 1.3対応のプロキシを使用することに言及していますが、Symantec WSSでそうしたプロキシを運用していないことについては明確に述べていません。この投稿についても、じっくりと読めば嘘が書かれているわけではないと理解できます。ただ、読者がこの記事で現状を正しく把握できるとは思えないのです。 

終わりに 

パート1では、TLS 1.3への対応の影に意外な複雑さが潜んでいることをお伝えし、SASEを提供している、あるいはこれから提供しようというあらゆるベンダー側でなにが起こっているのか、理解への足がかりとなるものを提示してきました。繰り返しとなりますが、TLS 1.3への対応における重要性をお話したものの、「だからなに？」と思われる部分もあったでしょう。今回の記事では、具体的なベンダーを例に挙げました。ほかのベンダーに対して同様のアプローチを考えている方のために、以下に留意点をまとめました。

• TLS 1.3は、セキュリティにもパフォーマンスにも影響します。TLSトラフィックがプロキシを通過する際、ベンダーがどのような対応をしているのか詳細をご存知ないのであれば、パフォーマンスを犠牲にするだけでなく思わぬ脆弱性を抱えている可能性があります。 
• TLS 1.3への「対応」は、あなたが想定する内容と異なっている場合があります。このプロトコルにベンダーが「対応」する際、その方法は複数あるという点に注意してください。
• 実際に製品を利用してみること、そしてベンダーのサポートサイトをよく読むことは、状況を深く理解するにあたって有効な方法です。
• コーポレート ブログや第三者のウェブサイトは、情報源として信頼性が低い可能性があります。