※ 2022 年 11 月 8 日現在の情報をもとに作成しています
1. はじめに
本記事では、Web ポリシーのブロックページが正しく表示されない例を 2 つ紹介します。
※ Web ポリシーを利用するには、SIG またはそれ相当のサブスクリプション契約が必要です
2. Web ポリシーのブロックページ
Web ポリシーのブロックページは、Web ポリシーのセキュリティ設定やコンテンツカテゴリ、接続先リストなどでブロック設定を行った環境において、ユーザーがブロック対象の宛先へアクセスを行った時に Web ブラウザに表示されます。
DNS ポリシーのブロックページの場合、Umbrella の DNS サーバー (208.67.222.222/208.67.220.220) がブロックページ用の IP アドレスを返すことで、ユーザーのアクセスを強制的にブロックページ用の Web サーバーに向かわせましたが、Web ポリシーの場合は少々仕組みが異なります。
Web ポリシーでは、SWG (Secure Web Gateway) がユーザーからの HTTP/S リクエストをブロック対象と判断した際、ブロックページ用の Web サーバーへのリダイレクト情報を含むステータス コード 303 (See Other) の HTTP/S レスポンスをユーザーに返します。
このレスポンスを受け取ったユーザーの Web ブラウザは、リダイレクト先であるブロックページ用の Web サーバーにアクセスし、最終的にユーザーの Web ブラウザにブロックページが表示されます。
3. HTTPS 検査を無効にしている場合
Web ポリシーのブロックページが正しく表示されない例として、Web ポリシー内の HTTPS 検査を無効にしている場合が挙げられます。

HTTPS 検査とは、SWG が HTTPS リクエストを復号し、その中に含まれる URL をもとにブロック判定を行う仕組みですが、この機能が無効になっている場合、SWG は URL を知ることができません。
※ HTTPS 検査はこの他にも HTTPS レスポンスの調査も行います
そこで、SWG は TLS/SSL 通信の Client Hello に含まれる SNI (Server Name Indication) から宛先のドメインを調べます。
もし、そのドメインが Web ポリシー上のブロック対象であった場合、通常であれば、前述のとおり、ユーザーにリダイレクト情報を含む HTTPS レスポンスを返しますが、HTTPS リクエストの中身を把握しているわけではないため、正しい内容の HTTPS レスポンスを作成することができません。
そのため、正常な HTTPS 通信を継続することは諦め、代わりに TCP の RST フラグが立った RST パケットをユーザーに返します。
その結果、ユーザーの Web ブラウザには以下のようなエラー画面が表示されます。
Chrome の場合

Firefox の場合

Microsoft Edge の場合

この動作は、HTTPS 検査が無効の状態でも、ポリシー上ブロック対象であれば、可能な限りユーザーの通信を止めるという考えに基づくものです。
もし、正常にブロックページを表示させたい場合は、HTTPS 検査の設定を「HTTPS トラフィック検査の有効化」または「ブロックされたトラフィックのみを復号化する」に変更します。

前者を選んだ場合、除外設定したものを除き、基本的にすべての HTTPS リクエストが復号され、後者を選んだ場合は、SWG が SNI からブロック対象と判断したもののみ複号されます。
4. ルート証明書をインストールしてない場合
HTTPS 通信の場合において、Web ポリシーのブロック ページを正しく表示させるには、ユーザー側に Umbrella が発行したルート証明書をインストールする必要があります。
これは、SWG がユーザーとの間の TLS/SSL 通信を正常に完了するために、その場限りのサーバー証明書を発行し、その証明書をユーザー側に信頼してもらう必要があるためです。
Umbrella が発行したルート証明書は Umbrella Dashboard の導入 > 設定 > ルート証明書からダウンロード可能です。

もし、ルート証明書をインストールしていない場合、ユーザーの Web ブラウザには以下のような警告画面が表示されます。
Chrome の場合

Firefox の場合

※ HTTP Strict Transport Security (HSTS) という記載がありますが、必ずしも HSTS によるリダイレクトが行われた訳ではありません
Microsoft Edge の場合
