次世代暗号アルゴリズム「ECC」と「常時SSL」で変わるウェブセキュリティ最新トレンド/日本ベリサイン
サイトのセキュリティリスクを低減させるためにも常時SSLを採用する企業サイトが増えてきている。しかし、常時SSLにはパフォーマンスやSEOに対しての不安を感じているWeb担当者がいるのも事実だ。日本ベリサインの山崎潤一氏は、常時SSLの必要性を示しながらこれらの疑問に答え、最新の暗号化アルゴリズムであるECCの紹介も行った。
Wi-Fiやスマートフォン活用で必要性が高まる常時SSL
セミナー冒頭、このように挨拶する山崎氏は、まず「常時SSL(https)」のトレンドについて解説する。常時SSLとは、簡単に言えばWebサイト上の全ページをhttps化することだ。なぜこうした対策が進んでいるのか、その背景の1つとして、山崎氏は無線LANに潜むリスクについての解説を始めた。
無線LANにはマンインザミドル(中間者攻撃)と呼ばれるリスクがあり、特にフリーのホットスポットやなりすましのアクセスポイントで情報を盗まれる危険が高く、暗号化されていないCookie内のセッションIDが盗まれてしまう可能性がある。以前は高度な技術がなければマンインザミドルは行えなかったが、簡単になりすましを行えるツールが登場したことも問題だ。
Cookieが盗まれてしまうと、FacebookやTwitter、自社サイトになりすましてログインされてしまい、IDやパスワードが改ざんされたり、ユーザー情報が漏えいしたりする危険がある。「Webサイトそのものに脆弱性がある場合は、Webサイトの情報をすべて盗み取るなどの大きな犯罪に発展することもある
」と山崎氏は警告する。
これを避けるためには、Cookie情報をSSLで暗号化することが求められるが、より確実に安全性を高めるのが常時SSLという考え方だ。たとえば、検索サイトからECサイトに来訪して、支払いサイトで決済するまでのすべてをSSL暗号化することで、ユーザーのCookie情報をすべて保護できる。これまでは、決済画面や個人情報を入力するページのみをSSL化して暗号化するケースが多かったが、TwitterやFacebook、Google、2014年に入り米Yahoo!やbingが採用するなど、常時SSLを採用するサイトが増えてきている、と山崎氏は説明する。
常時SSLを導入することでパフォーマンスに影響が出ることを懸念する声もあるが、現在のPCスペックを考えれば、ほとんど影響しないという。実際、Googleは常時SSL化の影響について、Gmailの常時SSL化による影響はCPU負荷の1%以下、セッションあたり10KB以下のメモリ、ネットワーク負荷の2%以下だったと、無視してもよい程度の負荷しかかからなかったと発表している。
常時SSLの事例として山崎氏は、ネット選挙が実行される前に、政党のホームページが信頼性を高めるために常時SSLを採用したケースを紹介する。たとえば、自民党や公明党は常時SSLとEV SSL証明書を組み合わせて利用している。厳しい審査を通じて発行されるEV SSL証明書を採用し、信頼性を向上させているのだ。
常時SSL化で注意すべき4つのポイント
既存のサイトを常時SSLにするには、いくつかの方法があると説明する山崎氏は、次の4つの方法を示す。
- HTTPS(SSL)のみ
安全性が高い反面、HTTPによるアクセスを取りこぼしてしまう可能性がある - HTTPのアクセスをHTTPSに転送する(実質SSLのみ)
同じURLのHTTPSページに301転送(完全に移動)を設定する
HTTP/HTTPSのいずれでアクセスしても必ずSSL暗号化される - ハイブリッド(HTTP/HTTPSの両方を運用)して、HTTPSのリンクを設置する
HTTPSへの切り替えボタンを用意する - ハイブリッドのみ
HTTPSを知っている場合やリンクで誘導されたユーザーだけがSSL化される
このなかで一般的なのは2番目の「HTTPのアクセスをHTTPSに転送する」方法で、ベリサインでも利用している方法だと山崎氏は勧める。この方法では、HTTPページのアクセスが自動的にHTTPSページへ転送されるため、SEOの効果を引き継ぐことができるが、ハイブリッドの場合は被リンクの効果がHTTPとHTTPSのページに分散されるため、検索順位を落とす可能性もあるという。
2011年5月にはGoogleのマットカッツ氏が301転送を行えばHTTPSに切り替えてもランクに影響を与えないと動画でコメントしている。ただし、2011年5月の時点ではまだ例が少ないため、いったんアクセスの少ないサイトや一部のサブディレクトリで試して、順位を確かめてみることが推奨されている。
また、常時SSL化するとリファラ(リンク元)情報を取得できるという効果もある。主要なブラウザはHTTPSからHTTPへ遷移するとリファラ情報を引き渡さないが、HTTPからHTTPS、HTTPSからHTTPSの場合は、リファラ情報を引き渡すようになっている。つまり、自社のページにHTTPがあった場合はリファラ情報を取得できない可能性があり、常時SSL化しておけば確実にリファラ情報を取得できるということになるのだ。
リンク元ページ | リンク先ページ | Internet Explorer 8 | Firefox 3.6 |
---|---|---|---|
HTTP | HTTP | ○(引き渡す) | ○(引き渡す) |
HTTPS | HTTP | ×(引き渡さない) | ×(引き渡さない) |
HTTP | HTTPS | ○(引き渡す) | ○(引き渡す) |
HTTPS | HTTPS | ○(引き渡す) | ○(引き渡す) |
続いて、山崎氏はサーバーがクライアントにCookieを送るときのレスポンスヘッダでSECURE属性を指定することで、Cookie情報を保護できることを説明する。これによって、セキュアなHTTPS接続時のみCookie情報を利用し、非セキュアなHTTP通信の場合はCookie情報を利用しないようにできるため、Cookieが盗聴される危険性を極小化できるという。
- Set-Cookieヘッダのフォーマット 例
Set-Cookie: NAME=VALUE; expires=DATE; secure
- Set-Cookieヘッダ 例
Set-Cookie: num=0001; expires=Sun, 1-Jan-2012 12:00:00 GMT; secure
常時SSLの説明の最後として、再度レスポンスの課題を説明する山崎氏は、CPU処理能力が飛躍的に向上しているのでレスポンスに問題はなく、さらに「Connection: keep-alive」のようにKeep Aliveを有効な設定とすることで、SSLネゴシエーションの発生回数を減らすこともできるとし、常時SSL化のメリットとデメリットを次のようにまとめた。
常時SSL化 | http/httpsのハイブリッド | |
---|---|---|
メリット |
|
|
デメリット |
|
|
実装サイト例 |
RSAよりも負荷を低減する暗号アルゴリズムECC
続いて解説は、新しい暗号アルゴリズムである「ECC(楕円曲線暗号)」の話題に移る。ECCは、広く普及する暗号化技術のRSAのように素因数分解で鍵長を長くしてセキュリティを高めるのではなく、より複雑な演算によって現状では鍵長が短くても解読しづらい使用となっているのが特徴だ。そのためECCは、セキュリティの観点から鍵長が長くなり続けているRSAよりも負荷をかけずに活用でき、常時SSL化されたサイトや、スマートフォンなどのPCよりも非力なデバイスからのアクセスにも適した暗号化を提供できる。
ECC暗号は、世界に先駆けて日本の上場企業情報サイト「Kmonos」やブログ「小悪魔女子大生のサーバエンジニア日記」で利用されている。
どちらも常時SSL化を行った後、不定期に訪れるピーク時のパフォーマンスが落ちることを避けるためにECC導入を決めているが、WebサーバーにApacheを利用しているKmonosではピーク時のCPU使用率を76.4%から41.53%に、Nginxを使っている小悪魔女子大生のサーバエンジニア日記では41.95%から30.5%に下げることができたという。
CPUの負荷を低減させる効果があり、サーバーリソースの寿命を延ばすことでもECCが注目されていると山崎氏は話す。ただし、ブラウザやOSのバージョンによって非対応の場合もあるため、ECCとRSAのハイブリッド構成にするなど、注意点もあるという。
- 最新版のアプリケーションをインストールする必要がある
- ApacheはRSAとECCのハイブリッド構成に対応しているが、どちらを選択するかはブラウザによって異なってしまう
- NginxはRSAとECCのハイブリッド構成に対応していない
現時点では普及段階にあるECCだが、最後に山崎氏は、今後さらに導入環境を整えていくことを話した。
現時点ではまだ普及していないが、トランザクションが頻発するような環境では将来的にECCの利用をご検討いただきたい。テスト用の証明書も公開しているので、興味のある人はベリサインのホームページでECCと検索して実機の検証やパフォーマンステストを試してみてほしい(山崎氏)
日本ベリサイン株式会社
https://www.verisign.co.jp/
ソーシャルもやってます!