2

https を使用してサーバーと通信する iOS Enterprise POS アプリに取り組んでいます。iOS7 GM での SSL エラーの受信を見てきました- "AddTrust External CA Root" is not trusted? および自己署名 CA と自己署名証明書の違いおよび一般的に Web を精査しましたが、どこにも行きません。

アプリは、http または https プロトコルを使用して iOS6.1 で正常に動作します。また、iOS 7GM では http 経由では正常に動作しますが、https 経由では機能しません。サーバーに送信する最初のメッセージで失敗します。アプリ側では、次の認証チャレンジを処理します。

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge: (NSURLAuthenticationChallenge *)challenge 
{
    [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] 
         forAuthenticationChallenge:challenge];
}

その後、コールバックを取得します：

- (void)connectionDidFinishLoading:(NSURLConnection *)connection

いいえ：

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error

これは、クライアントとサーバーが接続のネゴシエーションに成功し、暗号化プロトコルに同意したことなどを意味すると思います。残念ながら、(ネットワーク スタックに関する限り) 成功したように見えますが、AMF ペイロードに 0 バイトのデータが返されます。

ここが興味深い部分です。サーバー側 (JBoss4.2.3) では、AMFRequest を含む httpRequest 本体をブレークポイントして調べることができます。http では、本文に常に 384 バイトが含まれます。https 経由で、クライアントが iOS 6.1 の場合は 384 バイトを取得しますが、クライアントが iOS 7 の場合は 0 バイトを取得します。https 要求はサーバーによって「正常に」受け入れられ、エラーやセキュリティ違反などは発生しなかったと解釈します。

もう1つのデータポイント。クライアント側でCharlesを実行すると、iOS 7シミュレーターを使用してhttps経由ですべてが正しく機能します。私の 384 バイトの AMFRequest は、Charles とサーバーの両方で問題なく表示されます。Charles は http プロキシとして機能しますが、アプリはそれについて何も知りません。Charles の証明書をインストールしたので、SSL 経由でサーバーと通信していると思います (よくわかりません)。

助けや提案をありがとう。

更新: Apple が推奨するアプローチを実装しました。

- (void)connection: (NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
{
    traceMethod();
    SecTrustRef trust = challenge.protectionSpace.serverTrust;
    NSURLCredential *credential = [NSURLCredential credentialForTrust: trust];
    [challenge.sender useCredential: credential
         forAuthenticationChallenge: challenge];
}

しかし、古い (iOS 5 より前の) 方法とまったく同じ結果が得られます。

4

4 に答える 4

1

かなりの調査の後、Apple Developer Tech Support にインシデントをオープンし、最終的に説明を受けました。

SSL TLS プロトコルに対する「中間者」攻撃である「BEAST 攻撃への推奨対策」として、Apple が iOS 7 に変更を加えたことを確認できました。CERT に関するこの記事を参照してください。

理想的な解決策は、使用する JBoss (Tomcat) ssl コネクタを変更することです。

sslProtocol="TLSv1.2"

残念ながら、ストック JBoss4.2.3GA 実装は TLSv1.1 または TLSv1.2 を処理することも、この対策を使用するメッセージを処理することもできません。JBoss 構成をアップグレードすることが唯一の解決策のようです。これには、JBoss の大幅な変更が必要です。このJBoss の記事を参照してください。

別の方法としては、ネットワーク メソッドを書き直して下位レベルのフレームワーク (NSURLConnection の代わりに CFSocketStream) を使用し、BEAST 対策を無効にすることです。これには 2 つの欠点があります。セキュリティの脆弱性が再び露呈することと、完全なテスト (特にネットワーク エッジ ケースのシミュレーション) が必要な重要な実装であることです。

私の場合、ホリデー シーズン前にそのような規模の変更が許される時間はありません。私のクライアントは大手小売業者で、IT 部門は 10 月中旬に環境をロックダウンしました。

おそらく、この情報は他の誰かを助けるでしょう。

于 2013-10-04T17:30:47.163 に答える
0

iOS 7 が Jboss eap 6.0.1 の resteasy メソッドと通信するのと同じ問題がありました。

答えは、ssl タグ プロトコルを TLSv1.2 に設定することです。例えば

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
   <ssl name="ssl" key-alias="awssink" password="keystore-password" certificate-key-file="${jboss.server.config.dir}/attimoto.jks" verify-client="false" protocol="TLSv1.2"/>
</connector>

現在、Bearer トークンを使用して安静なメソッドにアクセスしているため、AFNetworking 2+ を使用して次のようにします。

NSString *secureURLString = [secureBaseURLString stringByAppendingString:BURP];
NSLog(@"the secure url is %@\n\n", secureURLString);

// set up the request manager
AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
// allow invalid certificates
manager.securityPolicy.allowInvalidCertificates = YES;

//Note we dont deal with pinned certificates since we are doing bearer token    

manager.responseSerializer = [AFHTTPResponseSerializer serializer];

manager.requestSerializer = [AFHTTPRequestSerializer serializer];
[manager.requestSerializer setValue:BEARER_TOKEN forHTTPHeaderField:@"Authorization"];
//Note we do NOT use setAuthorizationHeaderFieldWithToken:BEARER_TOKEN];
//Ultimately you want just a header like this
// "Authorization: Bearer textofthebearertoken"
//So BEARER_TOKEN is literally @"Bearer thetextofthebearertoken"

[manager GET:secureURLString
  parameters:nil
     success:^(AFHTTPRequestOperation *operation, id responseObject) {
         NSLog(@" RESPONSE RETURNED %@\n\n", responseObject);

     } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
         NSLog(@"error = %@", error);
     }];
于 2013-12-03T16:11:11.667 に答える
0

ELB で TLS v1.2 が有効になっていない NSURLConnection と Amazon の ELB & EC2 インスタンスに問題があり、15 ～ 50% のリクエストが適切に処理されませんでした (本文に JSON を含む HTTPS PUT)。TLS v1.2 を有効にすることで、この問題は解決しました... この事実の背後にあるロジックを理解しようとして頭をかきむしりました。

于 2014-02-16T22:11:50.007 に答える
0

API の SSL に間違いなく変更がありました

SSL の仕組みについてはよくわかりませんが、MKNetworkKit がkSecTrustResultConfirm (Security-Framework の SecTrust.h にあります)という iOS 7 で廃止された定数を使用していることに気付きました。

@constant kSecTrustResultConfirm 続行する前にユーザーの確認が必要であることを示します。重要: この値は、OS X 10.5 以降、SecTrustEvaluate または SecTrustSettings API によって返されなくなり、サポートされなくなりました。その使用は、OS X 10.9 以降および iOS では推奨されていません。

多分これは正しい方向へのポイントですか？とにかく、頑張って問題を解決してください!

これは、誰かが MKNetworkKit でこれを「修正」したコミット差分です: https://github.com/MugunthKumar/MKNetworkKit/commit/c28959805991bb8f0e99ede9c822e985b41f6fc9 (L:1142 までスクロール)

于 2013-09-26T19:32:14.287 に答える