WebサーバにSSL処理を任せてはいけない理由

「セキュリティ」と一口に言っても、セキュリティベンダーだけではなく、さまざまなベンダーが、DoS攻撃からマルウェアによる攻撃まで、さまざまなサイバー攻撃への対策製品を提供しています。この連載では、ネットワークベンダーから見たセキュリティの現状を解説していきます。第1回のテーマは「SSL」における問題点です。

SSLが増えるWebの世界

よく知られているように、WebブラウザとWebサーバ間で通信を暗号化し、盗聴や改ざんを防止する技術がSSLです。

SSLを使用する際は暗号化処理が必要になりますが、CPUに大きな負荷がかかります。HTTPSでWebページにアクセスした場合、画像を含め、すべてのコンテンツが暗号化されてから転送されます。そのため、トラフィックが増えれば増えるほど、Webサーバに与える負荷も増大します。

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

WebサーバにおけるSSLの暗号化処理負荷は、暗号鍵の長さが短かった頃は我慢できる範囲の処理負荷だったと言えます。しかし2004年8月に、NIST(National Institute of Standards and Technology:アメリカ国立標準技術研究所)の示したガイドラインが、状況を大きく変化させました。

その内容は、「これまで使用されてきた暗号鍵は1024ビットだったが、1024ビットのままでは安全性を確保することが難しい。1024ビットの暗号鍵は使用期限を2010年にすべき」というものです。これは「暗号アルゴリズムの2010年問題」と呼ばれています。

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

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

SSLパフォーマンス
	一般的なハードウェア
鍵長	32bit	64bit
1024	525 TPS	1570 TPS
2048	96 TPS	273 TPS
4096	15 TPS	38 TPS

上の表は、2010年問題が改めてクローズアップされた2011年1月に作成されたものです。一般的な64ビット・サーバでSSLを処理した場合、暗号鍵長が1024ビットのケースでは1570 TPS(Transactions Per Second)、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証明書の実装も必要です。証明書をただ"置く"だけではなく、有効期限も適切に管理した上で、必要に応じて更新するという作業も必要になります。これを多くのWebサーバで行うには、大きな運用負担となり、規模が増大するほど、負担も累積的に増大します。これに加えて、システムに実装する暗号鍵の数が増えれば増えるほど、管理上のセキュリティ確保にも負担がかかります。

1台のサーバで複数のドメインを運用する「バーチャルホスト」では、原則としてSSLが使えないことにも注意が必要です。SSLではHTTPヘッダが暗号化されているため、「クライアントがどのホスト名を要求しているのか」を判断できません。

この問題の解決策としては、SSL/TLSの拡張仕様の1つであるSNI(Server Name Indication)を活用する方法があり、バーチャルサーバでもSSLが使えるようになります。

ただし、注意するポイントとして、「SNIを使用する場合にはWebサーバ側だけではなく、Webブラウザ側の対応も必要」ということが挙げられます。SNIは比較的新しい拡張仕様のため、対応していないWebブラウザも少なくありません。

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

WebサーバのSSL処理について、不経済性に伴うパフォーマンスの低下や運用管理面でのデメリットを挙げましたが、それ以外にも問題点があります。

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

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

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

これらの不経済性やリスクはどのように回避すべきなのでしょうか。根本的な解決策は、最もインターネットに近い境界部分に、SSL処理を集中的に行う仕組みを設置することです。

これにより、Webサーバの負荷増大を回避でき、暗号鍵の展開・更新に必要な運用負担が軽減されるとともに、暗号鍵が増えることによるセキュリティのリスクも回避されます。

また、この仕組みの内側に、先ほど挙げたセキュリティ・アプライアンスを設置すれば、暗号化によってパケットが隠蔽されないため、本来の性能を発揮できます。

「SSL処理はWebサーバで行うもの」という"思い込み"は、早く捨て去るべきなのです。

著者プロフィール

伊藤 悠紀夫(いとう ゆきお)
F5ネットワークスジャパン
セールスエンジニアリング本部
プリセールスコンサルタント

UNIXサーバー、ストレージ、シン・クライアントといったインフラエンジニアを経て、F5ネットワークスジャパンへ2012年に入社。
現在はセキュリティ・クラウドをキーワードにイベント講演やハンズオンラボを行い、F5ソリューションの啓蒙活動に奮闘中。
最近はOpenStackやIoTといったキーワードを中心に連携ソリューションを模索している。