SNIは今SEOを実施する上で不可欠な要素です。エンドユーザに一度でも不信感を抱かれたWebサイトでKPIを達成することは極めて難しく、一度信用を失ってしまえば、それを取り戻すことは極めて難しいです。これらを回避しビジネスを安定的に成功させる為には、既に頭角を現しているWeb関連の新プロトコルをいち早く認識し、ApacheやAndroid等で常時SSLサービスが提供出来るよう、今SNIを準備しておきましょう。

顧客にSEOを上手く実施させる為の常時SSL対応環境とは

Googleの「HTTPSをランキングシグナルに使用する」というアナウンスがSEOに与える影響

検索エンジンGoogleが2014年8月7日、「HTTPSをランキングシグナルに使用します」と発表以降、HTTPSで運営しているサイトが検索結果の面でも優遇されることになりました。この影響により、それまで「サイト全体のSSL化(常時SSL化）」に慎重だった人たちがSNIに再注目しました。

当時の考え方としては「新規システムの構築なら迷わずSSL化。しかし構築済み、商用化済みのページを全てSSL化することへの懸念は、googleアナウンスがSEOに与える影響をしのぐものにはならないだろう。」という見解でした。

しかしその考えは徐々に軌道修正を迫られています。アナウンス直後から「Google アナリティクスでdirectが増えること」への懸念も上がっており、今ではその予想が的中。SSL化したサイトが増えれば増えるほど自身のサイトもSSL化しておかなければ、サイト解析する上で面倒が出始めたのです。

CDNやPaaSの登場によって今後益々必要になるSNIおよびHTTP/2・SPDY・WebSocket等の新プロトコルの頭角

SNIの必要性はSEOの為だけに限ったことではありません。

実はSNIという拡張仕様自体は新しいものではなく、これは昔から実装されていた機能であり、近年その重要度により使用されるようになりました。その背景には、独自SSLに対応したCDNとPaaSの拡充が挙げられます。

Webサービスの運用環境として今や当たり前に利用されているクラウド。ここで使用されているプロダクトは全てSNIを利用して運用されています。つまりCDNやPaaSを利用したいならばSNIの導入環境が必要なのです。

近年フルスピードで進化を続けたHTTP/2,SPDY,WebSocket等のWeb関連新プロトコル、今後これらを使ってシステムを円滑に統合運用するならば、SSLが使用出来るSNIを導入しておくことが大きな鍵となってきます。

SNIを導入しサイト利用者へ違和感のない独自ドメイン証明書環境を提供する

SSLサーバ証明書のドメイン表示は重要！サイト利用者が危険なサイトへのアクセスをどうやって回避するか

今や国民の多くが利用するようになったインターネット。手軽に欲しい情報が得られるとあって、Webへのアクセスは大変便利ですが、セキュリティ面では懸念が残ります。インターネットに関する知識を持っている人であれば、「このサイトは大丈夫」「このサイトは怪しい」などの適切な判断が行えますが、インターネットへの理解が不足している方には適切な判断が行えないケースがあります。

SNIが導入されていないサイトのSSLサーバ証明書は共有ドメインSSLが利用されているケースがあります。共有ドメインSSLですと、非SSLのページからSSLのページへ遷移した際に異なるドメインのURLが表示されることになります。共有ドメインSSLに設定されているドメイン名が表示されてしまうのです。

URLを見てサイトの安全性を判断する場合、「サイト名とドメインが違う」「もしかしたら怪しい偽サイトなのかもしれない」などと間違った判断をされてしまうこともあります。更に、SNS等で拡散されてしまえば手の打ちどころがありません。

常時SSL化によって促進するSNI導入

前述しましたが、GoogleがHTTPSで運営しているサイトを検索結果で優遇すると発表したことにより、Webサイトの常時SSL化が進むきっかけとなりました。常時SSL化の障壁となっていた問題の一つ「IPv4の枯渇」はSNIを導入することにより、単一のIPアドレス上で複数のSSL証明書が利用可能な為、枯渇問題を解消しSSL化を進めることが可能です。更にSNI導入後は全ページがSSLとなる為、非SSLページとSSLページでドメインが異なるという問題も無くなります。些細な判断が長期的な運用の成功へと繋がります。

Apacheリロードの為のバッチ処理が必要になるSNI導入のデメリット

コスト面や既に構築運用されたシステムの設計を考えれば、SSL化した部分と、SSL化していない部分がオプションによって選択され、それぞれのSSL証明書が表示されるよう上手く共存出来ないかどうか方法を模索するはずです。

それには既に運用されているホストへSSL証明書の切り替えを実行させるプログラムの改修やApacheをリロードする為のshellスクリプトを作成し、バッチ処理等を実行することが現実的です。やや面倒な処理ではありますが技術的には可能です。

AndroidへのSNI導入状況

Androidの対応状況はどのようになっているかを確認しておきましょう。

標準WebブラウザのSNI対応状況

まずは標準ブラウザ、Android3.0（Honeycomb）以降であればSNIに対応しています。問題はAndroidユーザが標準ブラウザ以外にも様々なブラウザを使用していること。それらには別途対応が必要になります。

現状、Android2.3のSNI非対応ブラウザがSNI導入のHTTPSにアクセスすると、SSL証明書名不一致のエラーポップアップが表示されてしまいます。

正しいサイトを表示しているにも関わらず、セキュリティ警告が出てしまうのです。

ネイティブアプリのSNI対応状況

Androidのネイティブアプリでは、WebAPIを呼び出す時やImageViewの画像をWeb経由で取得する時など多くの場面でHTTPクライアントが使用されます。

SNIが非対応であっても大抵の場合は例外処理が選択され問題なく実行されていますが、問題はWebViewです。Android2.3でNG、Android4.0以上で問題なく表示されますが、SNI非対応のWebViewで非デフォルトVirtualHostにHTTPSアクセスすると、画面は真っ白になってしまいます。非常にシンプルなコンポーネントで設計されているWebViewのエラーハンドリングは自前で実装する必要がありそうです。

SNI対応ブラウザと非対応ソフト

対応ブラウザ一覧

• Internet Explorer 7 以降で対応。但しWindows Vista以降のみ、Windows XPではInternet Explorer 8でも非対応です。
• Google Chrome 、Windows Vista以降で対応可能。バージョン6ならWindows XPにも対応しています。
• Mozilla Firefox 2.0 以降全て対応しています。
• Opera 8.0 (2005年版) 以降は全て対応可能。但し設定でTLS 1.1を有効にする必要があります。
• Opera Mobile 10.1 β 以降 ならAndroidでも対応可能です。
• Safari 3.0 以降 で対応可能。Mac OS X 10.5.6 以降、Windows Vista以降、iOS 4.0以降で対応可能です。
• Android ブラウザ はAndroid 3.0 (Honeycomb) 以降で対応可能です。
• Windows Phone 7 は対応可能です。

非対応ブラウザ一覧

• Internet Explorer 6 もしくはWindows XP以前での全バージョンは非対応です。
• Safari はWindows XPより前のバージョンが非対応です。
• BlackBerry ブラウザ は7.1またはそれ以前が非対応です。
• Windows Mobile 6.5は非対応です。
• Android 2.x のブラウザが非対応、但しHoneycomb for tablets と Ice Cream Sandwich for phones では対応可能です。
• wget 1.14未満 が非対応ですが、但しパッチによって対応が可能です。

SNI対応が今後ホスティングサービスの救世主となる

SSL/TLSの拡張仕様としてSNIがRFC6066を定義した理由

SNIが導入される以前、サーバは自身に登録されたSSL証明書しか返すことが出来ませんでした。Webサーバとしては複数ドメインで運用しているのに、SSL/TLSとしては登録された１ドメインのSSL証明書しか利用出来なかったのです。

この不便に対し「技術上SSLセッションがハンドシェイクする際のHostヘッダを利用すれば、複数のドメインが利用可能なのでは？」と言う論議が始まりました。しかしこれはSSL/TLSの機能である「サーバ証明」に違反する行為、セキュアな通信を保証出来るものではありません。

そこでIETF（Internet Engineering Task Force）団体が立ち上がりRFC6066を定義。SSLハンドシェイクの過程で通信対象のサーバ名を通知するよう仕様が変更されたのです。RFC6066によりサーバは各アクセスにどのSSL証明書を発行すればよいか判断することが出来るようになりました。IETFをも動かしたSNI、それだけ重要性が高まっていると言う証拠です。

今後SNI対応環境が顧客確保の為の必須プロセスになる！今の内に導入を検討してみましょう

RFC6066に定義され注目されるSNI、その考え方はGoogleの目指すインターネットのあり方とsyncし、googleが進化させるアルゴリズムや新Web関連プロトコル、セキュアな通信技術に影響を与え続けています。今後はSEOやKPIにも大きな影響を与えて行くでしょう。中長期的に各インターネットサービスやWeb技術とスムーズに相互作用しサーバ運用を円滑に行いたいのであればSNIは必須、是非今のうちに導入を検討しておきましょう。