Jak używać NSURLConnection do łączenia się z SSL dla niezaufanego certyfikatu?

Mam następujący prosty kod do połączenia ze stroną SSL

NSMutableURLRequest *urlRequest=[NSMutableURLRequest requestWithURL:url];
[ NSURLConnection sendSynchronousRequest: urlRequest returningResponse: nil error: &error ];

Tyle że daje błąd, jeśli certyfikat jest samopodpisany. Error Domain=NSURLErrorDomain Code=-1202 UserInfo=0xd29930 "untrusted server certificate".Czy istnieje sposób, aby mimo to akceptować połączenia (tak jak w przeglądarce, możesz nacisnąć przycisk akceptuj) lub sposób na ominięcie go?

Obsługiwane jest obsługiwane API! Dodaj coś takiego do swojego NSURLConnectiondelegata:

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
  return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust];
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
  if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust])
    if ([trustedHosts containsObject:challenge.protectionSpace.host])
      [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];

  [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];
}

Pamiętaj, że connection:didReceiveAuthenticationChallenge:może wysłać swoją wiadomość do challenge.sender (znacznie) później, po wyświetleniu użytkownikowi okna dialogowego, jeśli to konieczne itp.

Jeśli nie chcesz (lub nie możesz) korzystać z prywatnych interfejsów API, istnieje biblioteka open source (licencja BSD) o nazwie ASIHTTPRequest, która zapewnia opakowanie wokół niższego poziomu CFNetwork APIs. Niedawno wprowadzono możliwość zezwalania na HTTPS connectionsużywanie certyfikatów z podpisem własnym lub niezaufanymi w -setValidatesSecureCertificate:interfejsie API. Jeśli nie chcesz pobierać całej biblioteki, możesz użyć źródła jako odniesienia do samodzielnego wdrożenia tej samej funkcjonalności.

W idealnym przypadku powinny istnieć tylko dwa scenariusze, w których aplikacja iOS musiałaby zaakceptować niezaufany certyfikat.

Scenariusz A: Masz połączenie ze środowiskiem testowym, które korzysta z certyfikatu z podpisem własnym.

Scenariusz B: Serwer proxy wykonuje HTTPSruch przy użyciu MITM Proxy like Burp Suite, Fiddler, OWASP ZAP, etc.serwera proxy Zwraca certyfikat podpisany przez samopodpisany urząd certyfikacji, aby serwer proxy mógł przechwytywać HTTPSruch.

Hosty produkcyjne nigdy nie powinny używać niezaufanych certyfikatów z oczywistych powodów .

Jeśli potrzebujesz, aby symulator iOS zaakceptował niezaufany certyfikat do celów testowych, zdecydowanie nie należy zmieniać logiki aplikacji, aby wyłączyć wbudowane sprawdzanie poprawności certyfikatu zapewniane przez NSURLConnectioninterfejsy API. Jeśli aplikacja zostanie udostępniona publicznie bez usunięcia tej logiki, będzie podatna na ataki typu man-in-the-middle.

Zalecanym sposobem akceptowania niezaufanych certyfikatów do celów testowych jest zaimportowanie certyfikatu urzędu certyfikacji (CA), który podpisał certyfikat na symulatorze lub urządzeniu z systemem iOS. Napisałem szybki post na blogu, który pokazuje, jak to zrobić, na którym znajduje się symulator iOS:

akceptowanie niezaufanych certyfikatów za pomocą symulatora ios

NSURLRequestma prywatną metodę o nazwie setAllowsAnyHTTPSCertificate:forHost:, która zrobi dokładnie to, co chcesz. Możesz zdefiniować allowsAnyHTTPSCertificateForHost:metodę NSURLRequestza pomocą kategorii i ustawić ją tak, aby zwracała się YESpo hoście, który chcesz zastąpić.

W celu uzupełnienia przyjętej odpowiedzi, dla znacznie większego bezpieczeństwa, możesz dodać swój certyfikat serwera lub własny certyfikat głównego urzędu certyfikacji do pęku kluczy ( https://stackoverflow.com/a/9941559/1432048 ), ale zrobienie tego samemu nie spowoduje NSURLConnection automatycznie uwierzytelnij samopodpisany serwer. Nadal musisz dodać poniższy kod do delegata NSURLConnection, jest on kopiowany z przykładowego kodu Apple AdvancedURLConnections i musisz dodać dwa pliki (Credentials.h, Credentials.m) z przykładowego kodu Apple do swoich projektów.

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust];
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
//        if ([trustedHosts containsObject:challenge.protectionSpace.host])

    OSStatus                err;
    NSURLProtectionSpace *  protectionSpace;
    SecTrustRef             trust;
    SecTrustResultType      trustResult;
    BOOL                    trusted;

    protectionSpace = [challenge protectionSpace];
    assert(protectionSpace != nil);

    trust = [protectionSpace serverTrust];
    assert(trust != NULL);
    err = SecTrustEvaluate(trust, &trustResult);
    trusted = (err == noErr) && ((trustResult == kSecTrustResultProceed) || (trustResult == kSecTrustResultUnspecified));

    // If that fails, apply our certificates as anchors and see if that helps.
    //
    // It's perfectly acceptable to apply all of our certificates to the SecTrust
    // object, and let the SecTrust object sort out the mess.  Of course, this assumes
    // that the user trusts all certificates equally in all situations, which is implicit
    // in our user interface; you could provide a more sophisticated user interface
    // to allow the user to trust certain certificates for certain sites and so on).

    if ( ! trusted ) {
        err = SecTrustSetAnchorCertificates(trust, (CFArrayRef) [Credentials sharedCredentials].certificates);
        if (err == noErr) {
            err = SecTrustEvaluate(trust, &trustResult);
        }
        trusted = (err == noErr) && ((trustResult == kSecTrustResultProceed) || (trustResult == kSecTrustResultUnspecified));
    }
    if(trusted)
        [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
}

[challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];
}

Nie mogę tego przypisać, ale ten, który okazał się bardzo skuteczny dla moich potrzeb. shouldAllowSelfSignedCertjest moją BOOLzmienną. Po prostu dodaj do swojego NSURLConnectiondelegata i powinieneś się rozerwać, aby szybko ominąć połączenie dla każdego połączenia.

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)space {
     if([[space authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) {
          if(shouldAllowSelfSignedCert) {
               return YES; // Self-signed cert will be accepted
          } else {
               return NO;  // Self-signed cert will be rejected
          }
          // Note: it doesn't seem to matter what you return for a proper SSL cert
          //       only self-signed certs
     }
     // If no other authentication is required, return NO for everything else
     // Otherwise maybe YES for NSURLAuthenticationMethodDefault and etc.
     return NO;
}

W iOS 9 połączenia SSL nie będą działać dla wszystkich nieprawidłowych lub samopodpisanych certyfikatów. Jest to domyślne zachowanie nowej funkcji App Transport Security w systemie iOS 9.0 lub nowszym oraz w OS X 10.11 i nowszych.

Możesz zastąpić to zachowanie w Info.plist, ustawiając NSAllowsArbitraryLoadsna YESw NSAppTransportSecuritysłowniku. Zalecam jednak zastąpienie tego ustawienia wyłącznie do celów testowych.

Aby uzyskać więcej informacji, zobacz Technote aplikacji transportu tutaj .

Obejście kategorii opublikowane przez Nathana de Vriesa przejdzie testy prywatnego interfejsu API AppStore i jest przydatne w przypadkach, gdy nie masz kontroli nad NSUrlConnectionobiektem. Jednym z przykładów jest NSXMLParserotwarcie podanego adresu URL, ale nie ujawnienie NSURLRequestlubNSURLConnection .

W iOS 4 obejście nadal wydaje się działać, ale tylko na urządzeniu Symulator nie wywołuje allowsAnyHTTPSCertificateForHost:już tej metody.

Musisz użyć, NSURLConnectionDelegateaby zezwolić na połączenia HTTPS, aw iOS8 pojawiły się nowe połączenia zwrotne.

Przestarzałe:

connection:canAuthenticateAgainstProtectionSpace:
connection:didCancelAuthenticationChallenge:
connection:didReceiveAuthenticationChallenge:

Zamiast tego musisz zadeklarować:

connectionShouldUseCredentialStorage: - Wysłane w celu ustalenia, czy moduł ładujący URL powinien używać magazynu referencji do uwierzytelniania połączenia.

connection:willSendRequestForAuthenticationChallenge: - Mówi delegatowi, że połączenie wyśle ​​żądanie uwierzytelnienia.

Dzięki willSendRequestForAuthenticationChallengemożesz używać challengetak jak w przypadku przestarzałych metod, na przykład:

// Trusting and not trusting connection to host: Self-signed certificate
[challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
[challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];

Zamieściłem trochę kodu gist (na podstawie pracy innej osoby, którą odnotowuję), która pozwala poprawnie uwierzytelnić się na podstawie samodzielnie wygenerowanego certyfikatu (i jak uzyskać bezpłatny certyfikat - patrz komentarze na dole Cocoanetics )

Mój kod jest tutaj github

Jeśli chcesz nadal używać sendSynchronousRequest, pracuję w tym rozwiązaniu:

FailCertificateDelegate *fcd=[[FailCertificateDelegate alloc] init];

NSURLConnection *c=[[NSURLConnection alloc] initWithRequest:request delegate:fcd startImmediately:NO];
[c setDelegateQueue:[[NSOperationQueue alloc] init]];
[c start];    
NSData *d=[fcd getData];

możesz to zobaczyć tutaj: Synchroniczne połączenie SSL celu-C

Dzięki AFNetworking z powodzeniem korzystałem z usługi https z poniższym kodem,

NSString *aStrServerUrl = WS_URL;

// Initialize AFHTTPRequestOperationManager...
AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
manager.requestSerializer = [AFJSONRequestSerializer serializer];
manager.responseSerializer = [AFJSONResponseSerializer serializer];

[manager.requestSerializer setValue:@"application/json" forHTTPHeaderField:@"Content-Type"];
manager.securityPolicy.allowInvalidCertificates = YES; 
[manager POST:aStrServerUrl parameters:parameters success:^(AFHTTPRequestOperation *operation, id responseObject)
{
    successBlock(operation, responseObject);

} failure:^(AFHTTPRequestOperation *operation, NSError *error)
{
    errorBlock(operation, error);
}];

Możesz użyć tego kodu

-(void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
{
     if ([[challenge protectionSpace] authenticationMethod] == NSURLAuthenticationMethodServerTrust)
     {
         [[challenge sender] useCredential:[NSURLCredential credentialForTrust:[[challenge protectionSpace] serverTrust]] forAuthenticationChallenge:challenge];
     }
}

Posługiwać się -connection:willSendRequestForAuthenticationChallenge: zamiast tych przestarzałych metod

Przestarzałe:

-(BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace  
-(void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge 
-(void)connection:(NSURLConnection *)connection didCancelAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge