programing

CFNetwork SSL 핸드셰이크 실패 iOS 9

minimums 2023. 6. 17. 08:56
반응형

CFNetwork SSL 핸드셰이크 실패 iOS 9

iOS 9 베타 1을 사용하는 사람이 이 문제를 일으킨 적이 있습니까?

표준 NSURL Connection을 사용하여 웹 서비스에 연결하고 웹 서비스에 전화가 걸려오자마자 다음 오류가 발생합니다.이것은 현재 iOS 8.3에서 작동하고 있습니다.

베타 버그 가능성?어떤 아이디어나 생각이라도 좋습니다! iOS 9 개발의 매우 초기 단계라는 것을 알고 있습니다.

다음은 전체 오류입니다.

CFNetwork SSL 핸드셰이크 실패(-9824) NSURLSession/NSURL 연결 HTTP 로드 실패(kCFStreamErrorDomain)SSL, -9824)

 NSURLRequest * urlRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://mywebserviceurl"]];
        NSURLResponse * response = nil;
        NSError * error = nil;
        NSData * data = [NSURLConnection sendSynchronousRequest:urlRequest
                                                  returningResponse:&response
                                                              error:&error];

iOS 9 및 OSX 10.11에서는 앱의 Info.plist 파일에 예외 도메인을 지정하지 않는 한 데이터를 요청하려는 모든 호스트에 대해 TLSv1.2 SSL이 필요합니다.

Info.plist 구성의 구문은 다음과 같습니다.

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>yourserver.com</key>
    <dict>
      <!--Include to allow subdomains-->
      <key>NSIncludesSubdomains</key>
      <true/>
      <!--Include to allow insecure HTTP requests-->
      <key>NSExceptionAllowsInsecureHTTPLoads</key>
      <true/>
      <!--Include to specify minimum TLS version-->
      <key>NSExceptionMinimumTLSVersion</key>
      <string>TLSv1.1</string>
    </dict>
  </dict>
</dict>

애플리케이션(예: 타사 웹 브라우저)을 임의 호스트에 연결해야 하는 경우 다음과 같이 구성할 수 있습니다.

<key>NSAppTransportSecurity</key>
<dict>
    <!--Connect to anything (this is probably BAD)-->
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

이 작업을 수행해야 하는 경우 TLSv1.2 및 SSL을 사용하도록 서버를 업데이트하는 것이 가장 좋습니다.이 문제는 일시적인 해결 방법으로 간주해야 합니다.

현재 사전 릴리스 설명서에는 이러한 구성 옵션에 대한 구체적인 언급이 없습니다.확인되면 답변을 업데이트하여 관련 문서로 연결하겠습니다.

iOS 10+에서 TLS 문자열은 "TLSv1.0" 형식이어야 합니다.그냥 "1.0"일 수는 없습니다. (하아)


다음과 같은 다른 답변 조합이 작동합니다.

TLS 1.0만 있는 호스트(YOUR_HOST.COM)에 연결하려고 한다고 가정합니다.

앱의 Info.plist에 추가합니다.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>YOUR_HOST.COM</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSTemporaryExceptionMinimumTLSVersion</key>
            <string>TLSv1.0</string>
            <key>NSTemporaryExceptionRequiresForwardSecrecy</key>
            <false/>
        </dict>
    </dict>
</dict>

iOS 9 OS X 10.11에서 앱 전송 보안 예외 구성에 대한 자세한 내용

이상하게도, 실수로 URL을 잘못 구성한 코드의 실수로부터 보호하기 위해 연결이 http 프로토콜을 https로 변경하려고 시도한다는 것을 알게 될 것입니다.어떤 경우에는, 이것이 실제로 효과가 있을지도 모르지만, 또한 혼란스럽기도 합니다.

앱 전송 보안이 포함된 앱 배송에는 몇 가지 좋은 디버깅 팁이 포함됩니다.

ATS 실패

대부분의 ATS 고장은 -9800 시리즈의 코드와 함께 CFErrors로 표시됩니다.이는 Security/SecureTransport.h 헤더에 정의되어 있습니다.

2015-08-23 06:34:42.700 SelfSignedServerATSTest[3792:683731] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)

CFNETWORK_진단

콘솔에서 장애에 대한 자세한 정보를 얻으려면 환경 변수 CFNETWORK_DIAGNOSTICS를 1로 설정합니다.

nscurl

도구는 여러 가지 ATS 예외 조합을 통해 실행되며, 각 ATS 구성에서 지정된 호스트에 대한 보안 연결을 시도하고 결과를 보고합니다.

nscurl --ats-diagnostics https://example.com

백엔드에서 보안 연결 에이전트를 사용하는 경우 NSURLSession을 사용합니다.

CFNetwork SSLHandshake failed (-9801)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9801)

특히 ATS 버전 및 SSL 인증서 정보를 얻으려면 서버 구성을 확인해야 합니다.

설정을 통해 안전하지 않은 연결만 허용하는 대신NSExceptionAllowsInsecureHTTPLoads = YES대신 서버가 ATS에 대한 최소 요구 사항(v1.2)을 충족하지 못하는 경우(또는 서버 측을 더 잘 수정할 수 있는 경우) 보안 저하를 허용해야 합니다.

단일 서버에 대한 낮은 보안 허용

<key>NSExceptionDomains</key>
<dict>
    <key>api.yourDomaine.com</key>
    <dict>
        <key>NSExceptionMinimumTLSVersion</key>
        <string>TLSv1.0</string>
        <key>NSExceptionRequiresForwardSecrecy</key>
        <false/>
    </dict>
</dict>

openssl 클라이언트를 사용하여 인증서를 조사하고 openssl 클라이언트를 사용하여 서버 구성을 가져옵니다.

openssl s_client  -connect api.yourDomaine.com:port //(you may need to specify port or  to try with https://... or www.)

..마지막에 찾아보세요.

SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: //
    Session-ID-ctx: 
    Master-Key: //
    Key-Arg   : None
    Start Time: 1449693038
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

ATS(App Transport Security)를 사용하려면 TLS(Transport Layer Security) 프로토콜 버전 1.2가 필요합니다.

ATS를 사용한 연결 요구 사항:

ATS(App Transport Security)를 사용하기 위한 웹 서비스 연결 요구 사항에는 다음과 같은 서버, 연결 암호 및 인증서가 포함됩니다.

인증서는 다음 유형의 키 중 하나로 서명해야 합니다.

  • 다이제스트 길이가 256 이상인 SHA-2(Secure Hash Algorithm 2) 키(즉, SHA-256 이상)

  • 최소 256비트 크기의 ECC(Eliptic-Curve Cryptography) 키

  • 길이가 2048비트 이상인 RSA(Rivest-Shamir-Adleman) 키 잘못된 인증서를 사용하면 하드 오류가 발생하고 연결이 없습니다.

다음 연결 암호는 FS(Forward Secrecy)를 지원하며 ATS와 함께 작동합니다.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDSA_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECSHA_ECSHA_ECSHA_ECSHA_ECSHA_256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

업데이트: openssl은 최소한의 프로토콜 버전만 제공하는 것으로 나타났습니다. 프로토콜 : TLSv1 링크

이틀간의 시도와 실패 후에, 저에게 효과가 있었던 것은 이 여성의 코드입니다.

한 번의 변경으로, 게시물에 따르면 우리는 그러한 종류의 컨벤션의 NSExceptionDomains 사전과 관련된 하위 키 사용을 중단해야 합니다.

  NSTemporaryExceptionMinimumTLSVersion

그리고 새로운 컨벤션에서 사용합니다.

  NSExceptionMinimumTLSVersion

대신.

사과 문서

나의 규칙

<key>NSAppTransportSecurity</key>
    <dict>
        <key>NSExceptionDomains</key>
        <dict>
            <key>YOUR_HOST.COM</key>
            <dict>
                <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/>
                <key>NSExceptionMinimumTLSVersion</key>
                <string>TLSv1.0</string>
                <key>NSExceptionRequiresForwardSecrecy</key>
                <false/>
                <key>NSIncludesSubdomains</key>
                <true/>
            </dict>
        </dict>
    </dict>

또 다른 유용한 도구는 nmap(brew install nmap)입니다.

nmap --script ssl-enum-ciphers -p 443 google.com

출력을 제공합니다.

Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-11 17:25 IDT
Nmap scan report for google.com (172.217.23.46)
Host is up (0.061s latency).
Other addresses for google.com (not scanned): 2a00:1450:4009:80a::200e
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 5.48 seconds

이 오류는 버그가 있는 Cordova iOS 버전을 사용할 때 가끔 로그에 표시되었습니다.제가 코르도바 iOS를 업그레이드하거나 다운그레이드 할 때 없어졌습니다.

제가 접속하고 있던 서버가 TLSv1.2 SSL을 사용하고 있어서 문제가 없다는 것을 알았습니다.

프로젝트에서.plist파일에 이 권한 추가:

<key>NSAppTransportSecurity</key>
<dict>
    <!--Connect to anything (this is probably BAD)-->
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

Info.plist 구성의 구문

   <key>NSAppTransportSecurity</key>
   <dict>
   <key>NSExceptionDomains</key>
    <dict>
    <key>yourserver.com</key>
   <dict>
  <!--Include to allow subdomains-->
  <key>NSIncludesSubdomains</key>
  <true/>
  <!--Include to allow insecure HTTP requests-->
  <key>NSExceptionAllowsInsecureHTTPLoads</key>
  <true/>
  <!--Include to specify minimum TLS version-->
  <key>NSExceptionMinimumTLSVersion</key>
  <string>TLSv1.1</string>
   </dict>
 </dict>

업데이트된 답변(WWDC 2016 이후):

iOS 앱은 2016년 말까지 안전한 HTTPS 연결이 필요합니다.ATS를 끄면 나중에 앱이 거부될 수 있습니다.

ATS(App Transport Security)는 Apple이 iOS 9에서 도입한 기능입니다.ATS를 사용하도록 설정하면 응용 프로그램이 비보안 HTTP가 아닌 HTTPS 연결을 통해 웹 서비스에 강제로 연결됩니다.

그러나 개발자는 여전히 ATS를 끄고 위의 답변에서 언급한 대로 자신의 앱이 HTTP 연결을 통해 데이터를 전송하도록 허용할 수 있습니다.2016년 말에, 애플은 앱스토어에 앱을 제출하기를 원하는 모든 개발자들에게 ATS를 의무화할 것입니다.링크

제가 테스트한 장치의 시간 설정이 잘못되었습니다.따라서 인증서가 곧 만료될 페이지에 액세스하려고 하면 장치가 인증서가 만료되었지만 액세스를 거부합니다.수정하려면 장치에서 적절한 시간을 설정하십시오!

언급URL : https://stackoverflow.com/questions/30720813/cfnetwork-sslhandshake-failed-ios-9

반응형