Blog

Tech

ネットワーク

検証

Apple ATSに対応 SSL/TLSプロキシをサーバで安価に作ってみた（構築編）

このエントリーをはてなブックマークに追加

ATS

HTTPS

Nginx

SSL

TLS

こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。

今年に入って、Google が HTTPS を SEO で優遇するという話や Apple の ATS の話が出てきていたりと、通信の暗号化対応が求められているのではないでしょうか？私の部門でも漏れなく ニーズが上がってきており、プライベートクラウドでどう対応していくかが非常に重要になってきております。

Apple ATS とは

 

冒頭に少し触れた Apple の ATS ですが、iOS9 で デフォルトで有効になっている機能で、有効になっているとWEBサービスに接続するアプリケーションは HTTPS を使用しないと接続を拒否されることとなります。この記事を書いている(2016/08)現在では、デベロッパーが ATS を任意で無効にできるのですが、2016年末には ATS の有効化が必須になるという情報も出てきています。そこで今回のキーとなる ATS について、Apple のドキュメントから少し詳細に触れておきます。

 

Apple の ATS ではさらに暗号化に関する条件をつけています。ポイントを抜粋しておきます。

https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40016240

The server certificate must meet at least one of the following trust requirements:
Issued by a certificate authority (CA) whose root certificate is incorporated into the operating system
Issued by a trusted root CA and installed by the user or a system administrator
The negotiated Transport Layer Security version must be TLS 1.2
The negotiated TLS connection cipher suite must support forward secrecy (FS) and be one of the following:
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
The leaf server certificate must be signed with one of the following types of keys:
Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits
Elliptic-Curve Cryptography (ECC) key with a size of at least 256 bits
In addition, the leaf server certificate hashing algorithm must be Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 (that is, SHA-256 or greater).
If ATS is not enabled, the system still performs HTTPS server trust evaluation but you can override it on a case-by-case basis, as described in HTTPS Server Trust Evaluation. With ATS fully enabled, you cannot override the default HTTPS server trust evaluation.

まず、TLS1.2 に対応している必要があります。次に指定の Chiper に対応する必要があります。
この Chiper への対応がハードルが高いと思われる方が多いのでしょうか？

HTTPS の需要に合わせてインフラで考えるべきこと

 

HTTPS の比率がこれから増えてくるとなると、頭を悩ますのはどのコンポーネントで SSL/TLS の複合化と暗号化をするかという点です。選択肢は以下の通りだと思います。

  1. すべてのWEBサーバで実施する
  2. ロードバランサーなどの専用ハードウェアを購入する
  3. その他

1.のサーバで終端する場合は、サーバが増えれば増えるほど管理がとても煩雑になりますし更新作業の手間もサーバ台数に比例して増えていきます。また、 WEB サーバの CPU リソースを使用することにもつながります。ただし、実装自体にはコストがかからないというメリットがあります（※ CPU 負荷によるサーバ増加は除く）

2.のロードバランサーなどの専用装置を購入する場合は、1.のデメリットを解決することが可能で多くの会社ではこちらを採用しているのではないでしょうか。ただし、ATS に対応した Chiper  となると、本記事の執筆時点ではパフォーマンスの上限なども厳しくコスト面ではそれなりの投資となると考えております。（※2 環境 採用する機器により異なる点および執筆者個人の見解である点はご理解の上で読んでください）

 

弊社で検討している方式

 

まだ正式にリリースまでには至っていないのですが、現在試験を行っている環境では  3. その他 に分類される方式を採用しました。具体的には、 Nginx をリバースプロキシとして使いつつ、 SSL の複合化/暗号化を行います。Nginx は複数サーバで起動しており、その上部ではロードバランサーが稼働しております。弊社では基本的にDSRを採用しておりこの構成においてロードバランサーは TCP の L4 レベルの分散をするだけに留まるため、負荷はかなり少ないものと認識しております。

周辺の構成は運用に合わせて現在検討中が以下が現在想定している概要図です。

 

network

気になるパフォーマンスですが、弊社内での検証データを以下にグラフとして公開させて頂きます。

今回、性能試験に関するシミュレータはab(apache bench)を使用しております。また、サーバの構成や環境によっても異なると思いますので参考値として使用して頂くようお願い致します。

 

前提事項

  • SSL Sessionの再利用はなし
  • Nginx のバージョンは 1.10.1 を使用する
  • Apple ATS 対応の  cipher suite のみを受ける

まず、 E3-1270v3 の試験結果です。ハイパースレッドで合計 8コア@3.50GHz のマシンです。

ある程度のばらつきはありましたが、平均で 12712.6025 TPS という結果でした。CPUはすべてのコアで 97% 〜 100% 近くで推移している状態です。OpenSSLは最新の1.1.0 を使用しました。

 

※ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 を使用して、session id の使い回しもなく通信して状態のデータです。

image

次に、 E5-2680v4 の試験結果です。マルチプロセッサ、ハイパースレッドで OS上からは合計 56コア@2.40GHz で見えるマシンです。

こちらもある程度のばらつきはありましたが、平均で 29299.562 TPS という結果でした。サーバの利用期間の関係で、十分な検証環境が準備できずCPUはすべてのコアで 70%  程度で推移している状態です。過去の検証データとなるため、OpenSSLは検証当時最新の1.0.1 eを使用しました。

 

image-2

Tips

 

MAC の OS X El Capitan 以降では以下のコマンドでサーバが ATS に対応しているか確認可能です。

$ nscurl --ats-diagnostics https://.... 

 

まとめ

 

今回、コア数が少なくクロック数が高いCPUとコア数が多いがクロック数が低いCPUで試験をしました。結果としてはNginxの設定を正しく行うことで、各CPUコアを効率良く使用することができ、E5-2680v4 が性能としては安定して高い値を取ることがわかりました。特にE5-2680v4 は今回検証機としてお借りした Intel の最新ライナップであることからクロック数が落ちたものの性能としては高い値を叩きだすことは想定しておりましたが、とても良い数値が出たと思います。

 

実際の構成ですが、ロードバランサーでこのNginxクラスタへ分散をするためスケールアウトがとても容易になります。スケールアウトするごとにラックの場所を取るため、高密度サーバを用いて構成するのが理想かなと思います。

 

今回は特に性能面についてご紹介しましたが、次回以降で運用面についてもご紹介できればと考えております。

Author

アバター
komei