App Transport SecurityのTLS要件が思った以上に厳しかった件

iOS 9/El Capitan/Xcode 7以降で要注意箇所」でも触れていたが、iOS9及びOS X El CapitanではApp Transport Securityが加わり、デフォルトではSSL(TLS 1.2)通信が強制になるように仕様が変更される。それだけであればよいのだが、その要件が思った以上に厳しいことが判明した。以下に述べてみたい。

TLS 1.2以降必須とはいうが・・・

Forward Secrecyが必要、しかもかなり厳格

前の記事でも述べた通り、TLS 1.2以降が必要になると述べたが、それも前方秘匿性(Forward Secrecy)が確保されたTLS 1.2通信が必要になるということまでは説明していなかった。

しかもこのForward Secrecyの意味がかなり厳格で、App Transport Security Technoteによれば以下の暗号方式(Cipher)しかForward Secrecyとして認められない。

  • 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

そのため、Forward SecrecyでもDHEのものはATSではForward Secrecyとは認められず、通信が拒否されてしまうという問題が発生する模様である。

暗号化にも一定以上の条件を満たす必要がある

ほかにも、以下の条件を満たしていないと、デフォルトではATSでブロックされて通信が行えない。

  • 証明書はSHA256以上のフィンガープリントでなおかつ2048bit幅のRSA鍵、あるいは256bit以上のECC鍵が必要

以上から、クライアント・サーバー間通信を行うようなアプリはサーバーサイドのSSL対応を行う必要性がある。

現時点では例外を設けたりATSを無効化することは可能

ATSはInfo.plistの修正で一定の例外を設けたり無効化したりすることも現時点では可能であるため、必要であればそうすることによって一時しのぎだが弱いSSLや非SSLへの通信が行えるようになる。

ただし、いつそれが使えなくなるかどうか1 が不明瞭な関係上、少なくともiOS9及びEl Capitanの段階でサーバーサイドのSSL対応(具体的にはATS有効時でもブロックされないようにする対応)は絶対に行ったほうがよいだろう。

最後に

iOS/OS Xの次のバージョンで追加されたATSでデフォルトの設定ではアプリだけではなく、(クライアント・サーバー通信を行うアプリでは)サーバーサイドの対応が必要であり、なおかつその条件が厳格になっている関係上、そのちゃんと対策を行いたいところである。

もちろん、どういうことが求められていて、どういう対処をすればいいのかがはっきりと分析してわかっていればSSLの設定自体は経験さえあればそれほど難しいことではないはずなので、落ち着いて設定を行おう。

ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しております。仕事依頼や相談などについては、Contact Formよりお願いいたします。
  1. 最速でiOSでは10あるいは11、OS Xも10.12または10.13あたり []
スポンサーリンク

フォローする