LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

ラックピープル | 

必須化まで約2ヵ月半!App Transport Securityについて

App Transport Security(以降、ATS)が必須化されるまで約2ヶ月半と迫ってきたので、ATSに関してご説明します。詳しくはCocoa keys*1 をご覧ください。


【追記:2017/01/04】
Appleは2016年末を目途にApp Storeのすべてのアプリケーションに対し、ATSを必須化すると発表しましたが、米国時間12月21日にAppleの開発者向けサイトで「準備期間をさらに延ばすため」という理由により延期すると発表しました。現段階では期限は未定となっており、決定次第、発表するとしています。

スクリーンショット

Appleの開発者向けサイト:
Supporting App Transport Security - News and Updates - Apple Developer


App Transport Security(ATS)とは

ATSとは、iOS 9.0およびOS X v10.11以降で導入された、「サーバとアプリケーション間でセキュアな通信を保証するための機能」です。ATSを有効化にすることにより、Appleが推奨する条件を満たすHTTPS通信のみ許可され、条件を満たさないHTTPS通信やHTTP通信は強制的に接続失敗扱いとなります。
なお、ATSのサポート対象はiOS 9.0およびOS X v10.11以降におけるNSURLSession、NSURLConnectionを使用しているAPIで、それ未満のOSバージョンや、NSURLSession、NSURLConnectionを使用していないAPIはサポート対象外です。

現在は、ATS自体の無効化を行うことが可能ですが、Appleは6月13日(米国時間)に開幕されたWorldwide Developers Conference 2016(WWDC 2016)で、2016年末を目処にApp Storeの全てのアプリケーションに対しATSを必須化すると発表しました。

How iOS Security Really Works(PageNo.100)

How iOS Security Really Works(PageNo.100)*2

Appleが推奨する通信における必要条件

後述する例外等を設定しない限り、下記条件を満たさない通信はすべて接続失敗扱いとなります。

  • TLSのバージョン
    TLS 1.2以上
  • 暗号スイート
    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
  • サーバ証明書
    OSに組み込まれている認証局によって発行された証明書
    信頼されたルートCAによって発行されて、ユーザやシステム管理者によってインストールされた証明書
  • サーバ証明書の署名する際のキー
    2048bit以上のRSAキー
    256bit以上の楕円曲線暗号キー(ECCキー)
  • サーバ証明書のハッシュアルゴリズム
    256bit以上のダイジェスト長であるSHA-2(つまり、SHA-256以上)

また、ATSを有効にすることで自己証明書はもちろん、通信先サーバのドメイン名と証明書のCommon Nameが異なっている場合もエラーとなり接続失敗扱いとなるため、中間者攻撃の対策として有効です。たとえば、下図のようにCertificateのあと証明書エラーが発生することによって、クライアント(192.168.100.200)から通信が終了(FIN ACK)されます。
ただし、先述したようにATSのサポート対象はiOS 9.0およびOS X v10.11以降におけるNSURLSession、NSURLConnectionを使用しているAPIのみです。そのため、それ未満のOSバージョンや、NSURLSession、NSURLConnectionを使用していないAPIを使用している場合はATSが有効にならず、中間者攻撃の対策とならないのでご注意ください。

証明書検証失敗時のWiresharkログ例

証明書検証失敗時のWiresharkログ例

なお、サーバが利用可能な暗号スイートは、下記方法で調べることができます。
・openssl ciphers -v

「openssl ciphers -v」実行例

「openssl ciphers -v」実行例

・SSL Server Test(Powered by Qualys SSL Labs)
[https://www.ssllabs.com/ssltest/index.html]

推奨される暗号スイートがサーバで対応していない場合は、アプリケーションとサーバ間で行われるSSLハンドシェイク時に下記のようにエラー(Handshake Failure)が発生します。

SSLハンドシェイクエラー発生時のWiresharkログ例

SSLハンドシェイクエラー発生時のWiresharkログ例

ATSで使用可能なキー

下図に示すように、プレリリース版で使用可能であったキーから変更されていますので、正式版で採用されているキーについてそれぞれ説明します。

プレリリース版のATSで使用可能であったキー

プレリリース版のATSで使用可能であったキー

正式版のATSで使用可能なキー

正式版のATSで使用可能なキー

(1)NSAppTransportSecurity(Dictionary)

  • iOSとOS Xのアプリケーションおよびアプリケーションの拡張機能のHTTPコネクションのためのデフォルトの強力なセキュリティ変更を定義
  • iOS 9.0および OS X v10.11以降で有効

(2)NSAllowsArbitraryLoads(Boolean)

  • デフォルト値は『No』
  • 『Yes』に設定すると、「NSExceptionDomains」で設定したドメインの接続からすべてのネットワークに対する接続に関するATSを無効化
  • 『Yes』に設定すると、App Storeへアプリを提出する際に正当な理由が必要
  • iOS 10.0およびmacOS v10.12以降において、下記キーが設定されている場合、本キーは無視される
    - NSAllowsArbitraryLoadsInMedia
    - NSAllowsArbitraryLoadsInWebContent
    - NSAllowsLocalNetworking

(3)NSAllowsArbitraryLoadsInMedia(Boolean)

  • デフォルト値は『No』
  • iOS 10.0およびmacOS v10.12以降において有効
  • 『Yes』に設定すると、AVFoundationからAPIを使用してロードされたメディアに関する全てのATSを無効化
  • 本キーは、FairPlayやsecure HLSによって保護されたファイルとして、既に暗号化されているメディアロードで、なおかつ個人情報を含まない時に使用すること
  • 本キーを設定した場合、その値にかかわらず「NSAllowsArbitraryLoads」は無視される

(4)NSAllowsArbitraryLoadsInWebContent
(Boolean)

  • デフォルト値は『No』
  • iOS 10.0およびmacOS v10.12以降において有効
  • 『Yes』に設定すると、WKWebView、UIWebView (iOSのみ)、WebView(OS Xのみ)から発行された要求に関してATSを無効化
  • NSURLSession接続に関するATSに影響を与えることなく、WebViewのみATSから除外するこが可能
  • 古いOSバージョンをサポートするには、本キーに『Yes』を設定し、「NSAllowsArbitraryLoads」のサブキーも設定する
  • 本キーを設定した場合、その値にかかわらず「NSAllowsArbitraryLoads」は無視される

(5)NSAllowsLocalNetworking(Boolean)

  • デフォルト値は『No』
  • iOS 10.0およびmacOS v10.12以降において有効
  • 『Yes』に設定すると、ローカルリソースの読み込みを許可
  • iOS 9およびOS X v10.11以下でも動作し続けることを許可するには、本キーに『Yes』を設定し、「NSAllowsArbitraryLoads」のキーも『Yes』と設定する
  • 本キーを設定した場合、その値にかかわらず「NSAllowsArbitraryLoads」は無視される

(6)NSExceptionDomains(Dictionary)

  • ATSの例外を設定したいドメインを1つ以上記述
  • 値は「example.com」などのドメイン名で、下記制約が存在する。
    - 文字はすべて小文字
    - ポート番号は含まない
    - IPアドレスでの指定は不可
    - 「example.com.」など、最後が「.」で終わる指定の仕方は不可

(7)<domain-name-string>(Dictionary)

  • 「NSExceptionDomains」内の任意のドメイン名を指定し、複数のインスタンスを追加可能
  • 下記の子キーを1つ以上含むこと
    NSIncludesSubdomains
    NSExceptionAllowsInsecureHTTPLoads
    NSExceptionMinimumTLSVersion
    NSExceptionRequiresForwardSecrecy
    NSRequiresCertificateTransparency

(8)NSIncludesSubdomains(Boolean)

  • デフォルト値は『No』
  • 『Yes』に設定すると、すべてのサブドメインに対して「NSExceptionDomains」の例外が適応される

(9)NSExceptionAllowsInsecureHTTPLoads
(Boolean)

  • デフォルト値は『No』
  • 『Yes』に設定すると、下記が許可される
    - HTTP通信
    - 証明書なしの接続
    - 自己証明書を用いた接続
    - 有効期限切れの証明書を用いた接続
    - 通信先ホスト名と証明書のCommon Name(CN)が異なる証明書を用いた接続
  • TLSの推奨条件は何の影響も受けない
  • 『Yes』に設定すると、App Storeへアプリを提出する際に正当な理由が必要

(10)NSExceptionMinimumTLSVersion(String)

  • デフォルト値は『TLSv1.2』
  • 接続のための最小のTLSバージョンを指定する(設定値は下記参照)
    - TLSv1.0
    - TLSv1.1
    - TLSv1.2
  • SSLのバージョン指定は不可
  • 本キーを設定すると、App Storeへアプリを提出する際に正当な理由が必要

(11)NSExceptionRequiresForwardSecrecy
(Boolean)

  • デフォルト値は『Yes』
  • 『No』に設定すると、Appleが推奨する通信における必要条件で示した暗号スイートに加え、Perfect Forward Secrecy(PFS:前方秘匿性)をサポートしない下記の暗号スイートも許可
    - TLS_RSA_WITH_AES_256_GCM_SHA384
    - TLS_RSA_WITH_AES_128_GCM_SHA256
    - TLS_RSA_WITH_AES_256_CBC_SHA256
    - TLS_RSA_WITH_AES_256_CBC_SHA
    - TLS_RSA_WITH_AES_128_CBC_SHA256
    - TLS_RSA_WITH_AES_128_CBC_SHA

(12)NSRequiresCertificateTransparency
(Boolean)

  • デフォルト値は『No』
  • iOS 10.0およびmacOS v10.12以降において有効
  • 『Yes』に設定すると、下記が必要となる
    - 証明書の透明性(CT)のタイムスタンプが署名されていること
    - CTログが知られていること
    - ドメインのサーバ証明書が与えられていること

「正当な理由」について

下記キーを使用するためには、使用するための正当な理由をApple側に提供する必要があります。また、正当な理由だけではなく、セキュアな通信ができない理由を判断するための十分な情報を提供する必要もあります。
・NSAllowsArbitraryLoads
・NSExceptionAllowsInsecureHTTPLoads
・NSExceptionMinimumTLSVersion

なお、正当な理由の例として、下記をAppleは挙げています。
・Appleが提示する推奨条件を満たしていない管理外サーバと通信を行う必要がある
・Appleが提示する推奨条件を満たすためのアップグレードを行えないデバイスと通信を行う必要があり、なおかつパブリックなホスト名を経由して通信する必要がある
・さまざまなソースが埋め込まれたWebコンテンツを提供する必要があり、なおかつ「NSAllowsArbitraryLoadsInWebContent」でサポートされているクラスを使用することができない

「NSAppTransportSecurity」の使用例

Appleの公式ドキュメントでは、「NSAppTransportSecurity」の使用例をいくつか紹介しています。

・単一サーバへの安全でない接続を許可する場合

例:「media-server.example.com」のみに対して下記を許可
- HTTP通信
- 証明書なしの接続
- 自己証明書を用いた接続
- 有効期限切れの証明書を用いた接続
- 通信先ホスト名と証明書のCommon Name(CN)が異なる証明書を用いた接続

単一サーバへの安全でない接続を許可する場合

・単一サーバへの低いセキュリティレベルを許可する場合

例:「less-secure.example.com」のみに対して下記を許可
- TLS v1.0以上による接続
- PFSをサポートしない暗号スイートを用いた接続

単一サーバへの低いセキュリティレベルを許可する場合

・特定サーバ以外への安全でない接続を許可する場合

例:「domain-i-control.example.com」および「other-domain-i-control.example.com」を除く全てのドメインに対して下記を許可
- HTTP通信
- 証明書なしの接続
- 自己証明書を用いた接続
- 有効期限切れの証明書を用いた接続
- 通信先ホスト名と証明書のCommon Name(CN)が異なる証明書を用いた接続

特定サーバ以外への安全でない接続を許可する場合

以上、ATSについての説明およびCocoa keysの簡単な翻訳でした。詳しくはCocoa keys*1 をご参照ください。2016年末まで約2ヶ月半と迫ってきましたので、ATSに対応されることをお勧めします。

*1 Cocoa Keys
[https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW34]
*2 How iOS Security Really Works (Session 705)[https://devstreaming-cdn.apple.com/videos/wwdc/2016/705s57mrvm8so193i8c/705/705_how_ios_security_really_works.pdf]

この記事は役に立ちましたか?

はい いいえ