WebサーバによるSSL処理の不経済性

よく知られているように、WebブラウザとWebサーバ間で通信を暗号化し、盗聴や改ざんを防止するのがSSLです。SSLを使用するには当然ながら暗号処理が必要になりますが、CPUに大きな負荷がかかります。HTTPSでWebページにアクセスした場合、画像も含めてすべてのコンテンツが暗号化されてから転送されるため、トラフィックが増えれば増えるほど、Webサーバに与える負荷も増大します。

　最近ではサイト全体の安全性を確保するため、すべてのページをSSL化する「常時SSL」に踏み切るサイトも増えています。Googleが2014年8月に「SSL化されたWebサイトをSEOの評価として優遇する」と公式に発表したことも、常時SSL化への動きを後押ししているといえます。常時SSL化が進めば、SSLの処理負荷の問題はさらに大きくなるでしょう。

WebサーバにおけるSSLの暗号処理負荷は、暗号鍵の長さが短かった頃は、まだ我慢できる範囲の処理負荷だったといえます。しかし2004年8月、NIST（National Institute of Standards and Technology：アメリカ国立標準技術研究所）があるガイドラインを示したことで、状況は大きく変化しました。それまでSSLに使用されていた暗号鍵は1024ビットでしたが、1024ビットのままでは安全性を確保することが難しく、使用期限を2010年にすべきだとNISTから勧告されたのです。これは「暗号アルゴリズムの2010年問題」と呼ばれています。

暗号鍵の2048ビット化で顕在化したSSLのパフォーマンス問題

NISTによる勧告を受け、現在ではすでに2048ビットの暗号鍵によるSSLが一般的になっています。それでは暗号鍵長が1024ビットから2048ビットになることで、処理負荷はどれだけ大きくなるのでしょうか。ビット数が2倍だから、負荷も2倍になる？実はそうではありません。

 

 

 

上の表は、2010年問題が改めてクローズアップされた2011年1月に作成されたものです。一般的な64ビット サーバでSSLを処理した場合、暗号鍵長が1024ビットのケースでは1570 TPS、2048ビットのケースでは273 TPSであることが示されています。つまり暗号鍵長が2倍になることで、処理負荷は約6倍になっているのです。

　この表が作成された時期から約5年が経過した現在では、もちろんCPUの処理能力も向上しています。9月2日に独ベルリンで開催された世界最大のコンシューマー エレクトロニクス ショー「IFA 2015」でインテルが行った発表では、ベンチマーク スコアはこの5年間で2.5倍になったと言及されています。しかしこの数字を見る限り、暗号鍵の2048ビット化に伴う処理負担増加は、この5年間で実現したCPU性能向上ではカバーできていないことになります。

SSLの暗号処理を各Webサーバで処理すれば、当然ながら本来のWeb処理に費やすべきリソースがSSL処理に割り当てられ、パフォーマンスが低下します。処理速度の低下を補うには、より高速なサーバを使用するか、サーバ台数を増やして負荷を分散するしかありません。WebサーバでSSLを処理することは、実に不経済な選択なのです。

WebサーバでのSSL処理は運用面でも不経済

WebサーバによるSSL処理の不経済性は、パフォーマンスの低下だけではありません。SSL処理を行うにはSSL証明書を実装しなければなりません。SSL証明書の有効期限を適切に管理した上で、必要に応じて更新するといった作業も必要になるのです。これをすべてのWebサーバで行うのは、大きな運用負担を伴います。Webサイトの規模が増大するほど、この負担も増大することになります。またシステムに実装する暗号鍵の数が増えれば、管理上のセキュリティ確保にも大きな負担がかかります。

1台のサーバで複数のドメインを運用する「バーチャルホスト」では、原則としてSSLが使えないことにも注意が必要です。SSLではHTTPヘッダが暗号化されているため、クライアントがどのホスト名をしているのかを判断できないからです。ただしこの問題には解決策があります。SSL/TLSの拡張仕様の一つであるSNI（Server Name Indication）を使用することで、バーチャルサーバでもSSLが使えるようになります。ここで注意したいのは、SNIを使用する場合にはWebサーバ側だけではなく、Webブラウザ側での対応も必要だということです。SNIは比較的新しい拡張仕様なので、対応していないWebブラウザも少なくないため、使用できるWebブラウザが制限されてしまいます。

セキュリティが逆に低下する危険性も

WebサーバでSSL処理することで、他のセキュリティ機能が使えなくなる危険性もあります。

　例えばWebサーバとインターネットとの間に、IDSやIPSといった「ディープ パケット インスペクション」を行うセキュリティ アプライアンスを設置するケースを考えてみましょう。SSLのトラフィックは暗号化されているため、これらのアプライアンスではパケットの中をチェックできず、本来の機能を果たすことが不可能になります。同様の理由から、ゲートウェイ型のアンチ ウィルス製品でもマルウェアの検出が不可能になります。

　解決策として考えられるのは、すべてのWebサーバの暗号鍵をアプライアンスに展開し、トラフィックの解読と再暗号化をアプライアンスで行う方法が挙げられますが、当然ながらこれによってパフォーマンスは大幅に悪化します。

問題に対する根本的な解決策とは

　これらの不経済性やリスクを回避するにはどうすべきなのでしょうか。根本的な解決策は、最もインターネットに近い境界部分に、SSL処理を集中的に行う仕組みを設置することです。これにより、Webサーバの負荷増大が回避され、暗号鍵の展開・更新に必要な運用負担は軽減されるとともに、暗号鍵が増えることによるセキュリティ リスクも回避されます。またこの仕組みの内側に他のセキュリティ機能を実装すれば、暗号化によってパケットが隠蔽されることがないため、本来の機能をきちんと果たせるようになります。

SSLが抱えてきた多くの問題は、このような発想の転換を行うことで、スッキリと解決できます。SSL処理はWebサーバで行うものという“思い込み”は、早く捨て去るべきなのです。