Одобряет ли Apple приложение, которое обменивается данными по HTTPS с помощью самоподписанного сертификата?

Я очень новичок в разработке мобильных приложений и HTTP. Пожалуйста, потерпите меня ... Мне нужен ваш совет!

Приложение для iPhone обменивается данными с сервером по протоколу HTTPS и использует самоподписанный сертификат.

Чтобы исправить ситуацию с предупреждением о том, что мой сервер не является доверенным, я использовал методы делегата NSURLConnection и такой подход:

- (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. Мой первый вопрос: одобрит ли Apple такой подход? Это разрешенный и законный способ работы с HTTP-запросами при взаимодействии с сервером, использующим самоподписанный сертификат?

  2. При использовании вышеупомянутого подхода, чтобы дать свое согласие и по-прежнему подключаться к ненадежному серверу, будут ли мои данные отправляться через HTTP и будут ли они зашифрованы?


person Simplyi    schedule 02.06.2012    source источник
comment
1. Нет проблем с подходом, которые могли бы привести к отказу.   -  person Jitendra Singh    schedule 02.06.2012
comment
2. Как бы то ни было, Apple одобряет и отклоняет все, что они хотят, поэтому любые вопросы о том, будет ли мое приложение, выполняющее XXX, будет одобрено / отклонено в AppStore, НЕОБХОДИМЫ.   -  person    schedule 03.06.2012


Ответы (2)


Люди делают это все время с приложениями Apple, к лучшему или к худшему, без отказа магазина приложений. Однако более безопасным подходом было бы (1) использовать официально подписанный сертификат или (2) заставить ваше приложение принимать только ваш самозаверяющий сертификат.

person Yusuf X    schedule 02.06.2012
comment
Недостаток безопасности при таком подходе невозможно переоценить. Перехватить трафик с помощью атаки типа «злоумышленник посередине» будет несложно (это достаточно просто сделать, например, если пользователь находится в общедоступном Wi-Fi). Обратите внимание, что существуют органы подписи, которые бесплатно подписывают базовые сертификаты, и проверка самозаверяющего сертификата сервера на принадлежность вам также безопасна. Так что нет оправдания использованию этого небезопасного полусырого подхода. - person pmdj; 03.06.2012
comment
Юсуф, большое спасибо за ответ! Очень помогает знание того, что люди делают это все время, и Apple не отказывается от этого. Вы упомянули подход (2), и теперь я пытаюсь узнать, как заставить мое приложение принимать мой собственный самозаверяющий сертификат. Для этого я скачал ASIHTTPRequest, но не могу понять, как прикрепить свой самозаверяющий сертификат к запросу. Вы знаете, есть ли пошаговое руководство, как это сделать? - person Simplyi; 03.06.2012
comment
Если вы используете ASIHTTPRequest, тогда это У товарища есть ответ. - person Yusuf X; 03.06.2012
comment
Спасибо, Юсуф! Я пробовал это ... Я извлек идентификатор, но он все еще генерирует ошибку при использовании с ASIHTTPRequest. Этот же идентификатор при использовании с NSURLConnection работает очень хорошо. Странно ... Ну ладно, я просто продолжу NSURLConnection. Спасибо! - person Simplyi; 05.06.2012

  1. Нет проблем с подходом, которые могли бы привести к отказу.
  2. Если запрос типа POST, данные будут зашифрованы. Но для большей безопасности вы можете добавить больше шифрования к своим данным, если это необходимо.
person Jitendra Singh    schedule 02.06.2012
comment
Джитендра, большое спасибо за ответ. Я использую метод GET, а не POST. Сообщите, пожалуйста, при использовании (HTTPS) GET и отправке данных на сервер через строку QUERY, будут ли эти значения зашифрованы SSL? - person Simplyi; 03.06.2012
comment
@Sergey, параметры запроса HTTPS GET тоже зашифрованы, но могут храниться в журналах сервера в незашифрованном виде. Таким образом, это меньший риск, чем незашифрованный HTTP-трафик, но в зависимости от безопасности журнала вашего веб-сервера он может быть менее безопасным, чем HTTPS POST. - person Nate; 03.06.2012