Encrypted SNI（Server Name Indication）とは？

まずSNI SSLとは、1つのIPアドレスに対して1つのドメイン名しか利用できなかったSSLサーバー証明書（以下、SSL証明書）を、通信先のドメイン名を定義することで1つのIPアドレスで複数のドメイン名にSSL証明書を利用できるようにした仕組みです。

例えば、さくらのレンタルサーバでは1つのIPアドレスを多くのユーザーで共有していますが、SNI SSLを利用することによってユーザー単位でSSL証明書を利用することができます。

• ※もちろん、各ユーザーが複数のSSL証明書を利用することも可能です。

現在SNI SSLは幅広く普及し、非対応ブラウザ（古いInternet Explorerやフィーチャーフォン）も少なくなり、対応機種やブラウザをほとんど気にせずに利用できるようになりました。

しかしながら、SNI SSLには「通信先のドメイン名が暗号化されない」という欠点があります。パケットを確認できるWiresharkというツールを使って通信を覗いてみると、以下のように平文でドメイン名が送信されているのがわかります。この平文で記載された情報は「ClientHello」と呼ばれおり、暗号化通信が成立する前にブラウザからサーバーへ送られる情報^※のため、データが暗号化されていません。

• ※サーバーとの通信条件を決めるために送信する情報です。

一方Encrypted SNI（ESNI）に対応したブラウザを利用して、それに対応したサーバーへアクセスすると、以下のように「ClientHello」に記載されたドメイン名が暗号化されていることがわかります。

このようにEncrypted SNIは通信先のドメインを秘匿してくれます。正確に言うとEncrypted SNIにはいくつか方式がありますが、今回はすでにCloudflareなどで実装されているTLS拡張方式についてご説明します。

• ※現在も開発が進められている規格のため、今後仕様が変更される場合があります。

Encrypted SNIによるドメイン名の秘匿を行うには、まずサーバー運営者側がDNSのTXTレコードへ公開鍵を設定しておく必要があります。元来のSSLやTLSではブラウザからサーバーへ向けて通信を開始する際、公開鍵をサーバーから入手する手段が無いため、ドメイン名が平文送信されていました。Encrypted SNIでは、この公開鍵をDNSに問い合わせて入手します。

ブラウザはEncrypted SNIに対応したサーバーへの通信時に、あらかじめDNSから公開鍵を入手し、アクセスしようとしているドメイン名をその公開鍵で暗号化します。暗号化されたドメイン名はそのサーバーの秘密鍵でしか復号できないため、ドメイン名の秘匿が可能になります。

Encrypted SNIの限界を知ろう

これまでもご紹介した通り、SSL証明書による暗号化は様々な側面に限界があり、何でも100％暗号化されて保護されるというわけではありません。Encrypted SNIについても、サーバーとのドメイン名のやり取りを秘匿することはできますが、DNSリクエストは別のサーバー（DNSサーバー）へ暗号化されない状態で行われるため、これを傍受されると通信先ドメイン名を間接的に推測することができてしまいます。

そのため、Encrypted SNIはDNSリクエストを暗号化するDNS over HTTPS（DoH）、またはDNS over TLS（DoT）と併用することが求められます。DNS over HTTPSについては、当コラムの『DNSとブラウザ間の通信を暗号化！DNS over HTTPS（DoH）とは？』で詳しく紹介しています。

また、DNS応答が偽装されていないことも求められるため、DNS応答に署名することで完全性を担保するDNSSECも必要になります。Encrypted SNIはDoHやDoT、DNSSECと組み合わせて初めて意味のあるものになることを覚えておきましょう。

しかし、例えこれらを導入したとしても通信先のIPアドレスは平文で送られます。IPアドレスと通信しているデータ量がわかると、場合によっては通信の用途が容易に推測できてしまうので注意が必要です。