hirosanote’s blog

検証環境の構築手順やネットワーク機器のテスト結果、関連する事について記載します。このブログは個人で行っており、所属する会社とは関係ありません。

Apple ATSとロードバランサー

結局延期になってしまいましたが、2016年末までにApple ATS対応のために、SSL証明書サイファースイートの設定等の作業を行う必要がありました。

SSL/TLSの終端をロードバランサ(負荷分散装置、SSL/TLSアプライアンス)を行っている場合、ATSが推奨するサイファースイートを使用する必要があります。各ロードバランサーにて、そのサイファースイートのサポート状況や考慮すべき事項について調査してみました。

 

1. サイファースイート

Apple ATSが推奨するcipher suiteは、以下です。

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

 当たり前ですが、上記のサイファースイートをサポートするロードバランサーを使用する必要があります。どのベンダーがサポートしているのかについては、2016年11月8日にIPAより公開された「SSL/TLSアプライアンス製品の暗号設定方法等の調査」報告書から確認することが出来ます。その報告書から○×表を作成してみました。

f:id:hirosanote:20170109103144p:plain

表を作成して初めて気づいたのですが、日本製のロードバランサは対応していないことが分かりました。ECDHEはHTTP/2でも必須となっているのと、今後のTLS1.3対応のためにも、ECDHEサイファースイートをサポートしている機器を選択すべきです。

 

 

2. ECDHEサイファースイートと証明書

証明書は、以下のものを使用する必要があります。

TLS_ECDHE_ECDSA_xxx = ECC証明書

TLS_ECDHE_RSA_xxx = RSA証明書

多くのサイトで使用されているシマンテック社(旧ベリサイン)からECC証明書を購入する場合、RSA, ECCの両方を購入できるメニューしかないため、金額が高くなります。

RSAのみの証明書 / セキュアサーバID / 81,000円 (有効期間 1年)

RSA/ECCの証明書/ グローバルサーバID / 138,000円 (有効期間 1年)

 

 

3. ECDHEサイファースイートとSSLアクセラレーター

SSLアクセラレーター搭載とうたっているほとんどのロードバランサーは、SSLの処理を行う専用のSSLアクセラレーターチップを搭載しています。これにより、SSL処理によって機器本体が持つ汎用CPUに負荷をかけず、専用のCPUが処理することによりパフォーマンスが向上します。

SSLアクセラレーターチップは、特定のベンダーのある型番のみがECDHEサイファースイートを高速に処理できます。それ以外のモデルは高速に処理できないため、ロードバランサーの汎用CPUで処理しなければならず、ロードバランサー本体のCPU負荷率を高めることにより、サーバ負荷分散やその他の機能のパフォーマンスに影響が出る可能性があります。

 

 

 4. ECDHEサイファースイートとパフォーマンス

ECDHEのサイファースイートを使用した場合、どのくらいパフォーマンスの変化があるのかテストしてみました。

サーバ:Windows2008R2 RSA2048bit 自己証明書 / VMware ESXi上に構築

クライアント : Apache Bench on Ubuntu16 / VMware ESXi上に構築

VMware ESXiが動作しているサーバのCPU : Intel Xeon E3-1220v2@3.10GHz

構成:サーバ --- 1G Switch --- クライアント

 

Apache benchはHTTP1.0を使用するため、SSLコネクションはGETリクエスト毎に切断されます。よってSSL新規接続パフォーマンステストに近いテストが出来ます。

サイファースイート毎にWindows2008サーバのタスクマネージャーより確認出来るCPU負荷率が95% ~ 100%になるようにしました。ファイルサイズは、IISのデフォルトページを使用し、689 bytesです。

 

テスト結果:

ab -n 5000 -c 15 https://10.10.1.11/

SSL/TLS Protocol:       TLSv1,AES128-SHA,2048,128

Requests per second:    445.65 [#/sec] (mean)

 

ab -n 5000 -c 8 https://10.10.1.10/

SSL/TLS Protocol:       TLSv1,ECDHE-RSA-AES128-SHA,2048,128

Requests per second:    276.14 [#/sec] (mean)

 

Windows2008サーバがCPU100%で処理できる新規SSLリクエスト数は以下となり、ECDHEサイファースイートを使用すると約38%悪化します。

AES128-SHA                        : 445

ECDHE-RSA-AES128-SHA : 276

 

 

5. まとめ

5-1. ECDHEサイファースイートをサポートしていないロードバランサーがある。この場合、今後の対応状況によってはリプレイスが必要。

 

5-2. ECDHEサイファイースイートをサポートしているロードバランサーでも、ECDHEサイファースイートをSSLアクセラレーターチップで処理しないモデルがある。この場合、汎用CPUで処理することになり、処理できる新規SSLリクエスト数が低下し、CPU負荷率が高くなる。

 

5-3. 5-2の回避策として、SSLアクセラレーターで処理するサイファースイートを優先に使用するよう設定し、ECDHEしか使えない通信のみ、汎用CPUで処理するようにする。

 

5-4. 仮想版環境でロードバランサーを使用する場合、CPUもしくはCPUコアを複数割り当て、SSL処理に対するCPU負荷を下げる。

 

Apple ATS (App Transport Security)の対応は、ロードバランサーにかかる負荷も考慮する必要があります。

Apple ATSの目的はHTTP通信をやめることも目的となっており、SSLコネクションが増加することになります。ロードバランサーのカタログ値にある最大同時接続数の他に、SSL最大同時接続数が別に存在するものがあるため、パフォーマンス値の他にSSL通信のための最大同時接続数も確認する必要があります。