httpsを検討しているユーザはSNIという用語はよく耳にすると思います。本ブログでは、https有効化のためのSSL/TLS証明書を適用する際に必ず知っておくべきのSNIの定義と、なぜ適用しなければならないのかについてお話したいと思います。
SNIとは?
SNIは Server Name Indication の意味でHTTPSで使用するName基盤のバーチャルホスト 機能と考えてください。(https://en.wikipedia.org/wiki/Server_Name_Indication)
HTTPでは、HTTP/1.1が導入されて以降、下記のように1つのIP(172.20.30.40)に複数のドメインのバーチャルホスティングが可能となり、多くのWebホスティング会社ではこの機能を利用して以前からWebホスティングサービスを提供しています。
NameVirtualHost 172.20.30.40 <VirtualHost 172.20.30.40> DocumentRoot /www/example1 ServerName www.example1.com </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot /www/example2 ServerName www.example2.com </VirtualHost>
HTTPSでも、SNIというTLSの拡張機能を利用して似たような方式でサービス適用が可能ですが、各ドメインごとにSSL/TLS証明書を設置する必要があるため、やや複雑な過程を経る必要があります。
つまり、HTTPは3 way ハンドシェイク後にホスト・ヘッダーを通じてクライアントがアクセスしようとするドメインをすぐに認識できますが、HTTPSの場合は3 way ハンドシェイク後にTLSハンドシェイクを行い、その後アクセスしようとするドメインに対してホスト・ヘッダーが伝達されるため、暗号化されたプロセスによりクライアントがアクセスしようとするドメインをすぐに認識できない問題があります。結局１つのIPで1つのSSL/TLS証明書のみサービスができる構造のままのため、多くのIPを消耗してしまう問題が発生します。
このような問題を解消するために、2003年rfc3546を通じて初めてSNI機能が提案され、現在はrfc6066にアップデートされています。これを通じてクライアントはTLS交渉のクライアント Hello 過程でアクセスしようとするドメイン情報をプレーンテキストで伝達することによって認識可能になり、SSL/TLSサービスにおいてもバーチャルホスティングが可能になりました。
次の画像はPCで https://www.cdnetworks.co.jp/ にアクセスする時のパケットのキャプチャですが、SNI関連情報をプレーンテキストで見られることを確認できます。
画像 : SNIパケットのキャプチャ
LinuxやMacOSがあればopensslコマンドでも簡単に確認することができます。 （バージョンによってオプションは異なる可能性があります）
ex) SNIに対応する場合 :: Extension : server_name が存在します
$ openssl s_クライアント -connect www.cdnetworks.co.jp:443 -servername www.cdnetworks.co.jp
ex)SNIに対応しない場合 :: client Helloに SNIフィールドがありません
$ openssl s_client -connect www.cdnetworks.co.jp:443
SNIを導入すると、どんな影響があるのか
CDNサービスやホスティングサービスでSNIの導入率が少々低いのは事実ですが、これはSNIを導入した時の副作用があるかもという漠然とした不安感のためと言われています。
果たしてそうなのでしょうか？早速、SNI導入時にどんな影響があるのかを見てみましょう。
まず、ウィキペディアのSNIについての説明(https://en.wikipedia.org/wiki/Server_Name_Indication)を見ると、ほとんどのブラウザはすでに10年前からSNIをサポートしています。
・MS Internet Explorer : 2006年Windows Vistaから
・Mozilla Firefox : 2006年2.0から
・Google Chrome : 2010年 6.0から
また、Webサーバの場合は次の通りです。
・Apache HTTP : 2009年2.2.12から
・nginx : 2007年0.5.23から
・MS IIS : 2012年8からv
最後にtext commandおよびLibraryの場合は次の通りです。
・wget : 2012年1.14から
・curl : 2008年7.18.1から
・Java : 2011年1.7から
・Python : 2014年2.7.9および2011年3.2から
・perl : 2012年1.56から
つまり、すでに提供が終了していたり、今ではほとんど使われていない一部の古いバージョンを除いて、標準としてSNIを提供しています。
それでは、SNIを提供していない統計を見てみましょう。
いくつかの公式な統計調査によると、99%に近いクライアントがすでにSNIを安定的に提供していることがわかりました。特に下記のサイトではリアルタイムでSNIサポートの比率を統計にて表示していますが、結果の値は他の調査でも同様です。
SNIサポート統計、参照元: https://caniuse.com/#feat=sni
次のクライアントのみSNIをサポートしていません。
・Windows XPのMSIE6(2001年8月リリース)
・Windows XPのMSIE7(2006年10月リリース) ※Windows Vistaはサポート中
・Windows XPのMSIE8(2009年3月リリース) ※Windows Vistaはサポー中
・IOS 3.2 Chrome,Safari(2010年4月リリース)
・Android 2.1/2.2/2.3 ブラウザ(2010年12月リリース)
・BlackBerry ブラウザ(2012年1月リリース)
SNI はなぜ導入しなければならないのか、導入のメリットは?
ここでは、SNIはなぜ導入する必要があるかについて説明します。
・ ipv4 枯渇問題を解決できる
ご存知のようにIPv4のIPはすでに数年前に枯渇し、これ以上のIP割当はできない状態になっています。さらに、ログインの必要がないWebサイトですらHTTPS適用が基本とされ、SNIを導入しない場合はIPv4を割り当てられない問題が発生するでしょう。もちろん今後IPv6に変更されてゆきますが、その遷移スピードは非常に緩やかで、しばらくの間はIPv4環境のクライアントが多い状態は変わらず、その対応には限界があります。
・ 悪性ボットのアクセスを遮断できる
SNIをサポートしないクライアントからのアクセスをCDNetworksで分析した結果、そのほとんどがサービスとは関係のない悪性ボットと判明しました。ここで悪性ボット検知の例をいくつかご紹介します。
例① Windows 8/10なのにSNIに対応していない場合
例② Mozilla/5.0
+Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0)Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/48.0.2564.116+Safari/537.36
UA情報を見ると、64ビット Windows8のMSIE10.0およびWindows10という意味ですが、Windowsは Vista以降はSNIに対応しているため、これは異常リクエストです。(ブラウザでSNIをoffにする機能はありません)
例③ Windows XPで対応できないcipherでアクセスする場合
Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0) TLS_RSA_WITH_AES_128_CBC_SHA
すでにサポートが終了したWindows XPは最新のサービスパックをインストールしてもSNIに対応しません。アクセス時にログにあるcipher情報を見ると上記のようにXPは対応しないcipherでアクセスしたことが確認できます。つまりこれはXPに偽造されたボットであるということが分かります。
例④ iPhoneなどiOSなのにSNIではない場合
Mozilla/5.0+(iPhone;+CPU+iPhone+OS+10_2_1+like+Mac+OS+X)+AppleWebKit/602.4.6+(KHTML,+like+Gecko)
iOSはとても古いバージョンの5.xでも対応するほどSNIに対応していますが、最新バージョンの10.2にも関わらずSNIに対応していないとモニタリングされました。つまりこれはボットであることが分かります。
例⑤ ユーザエージェントおよびプロトコル情報がない場合
すべてのアプリケーションはユーザエージェントおよび0なのか1.2なのかなどのSSL/TLSプロトコル情報を伝達しますが、このような情報がなくアクセスしてくるケースがモニタリングされました。これは標準に従わないボットであることが推測できます。
例⑥ Windows XP Firefoxなのに動的コンテンツのみダウンロードする場合
Mozilla/5.0+(Windows+NT+5.1;+rv:15.0)+Gecko/20100101+Firefox/15.0.1
上記のようにWindows XP環境のFirefoxブラウザを使用するアクセスがモニタリングされました。一般的に正常ブラウザならindexファイルにアクセス後、下記のようにcss、jsまたは画像ファイルを順番にリクエストし、情報をユーザに表示します。
しかしログを分析した結果、下記のように‘indexファイルおよび特定ファイルのみリクエストする’にhitがあり、静的コンテンツに対するリクエストは全く確認できませんでした。これは該当のクライアントが一般的なブラウザではなくコンテンツに対する理解機能がないということが分かります。つまりこれは悪性ボットであることが推測できます。
GET /news/ GET /login.php GET /gallery/ GET /
このようにSNIを有効にするだけで、それなりの数の悪性ボットを遮断できる効果があります。悪性ボットにより不要なトラフィックが発生したり、ハッキングなどのサイバー攻撃を受ける可能性もあるため、セキュリティ担当者はなるべく早い段階で、ボット遮断の対策を導入することをお勧めします。
Webサイトのセキュリティ強化のためには古い環境からのアクセスは遮断する
分析の結果、ほとんどのアクセスは一般的なユーザではなくボットと確認されましたが、一部Windows XPを使用するユーザが含まれているかもしれません。Windows XPは数年前にサポートが終了しており、脆弱性が見つかってもセキュリティパッチが提供されないため、悪性コードに感染することによりPCが攻撃者から遠隔操縦されたり、攻撃ルートとして悪用される可能性が非常に高いと言えます。つまり、こういったユーザがアクセスすること自体がセキュリティ対策上で危険な状態と言えるため、このようなアクセスは遮断することをお推めします。
おわりに
CDNetworksでは、世界的に大きなWebセキュリティ上の課題であるIPv4枯渇問題を解決し、より多くのお客さまに安定的なHTTPSサービスを提供すべく”SNI Only”サービスを推し進めています。一部モニタリングツールやモバイルアプリケーションでまだSNIに対応しない旧バージョンを利用されているお客様は、是非この機会にSNIに対応できる環境にアップデートすることをお勧めします。
SNIのためのアップグレードは、セキュリティ全体の強化を図るという大きなメリットも得ることができる、ということを記憶に留めておいていただけたらと思います。
お困りごとがあればいつでもCDNetworksにご相談ください。
CDNetworksでは、弊社で提供中のSSLサービスについて詳しくまとめたホワイトペーパーを提供中です。是非ご覧ください。
なお、弊社では、Web会議（30分ほど）でのサービス紹介も承っております。
ご興味、ご関心のあるお客様は、お気軽にお問い合わせフォームよりお申し付けください。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■お問い合わせはこちら >>お問い合わせフォーム
■関連資料のダウンロードはこちら >> 資料ダウンロード
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
株式会社シーディーネットワークス・ジャパン TEL：03-5909-3373（営業部）
