iOS のネットワーク通信

概要

ほぼすべての iOS アプリは一つ以上のリモートサービスのクライアントとして動作します。このネットワーク通信は一般的に公衆 Wi-Fi などの信頼できないネットワーク上で行われるため、従来のネットワークベースの攻撃が潜在的な問題になります。

最近のモバイルアプリの多くはさまざまな HTTP ベースのウェブサービスを使用しています。これらのプロトコルは十分に文書化されており、サポートされているからです。

iOS App Transport Security

iOS 9 以降、Apple は App Transport Security (ATS) を導入しました。これは URL Loading System を使用して行われる接続 (通常 URLSession 経由) に対して常に HTTPS を使うようにオペレーティングシステムが強制する一連のセキュリティチェックです。アプリは Apple のベストプラクティス に従って、適切に接続を保護すべきです。

Apple WWDC 2015 の ATS 紹介ビデオをご覧ください

ATS はデフォルトのサーバー信頼性評価を行い、最低限のセキュリティ要件を要求します。

デフォルトのサーバー信頼性評価:

アプリがリモートサーバーに接続する際、サーバーは X.509 デジタル証明書を使用してそのアイデンティティを提供します。ATS のデフォルトのサーバー信頼性評価には以下に示す証明書の妥当性確認も含まれています。

  • 有効期限が切れていないこと。

  • サーバーの DNS 名と一致する名前を持っていること。

  • 有効な (改竄されていない) デジタル署名を持ち、オペレーティングシステムの Trust Store に含まれる信頼できる認証局 (Certificate Authority, CA) にさかのぼることができるか、ユーザーもしくはシステム管理者がクライアントにインストールしたものであること。

接続に必要な最低限のセキュリティ要件:

さらに ATS は以下に示す一連の 最低限のセキュリティ要件 を満たさない接続をブロックします。

  • TLS バージョン 1.2 以上。

  • AES-128 または AES-256 でのデータ暗号化。

  • 証明書は RSA 鍵 (2048 ビット以上)、ECC 鍵 (256 ビット以上) で署名されていなければならない。

  • 証明書のフィンガープリントは SHA-256 以上を使用しなければならない。

  • リンクは Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) 鍵交換による Perfect Forward Secrecy (PFS) をサポートしなければならない。

証明書の有効性チェック:

Apple によると 、「TLS 証明書の信頼ステータスの評価は RFC 5280 で規定されているように確立された業界標準に従って行われ、RFC 6962 (Certificate Transparency) などの新しい標準も取り入れられています。iOS 11 以降では、Apple デバイスは定期的に失効した証明書と制約のある証明書の最新リストで更新されます。このリストは Apple が信頼するビルトインの各ルート認証局およびその下位の CA 発行者が発行する証明書失効リスト (CRL) から集約されています。このリストには Apple の裁量で他の制約が含まれていることもあります。この情報はネットワーク API 関数を使用してセキュア接続を行う際に参照されます。CA から失効した証明書が多すぎて個別にリストアップできない場合、信頼性評価では代わりにオンライン証明書ステータス応答 (Online Certificate Status Response, OCSP) が必要となり、応答が得られない場合には信頼性評価は失敗します。」

ATS が適用されないのはどのような場合か?

  • 低レベル API を使用する場合: ATS は URLSession に含まれる URL Loading System とその上にレイヤー化された API にのみ適用されます。低レベル API (BSD ソケットなど) を使用するアプリには適用されません。その低レベル API 上に TLS を実装しているものも同様です (アーカイブされた Apple Developer ドキュメントの "Using ATS in Apple Frameworks" セクションを参照してください) 。

  • IP アドレス、非修飾ドメイン名、ローカルホストに接続する場合: ATS はパブリックホスト名に対して行われた接続にのみ適用されます (アーカイブされた Apple Developer ドキュメントの "Availability of ATS for Remote and Local Connections" セクションを参照してください) 。システムは以下に示す接続に対して ATS 保護を提供しません。

    • インターネットプロトコル (Internet Protocol, IP) アドレス

    • 非修飾ホスト名

    • .local トップレベルドメイン (Top-Level Domain, TLD) を使用するローカルホスト

  • ATS 例外を含む場合: アプリが ATS 互換 API を使用する際、ATS 例外 を使用して特定のシナリオで ATS を無効にできます。

さらに学ぶために:

ATS 例外

ATS の制限は Info.plist ファイルの NSAppTransportSecurity キーに例外を設定することで無効にできます。これらの例外には以下を適用できます。

  • セキュアではない接続 (HTTP) の許可

  • 最小 TLS バージョンの引き下げ

  • Perfect Forward Secrecy (PFS) の無効化

  • ローカルドメインへの接続の許可

ATS 例外はグローバルまたはドメイン単位で適用できます。アプリケーションは ATS をグローバルに無効化できますが、個々のドメインをオプトインできます。Apple Developer ドキュメントの以下のリストでは NSAppTransportSecurity Dictionary の構造を示しています。

NSAppTransportSecurity : Dictionary {
    NSAllowsArbitraryLoads : Boolean
    NSAllowsArbitraryLoadsForMedia : Boolean
    NSAllowsArbitraryLoadsInWebContent : Boolean
    NSAllowsLocalNetworking : Boolean
    NSExceptionDomains : Dictionary {
        <domain-name-string> : Dictionary {
            NSIncludesSubdomains : Boolean
            NSExceptionAllowsInsecureHTTPLoads : Boolean
            NSExceptionMinimumTLSVersion : String
            NSExceptionRequiresForwardSecrecy : Boolean   // Default value is YES
            NSRequiresCertificateTransparency : Boolean
        }
    }
}

出典: Apple Developer Documentation.

以下の表はグローバル ATS 例外をまとめたものです。これらの例外の詳細については、公式の Apple Developer ドキュメントの Table 2 を参照してください。

以下の表はドメインごとの ATS 例外をまとめたものです。これらの例外の詳細については、公式の Apple Developer ドキュメントの Table 3 を参照してください。

例外の正当性:

2017年1月1日から Apple App Store レビューでは以下の ATS 例外の一つが定義されている場合に 正当な理由を要求 します。

  • NSAllowsArbitraryLoads

  • NSAllowsArbitraryLoadsForMedia

  • NSAllowsArbitraryLoadsInWebContent

  • NSExceptionAllowsInsecureHTTPLoads

  • NSExceptionMinimumTLSVersion

これはアプリが意図した目的の一部であるかどうかを判断して、慎重に修正しなければなりません。Apple はアプリのセキュリティを低下させる例外について警告し、ATS の障害に直面した場合には 必要な場合にのみ例外を設定し、サーバーの修正を優先する ようにアドバイスしています。

例:

以下の例では、ATS はグローバルに有効 (グローバルな NSAllowsArbitraryLoads は定義されていない) ですが、 example.com ドメイン (とそのサブドメイン) に対して例外が 明示的に設定 されています。このドメインをアプリケーション開発者が所有し、適切な正当性があることを考慮すると、他のすべてのドメインに対して ATS のすべての利点を維持しているため、この例外は許容されるでしょう。しかし、上記のようにサーバーを修正することが常に望ましいと思われます。

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <true/>
        </dict>
    </dict>
</dict>

ATS 例外の詳細については Apple Developer ドキュメント の記事 "Preventing Insecure Network Connections" のセクション "Configure Exceptions Only When Needed; Prefer Server Fixes" および ATS に関するブログ投稿 を参照してください。

サーバー信頼性評価

ATS は Transport Layer Security (TLS) プロトコルで規定されたデフォルトのサーバー信頼性評価を補完する拡張セキュリティチェックを課します。ATS 制限を緩めているとアプリのセキュリティが低下します。アプリは ATS 例外を追加する前に、サーバーセキュリティを向上させる別の方法を優先させるべきです。

Apple Developer ドキュメント ではアプリは URLSession を使用してサーバー信頼性評価を自動的に処理できると説明しています。しかし、アプリはそのプロセスをカスタマイズすることもできます。たとえば、以下のことができます。

  • 証明書の有効期限をバイパスまたはカスタマイズする。

  • 信頼性を緩める/広げる: システムによって拒否されるようなサーバー資格情報を受け入れる。たとえば、アプリに埋め込まれた自己署名証明書を使用して開発サーバーにセキュア接続を行う。

  • 信頼性を強める: システムによって受け入れられるサーバー資格証明を拒否します。

  • その他

参考情報:

iOS ネットワーク API

iOS 12.0 以降、Network フレームワークと URLSession クラスはネットワークおよび URL リクエストを非同期および同期でロードするメソッドを提供します。古いバージョンの iOS では Sockets API を利用できます。

Network フレームワーク

Network フレームワークは 2018 年の Apple Worldwide Developers Conference (WWDC) で紹介された、 Sockets API に代わるものです。この低レベルネットワークフレームワークは動的ネットワーク、セキュリティ、パフォーマンスのサポートが組み込まれたデータ送受信のためのクラスを提供します。

Network フレームワークでは引数 using: .tls が使用されている場合、デフォルトで TLS 1.3 が有効になっています。これは従来の Secure Transport フレームワークよりも優先されるオプションです。

URLSession

URLSessionNetwork フレームワーク上に構築されており、同じトランスポートサービスを利用します。また、エンドポイントが HTTPS の場合、このクラスはデフォルトで TLS 1.3 を使用します。

HTTP および HTTPS の接続には Network フレームワークを直接利用するのではなく URLSession を使用すべきです。 URLSession クラスは両方の URL スキームをネイティブにサポートし、そのような接続のために最適化されています。定型コードをあまり必要としないため、エラーの可能性を減らし、デフォルトでセキュアな接続を確保できます。 Network フレームワークは低レベルや高度なネットワーク要件がある場合にのみ使用すべきです。

Apple の公式ドキュメントには Network フレームワークを使用して netcat を実装する 例や、URLSessionウェブサイトのデータをメモリに取り込む 例が掲載されています。

Last updated