このページの本文へ

GoogleもFacebookもTwitterも!いまやAlways-On SSL

ベリサイン、増える常時SSLサイトの動向について解説

2012年03月29日 06時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

3月28日、日本ベリサインは「『常時SSL』が進む米国のネットサービス」をテーマとした勉強会を開催した。メジャーなネットサービスがユーザーセッションを開始から終了まで暗号化する常時SSL(Always-On SSL)に移っている昨今について米シマンテックのWebサイトセキュリティの担当者が説明を行なった。

サイトまるごとSSL化が進む背景

 Always-On SSLはSSL/TLSをWebサイトすべてに適用し、サイトの閲覧やログイン/ログアウトまで一貫してセキュリティを確保する手法。サイト上のすべてのユーザーセッションを暗号化することで、ログインや取引情報のみの部分的なSSL導入では防げない最新の攻撃に対応するものだ。こうしたAlways-On SSLの試みは、GoogleやFacebook、Twitterなどの大手のネットサービスでいち早く導入されているという。

SSL/TLSをWebサイトすべてに適用するAlways-On SSL

 勉強会において米シマンテック トラストサービシズ プロダクトマーケティング ロブ・グリッドマン氏は、こうしたAlways-On SSLの導入が進む背景として、デジタルネイティブな利用者がSNSなどに安易に情報を共有するようになったこと、特定ユーザーをターゲットにしたサイバー犯罪が巧妙化してきたこと、クラウドの普及でデータが多くの場所が分散していること、ユーザーや情報保護などを実現するためのコンプライアンスの必要になっていることなどを挙げた。

米シマンテック トラストサービシズ プロダクトマーケティング ロブ・グリッドマン氏

 特に、Webサイトを使ったユーザーへの攻撃は非常に巧妙化しているという。グリッドマン氏は、ユーザーのWebブラウザの脆弱性を突くドライブバイダウンロードのほか、ソーシャルエンジニアリングによるユーザーマシンの奪取、暗号化されていないCokkieを盗み出すことでユーザーになりすます攻撃が増えていると説明した。さらに同氏は、Firefoxのアドインとしてサイドジャッキングを行なう「FireSheep」や「SSL Strip」などの例を挙げ、ユーザーセッションを勝手に読み出すサイトジャッキングやマンインザミドルは部分的なSSL化で防げない点を指摘した。

ドライブバイダウンロードやソーシャルエンジニアリング

セッションCokkieの乗っ取りによるサイドジャッキング

 これに対して、大手サイトが導入しているのがAlways-On SSLだ。SNSやWebメール系ではすでに当たり前になっており、「Twitterでは全体の22%のユーザーがメニューからSSLをオンにしている。Facebookでは、サードパーティも含め、すべてを網羅する形でSSLを利用できるようにしている」(グリッドマン氏)という。

著名なサイトはAlways-On SSLを実施している

 また、今年2月のRSA ConferenceではOTA(Online Trust Alliance)という団体の主催で、マイクロソフト、グーグル、シマンテック、フェイスブック、ペイパルなどがパネルディスカッションを行ない、その有効性や推奨構成などを論議したという。グリッドマン氏は、シマンテックとしては、EV SSL証明書の移行やマルウェアスキャン、脆弱性アセスメントなどのベリサイン証明書の付加機能の利用とともに、Always-On SSLを推奨すると説明した。

Always-On SSLは遅くなる?コストは上がる?

 続いてAlways-On SSLの詳細について説明した、日本ベリサイン SSLプロダクトマーケティング部 上席部長 安達徹也氏は、日本特有の動向として無線LANのリスクを挙げた。現在、公衆無線LANの利用は多くのキャリアが注力している分野で、米国を猛追しているが、前述したようなサイドジャッキングのような攻撃の危険性を多分にはらんでいるという。

日本ベリサイン SSLプロダクトマーケティング部 上席部長 安達徹也氏

 もちろん、こうしたリスクを軽減するため、今まではエンドユーザーがVPNを導入したり、SSLで接続しやすくするためのブラウザアドオンなどを使ってきたが、対処範囲が限定的。また、HTTPとHTTPSが混在させたサイトで、Cokkieの有効範囲の設定を間違っていると、HTTP上のCokkieが窃取され、なりすましされてしまう可能性が高い。「HTTPとHTTPSのサイトの移動で、Cokkieを引き継ぐところが弱点になる」(安達氏)。こうした課題を考えると、やはりサイトの運営者側で全面的なSSL化を進めた方がよいというのが安達氏の論だ。

 さらに安達氏は、通信速度やコスト、警告表示、ログ解析などAlways-On SSLでの懸念点について説明を加えた。まず遅くなるというイメージのあるSSLの通信速度に関しては、ネゴシエーションの回数を減らすKeep-Aliveを有効にすれば、昨今のCPUパワーの向上で十分対応可能になるとのこと。10年前に比べて計算能力があまり必要ないため、コストにも跳ね返らないという。

グーグルのコメントを引用し、Always-On SSLでもコストは上がらないと説明

 また、HTTPSにおいて、HTTPサイトと混在しているというエラーが出る懸念もあるが、これはパスの記載を工夫することで、回避できるほか、埋め込みタブもSSL用のものを利用するとよいと説明した。ログ解析に関しては、すべてSSL化することでHTTP用とHTTPS用が統合されるため、解析がしやすくなるほか、リファラーの情報も増加するという。これは主要なWebブラウザでは、HTTPSからHTTPに遷移する際にリファラー情報を引き渡さないためだ。

HTTPサイトとHTTPSサイトの混在させると生じるダイアログ表示

常時SSLとログ解析の関係

 安達氏は、その他GoogleでのSSL検索やSEOへの影響などを説明した。これらAlways-On SSLの導入ノウハウは、ホワイトペーパーとして公開されている。

■関連サイト

カテゴリートップへ

ピックアップ