2025年4月1日

1. はじめに

HTTP通信の可視化はFlowmonを導入いただいているお客様の中で好評いただいている機能の一つですが、近年ではそのほとんどがHTTPSの暗号化通信となっています。Web通信におけるプライバシー確保のニーズは高まっており、常時SSL化の動きも急速に広まっていますが、ネットワーク管理者の立場では社内のWeb通信を可視化したいというような相反するご要望も存在します。そこで本コラムでは先月と今月の二回にわたりHTTPSの秘匿された通信がトラフィック可視化ツールFlowmonでどのように視えるのかを解説いたします。パート2となる今月は、Flowmonの実機を用いて実際のHTTPS通信がどのように可視化されるのかを検証していきます。なお、パート1となる先月のコラムではHTTPS通信の暗号化の仕組みを解説しておりますので、本コラムを読む際の予備知識として参考にしていただければ幸いです。前回の記事はこちらからご覧いただけます。

2. HTTPS利用状況

レポート機能を用いて、ある1週間を対象に社内通信のHTTPS利用状況を見てみました。まずHTTPとHTTPSの利用割合ですが、この週では約93%（バイト）がHTTPSの通信となっていました（ポート443の通信をHTTPS、80の通信をHTTPとしています）。

図1：HTTPS利用状況

HTTPSの暗号化を担うTLSのバージョンもFlowmonで可視化できます。前回のパート1でもご紹介したように、TLS 1.2以前とTLS 1.3以降では暗号化の仕組みや暗号化される通信の範囲が異なります。どのバージョンを利用するかはTLSハンドシェイクの初めにネゴシエーションされ、Client Helloからクライアントの希望するバージョンを、Server Helloからサーバが採用したバージョンをそれぞれ確認できます。

図2：TLSバージョン（サーバ）の統計

図3：TLSバージョン（クライアント）の統計

サーバ、クライアント共に1位は「N/A（Not Available）」となっていますが、これはFlowmonで取得できなかったものや未対応のものとなり、最新のHTTP/3で利用されているQUICの通信などはここに含まれます。QUICについては本コラムの最後の方で解説いたします。

サーバ側の2位以降は、「TLS 1.2」が3割、「TLS 1.3」が2割、そして「TLS 1.0」やRFCとしてリリースされる前の草案となる「TLS 1.3 (Facebook draft 23)」も見られました。

クライアント側の2位以降は、「TLS 1.3」及び「TLS 1.2」が共に2割程度となり、4 ~ 19位には「GREASE#0x****」というものが入っていました。GREASEとはTLS 1.2及び1.3で使われる全部で16個の予約された値で、プロトコルの拡張性を確保するために用いられます。どのように使われるかというと、例えばWebサーバでTLSの実装に問題があった際、未対応の拡張が含まれたパケットを受信した際に接続が失敗してしまうことがあります。そこで、クライアントから意図的に無意味な値（0x****で表記されている16進数の値）をClient Helloに挿入して送信することで、サーバがこれを無視して接続を続行できるかテストします。

3. HTTP情報取得のためのFlowmon設定

HTTP情報は通常のNetFlow/IPFIXでは取得できませんが、Flowmon Probeを用いてフロー生成を行うことで可視化できるようになります。本コラムの検証では、以下の情報を用いました。

• HTTPフィールド：HTTPヘッダから取得可能な情報
• TLS Mainフィールド：TLSバージョンなどの基本情報
• TLS Clientフィールド：拡張タイプなどクライアント側の情報
• TLS Certificateフィールド：サーバ証明書の情報

これらの情報を取得する際には、Probe（フロー生成機）とCollector（フロー分析機）でそれぞれ以下に示した項目にチェックが入っている必要があります。

Flowmon Probeの場合

図4：HTTP情報取得の設定（Probe）

Flowmon Collectorの場合

図5：HTTP情報取得の設定（Collector）

4. HTTP通信の可視化

「フローのリスト」解析を用いて、HTTP及びHTTPSのTLSバージョンごとに可視化できる項目を確認していきます。今回は、以下の項目を出力しました。

HTTPフィールド

• ホスト名
• HTTPメソッド
• URL
• HTTP結果コード

TLS Mainフィールド

• TLS Server version
• TLS server name (SNI)
• TLS Content type
• TLS Handshake type

TLS Clientフィールド

• TLS Client version
• TLS Extension types

TLS Certificateフィールド

• TLS Issuer common name
• TLS Subject common name
• TLS Subject organisation name
• TLS Signature algorithm
• TLS Public key algorithm

それでは実際に取得された情報を確認してみましょう。まずは平文のHTTP通信から、フロー情報を下図に示します。

図6：HTTPの可視化

Windows Update関連の「lu.dl.delivery.mp.microsoft.com」（末尾から32ビットまで表示）と、Chromeの管理コンソール「client2.google.com」が確認できました。ホスト名やメソッドのほかに、クライアントからのリクエストではURLが、サーバからのレスポンスではHTTP結果コードが記録されていました。また、HTTPではSSL/TLSは使用しませんので、TLS Main、TLS Client、TLS Certificateのフィールドは空欄（N/A）でした。

5. TLS1.2の可視化

続いて、TLS 1.2のHTTPS通信で取得できたフロー情報を下図に示します。

図7：TLS 1.2の可視化

マイクロソフトのEdge「edge.microsoft.com」やGraph「graph.microsoft.com」との通信が該当しました。HTTP通信とは異なり、URLや結果コードは確認できませんでしたが、TLS関連の項目はすべて確認できました。通常ホスト名はHTTPヘッダから取得される情報ですが、TLSで暗号化されている場合はTLSの拡張機能であるSNI（TLS Server Nameの項目）から取得できます。また、メソッドには「SSL」という値が出力されます。そのほかにも、TLSコンテンツタイプからはハンドシェイク（HS）やChange Cipher Spec（CCS）等をやり取りする通信がフローに含まれていることが分かります。ハンドシェイクタイプを見ると、Client Hello（CH）やServer Hello（SH）、Certificate（CER）等がハンドシェイク内でやり取りされています。クライアント側の情報（緑のフィールド）としては、エクステンション（拡張）タイプから、0：SNI、5：Status Request（サーバ証明書の失効情報取得に使用）等のTLS拡張機能が確認できます。証明書の情報（紫）としては、発行者のCN（コモンネーム）、対象ドメイン（ホスト）のCNやON（組織名）のほかにも、署名や公開鍵のアルゴリズム等が分かります。

6. TLS1.3の可視化

下図はTLS 1.3の通信から取得できたフロー情報です。

図8：TLS 1.3の可視化

「www.google.com」「www.yahoo.co.jp」「login.microsoft.com」との通信がTLS 1.3を利用していました。TLS 1.2と同様に、SNIからホスト名を取得することができています。また、TLS Main（オレンジのフィールド）やTLS Client（緑）は見ることができましたが、TLS Certificate（紫）は取得されませんでした。TLS 1.3ではServer Helloまでは平文で行われますが、Server Helloで鍵交換が完了した直後から暗号化通信が開始するため、そのあとにやり取りされる証明書などの情報は見ることができないのです。

7. 最新の暗号化通信

HTTP/3ではTLS 1.3を組み込んだQUICというプロトコルが使用されます。HTTP/2との大きな違いはトランスポート層がUDPになっていることで、接続確立の高速化など効率的な通信を実現しています。TLSがQUICに内包される形となるためFlowmonではTLSバージョンを確認することができませんが、下図のようにHTTPS通信（port 443）でUDPを使っていることからQUIC（HTTP/3）であると判断できます。

図9：QUIC（HTTP/3）の可視化

「www.bing.com」「play.google.com」との通信が該当しました。これらの通信では、SNI（ホスト名）のほかに可視化できた項目はありませんでした。QUICではClient Helloから一部暗号化された状態で接続を開始します（AEAD: AES-GCMという独自の方式で暗号化します）。これは事前共有鍵ではなく固定鍵を用いるため完全な機密性はなく、ハンドシェイクのみに利用されます。QUICのデフォルトではSNIは暗号化範囲外のため今回はホスト名を確認することができましたが、近年では通信のセキュリティ強化を目的としたESNI（Encrypted SNI、暗号化されたSNI）やECH（Encrypted Client Hello、暗号化されたClient Hello）が登場しています。現状ではESNIは実装上の課題からあまり普及はせず、後継となるECHもまだ実験段階のため広く使われているわけではありません。しかしセキュリティ強化のニーズは高まる一方なので、Client Helloから暗号化を行おうという動きは今後広まっていくでしょう。FlowmonではECH等にも対応した可視化ソリューションを開発しているとのことなので、プライバシーの確保とネットワーク可視化がどのように両立されるのか気になるところです。

8. まとめ

今回の検証結果として、TLSバージョンごとに可視化できた項目を以下の表にまとめます。

表1：検証結果

TLSを使わないHTTP通信では、ホスト名やメソッド、URL、結果コードといったHTTPヘッダ情報が可視化できました。TLSを用いるHTTPS通信（TLS 1.2、TLS 1.3、QUIC）ではHTTPヘッダ情報は取得できませんでしたが、SNIからホスト名を取得できました。また、TLS 1.2ではTLSの基本情報であるTLS Mainフィールド、クライアント情報のTLS Clientフィールド、証明書情報のTLS Certificateフィールドのすべてが可視化できました。TLS 1.3ではTLS Main、TLS Clientフィールドは可視化できましたが、証明書交換以降は暗号化されるためTLS Certificateフィールドは取得できませんでした。QUICはTLS 1.3が組み込まれた新しい暗号化通信規格ですが、鍵交換を行う前から暗号化されるためホスト名以外の可視化はできませんでした。

9. おわりに

本コラムでは、Flowmonの実機を用いてHTTPS通信がどのように可視化できるのかを検証いたしました。SSL/TLS及びHTTPのバージョンを追うごとに暗号化される範囲は広がっており、可視化できる項目も減ってきてはいますが、今後Flowmonでは暗号化通信の可視化にどのようなソリューションを提示していくのか注目していきたいです。

◆Flowmonについて、より詳しく知りたい方は、下記の資料をぜひご覧ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

Flowmon製品に関する
お問い合わせはこちらからどうぞ