3

I am very very new to Mobile Apps development and HTTPs. Please bear with me... I need your advice!

My iPhone app communicates with a server over HTTPS with uses Self Signed Certificate.

To fix situation with a warning message that my server is untrusted I used NSURLConnection delegate methods and this approach: 

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

    [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];
}

  1. My first question is this: Will Apple approve this approach? Is it an allowed and legal way of dealing with HTTPs Requests when communicating with a server that uses Self Signed Certificate?

  2. When using the above mentioned approach to give my consent and still connect to an untrusted server, is my data going to be send over HTTPs and will it be encrypted?

RivieraKid
  • 5,923
  • 4
  • 38
  • 47
InterestedDev
  • 578
  • 7
  • 22
  • 1
    1. There is no issue with approach that could result in rejection. – Jitendra Singh Jun 02 '12 at 19:13
  • 2. Anyway, Apple approve and reject whatever they want, so *any* question asking "Will my app doing XXX will be approved in/rejected from the AppStore" are UNANSWERABLE. –  Jun 02 '12 at 20:32

2 Answers2

2

People do this all the time with Apple apps, for better or worse, without app store rejection. However, a safer approach would be to (1) use an officially-signed certificate, or (2) get your app to accept only your self-signed certificate.

Yusuf X
  • 14,513
  • 5
  • 35
  • 47
  • The lack of security with this approach can't be overstated. The traffic will be trivial to intercept via a man-in-the-middle attack (easy enough to do if the user is on public wifi, for example). Note that there are signing authorities which will sign basic certificates for free, and **checking** the server's self-signed certificate to be yours is equally secure. So there's no excuse to use this half-baked insecure approach. – pmdj Jun 02 '12 at 20:33
  • Yusuf, thank you very much for your response! Learning that people do it all the time and Apple does not reject it helps a lot. You've mentioned approach (2) and I am trying to learn now how to make my App accept my own self-signed certificate. For that I downloaded ASIHTTPRequest but cannot figure out how to attach my self-signed certificate to a request. Do you know if there is a step by step tutorial on how to do it? – InterestedDev Jun 02 '12 at 22:01
  • If you're using ASIHTTPRequest, then [this](http://stackoverflow.com/questions/5971391/use-a-self-signed-ssl-certificate-in-an-iphone-app) fellow has an answer. – Yusuf X Jun 03 '12 at 07:30
  • Thank you Yusuf! I tried that one... I extracted identity but it still generates an error when used with ASIHTTPRequest. This same identity when used with NSURLConnection works very well. Strange... Ah well, I will just continue with NSURLConnection. Thank you! – InterestedDev Jun 05 '12 at 18:56
1
  1. There is no issue with approach that could result in rejection.
  2. If the request is POST type then the data will be encrypted. But for more security you can add more encryption to your data if required.
Jitendra Singh
  • 2,103
  • 3
  • 17
  • 26
  • Jitendra, thank you very much for your response. I am using GET method not POST. Please advise me when using (HTTPS)GET and sending data to server via QUERY string will these values not be SSL encrypted? – InterestedDev Jun 02 '12 at 22:04
  • 1
    @Sergey, HTTPS GET query parameters are encrypted, too, but they may be stored in server logs unencrypted. So, this is less of a risk than unencrypted HTTP traffic, but depending on the security of your web server's log, it may be less secure than HTTPS POST – Nate Jun 02 '12 at 22:22