1. サーバを増やさずSSL/TLSを拡張!SNIと常時SSLとの密接な関係

サーバを増やさずSSL/TLSを拡張!SNIと常時SSLとの密接な関係

  • このエントリーをはてなブックマークに追加

重要性を増し続ける「サイトの安全性」。今では、1社で複数のウェブサイトを運営している企業も少なくありません。ここでは複数のウェブサイトに従来型のSSL証明書を利用する場合の問題点と、それらに対するSNIの有効性について解説します。SNIは、近年ますます広がっている常時SSLの流れとも密接に関係しています。

SSL証明書における問題点

従来型SSL証明書をウェブサイトに入れるためには大きく2つの方法がありますが、複数のサイトに利用するには問題点もあります。

一般的なSSL証明書では、複数のドメインを運用できない

SSL証明書は仕組み上、1つのIPアドレスに対して1枚しか設定できません。そのため、もし異なるドメインの複数サイト全てに対してSSL証明書を設定したければ、サイトの数と同じだけのIPアドレスを用意したうえで、SSL証明書を取得しなければなりません。これでは導入コストがかかりすぎてしまいます。

共有SSL証明書は信頼性に欠ける

共有SSL証明書は、レンタルサーバ会社などが自らSSL証明書を取得し、そのドメインを複数のユーザで共有するSSL証明書です。SSL証明書の取得や管理はレンタルサーバ会社になるため手間も少なく低コストで導入できますが、ドメインを他ユーザと共有するので独自ドメインが使えず、そのレンタルサーバ会社のドメインに切り替わります。そのため、サイト利用者にとって利用していたサイトとは違うサイトのSSL証明書が表示されることになります。気に留めないサイト利用者もいますが、これによって「信頼性に欠ける」と不安感を抱き、ページから離脱してしまう可能性も考えられます。

共有SSL証明書は信頼性に欠ける

SNIと従来型SSL証明書との違い

SNIとは何か?

従来型のSSL証明書の問題点を解決するべく登場したのがSNI(Server Name Indication=サーバ名表示)という技術です。この技術が確立される前は、サーバはPCからのSSLによる認証・暗号化処理(SSLハンドシェイク)に対して、設定されたSSL証明書を提示することしかできませんでした。

SNIを利用することで、SSLハンドシェイクの過程でPCからサーバに対してサーバ名が表示されるようになり、サーバ側はどのアクセスに対して、どのSSL証明書を提示すればいいかの判断が可能になりました。その結果、複数のドメインに別々のSSL証明書を設定しても、サーバが対応できるようになったというわけです。

SNI(Server Name Indication=サーバ名表示)

SNIのデメリット「非対応端末の存在」

ところがSNIにも「非対応端末の存在」というデメリットがありました。SNIが利用され始めたのは2003年からですが、当時はこの新しい技術に対応できない端末が少なからずあったのです。代表的なものにはWindows XP、フィーチャーフォン、Android 2.xなどが挙げられ、これらの非対応端末からアクセスしてくるユーザをシステム上、無視することになりました。しかし現在では、非対応端末を利用するユーザは少なくなっており、SNIのデメリットは、ほとんど解決されていると言えます。

常時SSLの流れとSNI、その関係性と課題

HTTP“S”が当たり前の時代がやってくる!

SNIの登場により、複数ドメインがある場合でも低コストで効率良くサイトのSSL化を実現できます。これと並行して、ウェブサイトの安全性についての認識を大きく変える以下の3つの出来事が起こりました。

  • 1. 2014年にGoogle社が公式ブログにて「HTTPSをランキングシグナルに使用します」と発表
  • 2. 2015年にGoogle社が「同一コンテンツのページならHTTPSのページを優先的にインデックスする」と発表
  • 3. 2015年に非営利団体が無料SSL証明書配布プロジェクト「Let’s Encrypt」のサービス開始

HTTPS(Hyper Text Transfer Protocol Secure)は、SSLによる安全な通信を行うことを意味します。「1」と「2」はGoogle社がSSLを推奨するという立場の表明になります。安全な通信でなければ検索順位において不利になり、サイト全体をHTTPSのページ(常時SSL化)するのが当たり前という時代が迫っています。

Let's Encryptで常時SSLの低コスト化が進む

しかもこの常時SSL化の流れは、「Let's Encrypt」のサービスによってさらに促進されています。Let's Encryptは無料SSL証明書の先駆けで、1990年設立の電子フロンティア財団が発表したSSL採用促進計画です。MozillaやCisco Systems、ミシガン大学、Akamai Technologiesなどがプロジェクトに参加しており、より簡単に無償でSSL証明書を設定できるサービスを提供しています。認証局が提供するような審査レベルではありませんが、無償でSSL証明書が入手できます。

常時SSLに残される課題

常時SSLの普及にも問題があり、「HTTPS=安全」とは言えなくなるかもしれません。これまではある程度のコストをかけなければ「安全なサイト」を騙ることはできませんでしたが、Let’s Encryptなどの無償SSL証明書の台頭により、コストをかけなくても「安全なサイト」を作れるようになりました。審査レベルも厳密ではないため、詐欺サイトであってもHTTPSのページが作れるという事態が発生する危険があるのです。

それに伴い、「HTTPSの高コスト化」が考えられます。「HTTPS=安全」という単純な公式が通用しなくなると、より審査レベルの高いSSL証明書(企業認証SSLやEV SSL)を利用しなければ安全性を担保できなくなります。したがって、いずれは常時SSLを実現するには現状よりもある程度の予算が必要になると考えられます。

「ウェブサイトの安全性」の問題は続いていく

ネットワークセキュリティの問題はめまぐるしく変動しています。それは標準的なSSL証明書からSNIまでの変化を見るだけでも一目瞭然です。確かにSNIや無償SSL証明書の普及により、常時SSLの実現性は高まっています。しかし、だからといって「もう安心」というわけではありません。最後に解説したように、絶えず新たな問題が浮上しているからです。したがって担当者や関係各社は、今後もサイトの安全性確保のために最適な運用を追求し続ける必要があるでしょう。

  • このエントリーをはてなブックマークに追加

この記事を書きました

グローバルサインブログ編集部

グローバルサインブログ編集部
所属:GMOグローバルサイン マーケティング部
当ブログの運営・管理を担当。マーケティング部=なんでも屋。
>>グローバルサインブログ編集部の記事一覧