HTTPDNS:iOS ネイティブシナリオでの HTTPDNS の利用

3.1 プレーン HTTP シナリオ

平文 HTTP リクエストの場合、ネットワークリンクに TLS/SSL ハンドシェイクや証明書検証は存在しません。したがって、HTTPDNS を統合するためのコア操作は HTTP レイヤーでのみ実行されます：

1. リクエスト URL の Host を HTTPDNS によって名前解決された IP アドレスに置き換えます。

   • 例えば、元のリクエスト URL が http://example.com/api で、HTTPDNS がそれを IP アドレス 1.2.3.4 に解決した場合、URL を http://1.2.3.4/api に変更できます。

2. HTTP ヘッダーの Host を元のドメイン名に明示的に設定します。

   • NSMutableURLRequest を使用する場合、リクエストヘッダーに request.allHTTPHeaderFields[@"Host"] = @"example.com"; を追加できます。これにより、サーバーはアプリケーション層で正しいドメイン名を識別できます。

3.2 HTTPS (非 SNI) シナリオ

SNI メカニズムを使用しない、または少数の固定ドメイン名のみを含む (証明書がこれらのドメインのみをカバーする) HTTPS サイトの場合、次のように NSURLSession レイヤーで HTTPDNS を統合し、証明書検証を実行できます：

1. リクエスト URL の Host を HTTPDNS によって名前解決された IP アドレスに置き換えます。

   • 例えば、元のリクエスト URL が https://example.com/api で、HTTPDNS がそれを IP アドレス 1.2.3.4 に解決した場合、URL を https://1.2.3.4/api に変更できます。

2. HTTP ヘッダーの Host を元のドメイン名に明示的に設定します。

   • 同様に、NSMutableURLRequest で request.allHTTPHeaderFields[@"Host"] = @"example.com"; を設定できます。

3. 証明書検証プロセスのフック

   • これは HTTPS リクエストであるため、TLS ハンドシェイク中に証明書検証が必要です。この時点で、IP アドレスを直接 Host としてチェックに使用すると、ドメイン名と証明書の不一致の問題が発生します。

   • NSURLSessionDelegate のコールバックメソッド URLSession:didReceiveChallenge:completionHandler: で、システムから取得した serverTrust を検証する際に、IP アドレスを元のドメイン名 (example.com) に置き換えることができます。これにより、証明書検証が成功します。

   • コード例:

     - (void)URLSession:(NSURLSession *)session
                   task:(NSURLSessionTask *)task
     didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
       completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition,
                                   NSURLCredential *credential))completionHandler {
         if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
             NSString *originalHost = [self getOriginalHostFromRequest:task.originalRequest];
             SecTrustRef serverTrust = challenge.protectionSpace.serverTrust;
             if ([self evaluateServerTrust:serverTrust forDomain:originalHost]) {
                 // 証明書が検証されました。
                 NSURLCredential *credential = [NSURLCredential credentialForTrust:serverTrust];
                 completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
             } else {
                 // 証明書の検証に失敗しました。デフォルトのハンドラを使用します。
                 completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
             }
         } else {
             completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
         }
     }
     
     - (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain {
         // 証明書検証ポリシーを作成します。
         NSMutableArray *policies = [NSMutableArray array];
         if (domain) {
             [policies addObject:(__bridge_transfer id) SecPolicyCreateSSL(true, (__bridge CFStringRef) domain)];
         } else {
             [policies addObject:(__bridge_transfer id) SecPolicyCreateBasicX509()];
         }
     
         // 検証ポリシーをサーバー証明書にバインドします。
         SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef) policies);
         // 現在の serverTrust が信頼できるかどうかを評価します。Apple は、結果が kSecTrustResultUnspecified または kSecTrustResultProceed の場合、serverTrust は検証可能であると推奨しています。詳細については、https://developer.apple.com/library/ios/technotes/tn2232/_index.html をご参照ください。
         // SecTrustResultType の詳細については、SecTrust.h をご参照ください。
         SecTrustResultType result;
         SecTrustEvaluate(serverTrust, &result);
         return (result == kSecTrustResultUnspecified || result == kSecTrustResultProceed);
     }

4.1 カスタム `NSURLProtocol` の実装

iOS では、開発者は NSURLProtocol を継承することで、システムが開始したネットワークリクエストをインターセプトできます。その後、より低いレベルで HTTP/HTTPS リクエストロジックを実装できます。CFNetwork や NSInputStream/NSOutputStream などのインターフェイスに基づいて、すべてのネットワーク操作を手動で完了させることができます：

1. リクエストをインターセプトする

   • canInitWithRequest: メソッドで、現在のリクエストをインターセプトするかどうかを判断できます。

   • startLoading メソッドで、元のリクエスト URL のドメイン名を IP アドレスに置き換えることができます。後続の証明書検証と SNI 設定のために、元のドメイン名を保持する必要があります。

2. SNI を設定する

   • CFStream 関連の API または SecureTransport インターフェイスを使用して、kCFStreamSSLPeerName を元のドメイン名として指定できます。これにより、基盤となるレイヤーが SSL ハンドシェイクフェーズで正しいドメイン名情報を含めることが保証されます。

3. 証明書の検証

   • 証明書検証プロセスを手動で実行して、証明書に含まれるドメイン名が元のドメイン名と一致することを確認できます。

参考例として、Alibaba Cloud が httpdns_ios_demo で提供している HttpDnsNSURLProtocolImpl.m のサンプル実装をご参照ください。必要に応じて変更または再利用できます。

4.2 `libcurl` を利用したネットワークリクエスト

libcurl は C で実装されたクロスプラットフォームのネットワークライブラリです。SNI フィールドを手動で設定して、SSL ハンドシェイク中に正しいドメイン名情報を渡すことをサポートしています。これにより、複数のドメイン名が同じ IP アドレスを共有するシナリオで証明書検証を完了できます。一般的なプロセスは次のとおりです：

1. ドメイン名を解決して対応する IP アドレスを取得する。

   • 例えば、resolveHostSyncNonBlocking: などの HTTPDNS API 操作を使用して、ターゲットドメイン名の IP アドレスを取得できます。

2. SNI と IP マッピングを設定する。

   • CURLOPT_RESOLVE または他の API を使用して、「domain:port:resolved_IP」マッピングを curl の内部 DNS キャッシュに追加します。

   • CURLOPT_URL には元のドメイン名を引き続き使用します。これにより、TLS ハンドシェイクに正しいドメイン名が含まれることが保証されます。

3. 証明書を検証する。

   • libcurl はデフォルトで証明書検証を有効にします。必要に応じて、対応するコールバックを使用して証明書をより詳細にチェックすることもできます。

以下のコアコードスニペット (擬似コード) は、iOS で `libcurl` と HTTPDNS の解決結果を使用してリクエストを完了する方法を示しています：

CURL *curl_handle = curl_easy_init();
if (curl_handle) {
    // 例：HTTPDNS から IP = 1.2.3.4 を取得、ターゲットドメイン名 = example.com、ポート = 443
    struct curl_slist *dnsResolve = NULL;
    dnsResolve = curl_slist_append(dnsResolve, "example.com:443:1.2.3.4");
    // ドメインと IP のマッピングを設定します。
    curl_easy_setopt(curl_handle, CURLOPT_RESOLVE, dnsResolve);

    // URL として元のドメイン名を引き続き使用します。
    curl_easy_setopt(curl_handle, CURLOPT_URL, "https://example.com");

    // SSL 検証を有効にします。
    curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 1L);
    curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYHOST, 2L);

    // リクエストを開始します。
    CURLcode res = curl_easy_perform(curl_handle);

    // 結果を確認します。
    if (res != CURLE_OK) {
        fprintf(stderr, "curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
    }

    // クリーンアップします。
    curl_easy_cleanup(curl_handle);
    curl_slist_free_all(dnsResolve);
}

4.3 EMASCurl の利用

iOS で libcurl を直接使用する際の参入障壁を下げるために、Alibaba Cloud EMAS チームは EMASCurl ライブラリを提供しています。これは libcurl をカプセル化し、HTTPDNS との直接統合をサポートしています。

1. インストールとインターセプト

   • 主に 2 つの使用方法を提供します： 1) 特定の NSURLSessionConfiguration で作成された NSURLSession をインターセプトする。 2) システムのグローバルな [NSURLSession sharedSession] をインターセプトする。

   • API インターフェイスの詳細については、GitHub の README ファイルをご参照ください。

2. HTTPDNS との統合

   • EMASCurlProtocolDNSResolver プロトコルを実装して、HTTPDNS の解決結果を EMASCurl に渡すことができます。

   • resolveDomain: メソッドで、[HttpDnsService resolveHostSyncNonBlocking:] を呼び出して IP アドレスを取得できます。その後、IP アドレスを EMASCurl に返して、後続の SNI 設定とリクエスト送信を完了できます。

3. 証明書の検証

   • EMASCurl は libcurl の証明書検証メカニズムに依存しています。開発者は、ビジネス要件を満たすために、対応するインターフェイスを通じて証明書検証を拡張またはカスタマイズすることもできます。

4. HTTP/3 のサポート

   • EMASCurl は、QUIC 対応の libcurl に基づくカプセル化バージョンである EMASCurl/HTTP3 を提供します。開発者は必要に応じて 統合し、追加の適応なしで HTTP/3 CAPABILITIES を使用できます。