目次 非表示
はじめに
前回のDPIの仕組み ～基礎編～では、HTTP通信に含まれるホスト名を用いてアプリケーションの識別が可能となっていることを紹介しました。
しかし昨今ではHTTPS導入の本来の目的である、暗号化や成りすまし、改ざん検知のみならず、SEO(Search Engine Optimization)目的でもWebサイトのHTTPS化が進んでおり、Google社の透明性レポートによると90%以上のトラフィックがHTTPSを介した読み込みとなっているようです。
ではHTTPSにより暗号化されたトラフィックは、DPIにおいてどのようにアプリケーション識別を行うのでしょうか？
HTTPS通信の仕組み
HTTPSはHTTPをセキュアに転送するため、TLS(Transport Layer Security)というプロトコルを利用しHTTPを暗号化してネットワーク上を転送します。よって、原理的にはTLSによる暗号化を解けば平文のHTTPを参照でき、基礎編で述べたような方法でアプリケーションの識別を行うことは可能に見えます。
しかし、TLSはSSL(Secure Sockets Layer)を拡張して定義され、より安全性の強化されたプロトコルであり、そう簡単に暗号化を解いて平文のHTTPを参照することはできません。
(SSL/TLSの暗号化はHTTPを暗号化する共通鍵を公開鍵暗号方式で暗号化し、ネットワーク上を転送するため共通鍵を平文で得ることは困難)
HTTPが暗号化されているのであれば。。。
アプリケーション識別の話へ無理やり戻します。
上述した「SSL/TLSによる暗号化の概略図」において、項番7および10でネットワーク上に放たれるデータは暗号化されているということはご理解いただけたと思います。
しかし、TLSプロトコルの手続き上、暗号化が開始されるまでの序盤(項番1～2)までは平文でやり取りされるデータがいくつかあります。
最もよく使われるのは、SNI(Server Name Indication)です。SNIはHTTPにおけるHostヘッダとほぼ同じ役割を担っており、1つのサーバで複数のホスト名を持っている場合にサーバがクライアントへ返すサーバ証明書を選択する目的で利用されるため、ホスト名(FQDN)が設定されます。
もう一つは、このサーバ証明書に含まれるCN(Common Name)属性にも同様にホスト名が設定されます(ただし、複数のホストでサーバ証明書を共用するワイルドカード証明書の場合はFQDNは得られません)。
このように、DPIは様々な手段でホスト名を得ることでアプリケーションの識別精度を上げることが可能です。
