Гарантии безопасности TLS

HTTPS определяется RFC 2818, но по большей части он состоит из простого состава двух существующих протоколов:

• HTTP (как определено протоколом передачи гипертекста RFC 2616 - HTTP/1.1 и другие)

• TLS (как определено RFC 5246 Версия протокола 1.2 Transport Layer Security (TLS) и другие), или более старый протокол SSL

HTTPS наследовал его гарантии безопасности от TLS. По умолчанию это:

• на-проводном конфиденциальность — Это гарантирует, что данные безопасны от пассивного атакующего (кто-то, кто видит, но не может изменить пакеты, которыми обмениваются между клиентом и сервером).

• аутентификация «клиент аутентифицирует сервер» — Это защищает клиент от активного атакующего (кто-то, кто может и видеть и изменить пакеты, которыми обмениваются между клиентом и сервером). Самое главное это защищает клиент от различных форм атаки «человек посередине», включая серверы самозванца (серверы, кто симулирует быть реальным сервером и таким образом получать конфиденциальную информацию от клиента).

Оценка доверия сервера TLS является частью TLS, что аутентификация реализаций «клиент аутентифицирует сервер». При отключении его Вы теряете эту вторую, чрезвычайно важную гарантию безопасности.

Разрешение отказов оценки доверия сервера

Если отключение оценки доверия сервера полностью является ошибкой, что необходимо сделать? Ваш первый шаг должен быть должен диагностировать проблему. Чтобы сделать это, считайте Отказы Оценки Доверия Сервера Понимания. Как только Вы понимаете проблему, Вы, вероятно, найдете, что самое простое решение состоит в том, чтобы фиксировать сервер. Это сокращает объем кода, который необходимо записать, и гарантирует безопасность пользователя.

Если не будет возможно фиксировать сервер, то необходимо будет настроить оценку доверия сервера, чтобы позволить соединению продолжаться, полностью не подрывая безопасность пользователя. Основная Доверительная Настройка объясняет общий процесс для настройки оценки доверия сервера; это сопровождается Доверительной Настройкой для Определенного APIs, объясняющего процесс для различного обычно используемого APIs. Наконец, Разрешение Определенных Отказов Оценки Доверия Сервера является обсуждением того, как работать вокруг определенных проблем оценки доверия сервера.

Можно также настроить оценку доверия сервера по противоположной причине, т.е. для создания соединения более безопасным. Посмотрите Осуществляющую Более строгую Оценку Доверия Сервера для обсуждения этого.

Доверительные основные принципы оценки

Оценка доверия сервера TLS состоит из двух основных шагов:

1. основной сертификат X.509 доверяет оценке

2. Специфичные для TLS дополнения

Для понимания первого шага необходимо знать немного о сертификатах X.509. Сертификат X.509 имеет пять критических атрибутов:

• информация о предмете

• информация об эмитенте

• информация о самом сертификате (например, допустимый диапазон дат, который является диапазоном дат, для которых сертификат допустим),

• открытый ключ

• цифровая подпись

Если цифровая подпись допустима тогда, сертификат является гарантией от эмитента, что предмет удерживает закрытую клавишу, связанную с открытым ключом в сертификате. Например, сертификат для DevForums (https://devforums.apple.com/) (во время записи) выпущен, Поручают, и путем подписания того сертификата Поручают, гарантирует, что специалисты по обслуживанию сервера DevForums удерживают закрытую клавишу, связанную с открытым ключом в сертификате.

Оценка доверия сертификата X.509 является рекурсивным двухступенчатым процессом:

1. проверьте законность самого сертификата — Это включает различные вещи, но самые важные два являются a), заверяющим цифровую подпись и b), проверяющий, что проверять дата (обычно текущая дата) в допустимом диапазоне дат сертификата.

2. проверьте законность эмитента — Это включает нахождение сертификата эмитента и (рекурсивно) проверку его законности.

Ясно этот рекурсивный процесс должен завершиться в конечном счете. Доверительная оценка может преуспеть только в одном случае: если это поражает доверяемую привязку. Доверяемая привязка является сертификатом, которому система слепо доверяет, обычно потому что это - корневой сертификат об известном центре сертификации, испекшемся в к системе.

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

• если это поражает недопустимый сертификат

• если это не может найти сертификат для эмитента

• если это поражает самоподписанный сертификат, который не является доверяемой привязкой

Если оценка доверия X.509 успешна, система тогда применяет дополнительные специфичные для TLS проверки. На практике это включает проверку, что имя DNS, что Вы пытаетесь подключить к соответствиям имя DNS в сертификате. Существуют, однако, несколько морщин:

• Обычно Вы ожидали бы находить это имя DNS в поле Common Name предмета, но это может также быть в Подчиненном Альтернативном расширении Имени. Если имя присутствует в Подчиненном Альтернативном расширении Имени, оно берет приоритет над Общим названием.

• Подчиненное Альтернативное расширение Имени может также содержать IP-адреса, с которыми консультируется клиент, если оно соединилось через IP-адрес, а не имя DNS.

• Имя DNS в сертификате могло бы быть подстановочным именем, например, «*.apple.com».

• Расширенное Ключевое расширение Использования, как ожидают, будет включать значение Аутентификации сервера.

Если Вы интересуетесь подробными данными этих специфичных для TLS проверок, посмотрите RFC 2818.

Общие отказы

С вышеупомянутым в памяти, просто понять различные отказы оценки доверия сервера, которые Вы, вероятно, будете видеть. Они включают:

• недостающий сертификат эмитента — Для любого данного сертификата (кроме доверяемой привязки), система должна быть в состоянии определить местоположение сертификата об эмитенте.

• проблемы даты — Для любого данного сертификата, проверять дата должна быть в допустимом диапазоне дат сертификата.

• самоподписанный сертификат — Для любого данного сертификата, если сертификат самоподписывается, он заставит оценку перестать работать (если это не будет доверяемая привязка).

• никакая доверяемая привязка — система должна быть в состоянии следовать за путем сертификатов эмитента, приводящих к доверяемой привязке.

• DNS называет несоответствие — имя DNS, с которым Вы пытаетесь соединиться, должен соответствовать имя в сертификате сервера, как описано в предыдущем разделе.

Если, после исследования каждой из точек выше, Вы все еще не можете разработать, почему оценка доверия сервера перестала работать, Вы могли бы хотеть попробовать метод, описанный в Исследовании Твердых к отладке Доверительных Отказов Оценки.

Средства отладки

Существует множество инструментов, которые можно использовать для отладки проблем оценки доверия сервера, и этот раздел обсуждает некоторые более общие.

$ openssl s_client -connect www.apple.com:443

CONNECTED(00000003)

[...]

GET / HTTP/1.1

Host: www.apple.com

HTTP/1.1 200 OK

Server: Apache/2.2.3 (Oracle)

Content-Length: 9464

Content-Type: text/html; charset=UTF-8

ntCoent-Length: 9516

Cache-Control: max-age=47

Expires: Mon, 25 Jun 2012 16:18:24 GMT

Date: Mon, 25 Jun 2012 16:17:37 GMT

Connection: keep-alive

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">

[...]

</html>

closed

$

$ openssl s_client -showcerts -host www.apple.com -port 443

[...]

---

Certificate chain

 0 s:/C=US/L=Cupertino/O=Apple Inc./ST=CALIFORNIA/CN=www.apple.com

   i:/C=US/O=Akamai Technologies Inc/CN=Akamai Subordinate CA 3

-----BEGIN CERTIFICATE-----

MIIDJzCCApCgAwIBAgIOAQAAAAABNwl6mQWT01EwDQYJKoZIhvcNAQEFBQAwUTEL

MAkGA1UEBhMCVVMxIDAeBgNVBAoTF0FrYW1haSBUZWNobm9sb2dpZXMgSW5jMSAw

HgYDVQQDExdBa2FtYWkgU3Vib3JkaW5hdGUgQ0EgMzAeFw0xMjA1MDExNzUzNDNa

Fw0xMzA1MDExNzUzNDNaMGMxCzAJBgNVBAYTAlVTMRIwEAYDVQQHEwlDdXBlcnRp

bm8xEzARBgNVBAoTCkFwcGxlIEluYy4xEzARBgNVBAgTCkNBTElGT1JOSUExFjAU

BgNVBAMTDXd3dy5hcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK

AoIBAQCdJlExG8umAtxL9Df/10diaYoqFeeVDbU13cH0KNxq2vV0nSb3dROtUAig

/wXj6jFU16fhfFegjcYBkYL9qiUkIiROMNo9r1IzZX4Yv9HT30vBdRMZkuIdy9eP

m9nctNVYyBGRJapem1c+llxAJzToiuQofBY6L6K2dO7nuGm7AZ/PwcbyxZEWoh0E

2SKMbMD9vG0Dph+rZDcPxENFa401j95ZiyyDinHXPliPVGimQmLeaWXMOhJSGXcd

FidodxJCGPUIMuQnxipIH8EAiOg76aKsFvi/7ctoYtRGsXJZqRLnKJ2JVAq+tQxj

6so8vaO5I5wqjyCa+ECJJ0i8Vhp/AgMBAAGjbDBqMDkGA1UdHwQyMDAwLqAsoCqG

KGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvQWthbWFpU3ViMy5jcmwwHQYDVR0O

BBYEFK5QfqCwo5h4aWa7DmhIJdMZ50FjMA4GA1UdDwEB/wQEAwIFIDANBgkqhkiG

9w0BAQUFAAOBgQCMfDikw5AwrCCCkhcb+ak5oTRmhV88mL5Pk7SzVTbMdCoaktOD

+Bu7iX0OYsISOjYu0x2CzX2VQ5kP5NhA7fqXOiq4iG1G/Ae+xW01lUB1gJ7VUwoX

9LabdT6c812EOMpza4lrnLqnOsiSCDf1SWv0Lo+pMkZ9Ka9EbSd3DqUEHw==

-----END CERTIFICATE-----

 1 s:/C=US/O=Akamai Technologies Inc/CN=Akamai Subordinate CA 3

   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root

-----BEGIN CERTIFICATE-----

MIIDxzCCAzCgAwIBAgIEBAAEAzANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJV

[...]

bZ14M6VWhKYouKEZnaAsSCe+XHsF0haUfOnxpj4p7CZj/DnGZVB8Uh92ORa0lyY5

q44d/bV6wDodO38=

-----END CERTIFICATE-----

---

[...]

Веб-представление

Веб-представление OS X предоставляет Вам доступ к запросам аутентификации NSURLConnection через resourceLoadDelegate свойство. Можно реагировать на запросы аутентификации таким же образом, что Вы были бы с NSURLConnection. Увы, это не возможно к доступу NSURLAuthenticationMethodServerTrust запросы аутентификации через этот механизм (r. 9475067). Можно работать вокруг этого ограничения с помощью подкласса NSURLProtocol, как проиллюстрировано Примером кода 'CustomHTTPProtocol'.

UIWebView

UIWebView не обеспечивает пути к приложению для настройки его оценок доверия сервера HTTPS (r. 10131336). Можно работать вокруг этого ограничения с помощью подкласса NSURLProtocol, как проиллюстрировано Примером кода 'CustomHTTPProtocol'.

HTTP живая потоковая передача

HTTP поддержка Живой Потоковой передачи оценки доверия сервера зависит от типа выбираемого ресурса, как показано в Таблице 1.

Для получения общей информации о HTTP Живая Потоковая передача, посмотрите, что HTTP Живет, Передавая Обзор потоком. Для определенной информации о том, как заставить HTTP Живая Потоковая передача вызывать Ваш код для выборки ключей — в которой точке можно использовать любой метод, Вы хотите получить доступ к ним, включая NSURLSession со специализированной оценкой доверия сервера HTTPS — наблюдают Сеанс 2011 года WWDC 408 HTTP Живое Обновление Потоковой передачи.

Кроме того, Основа AV позволяет Вам реализовывать свою собственную загрузку ресурса, при которой точке можно использовать любую сеть API, чтобы загрузить эти ресурсы (и таким образом настроить оценку доверия сервера HTTPS с помощью того API). В частности можно установить загрузчик ресурса (AVAssetResourceLoader) на активе (AVAsset) и затем использовать его делегата для переопределения загрузки ресурсов неучастка среды (см. Таблицу 1). Поддержка этого метода была представлена в iOS 6.0 и OS X 10.9.

NSURLSession

NSURLSession позволяет Вам настраивать оценку доверия сервера HTTPS путем реализации -URLSession:didReceiveChallenge:completionHandler: метод делегата. Для настройки оценки доверия сервера HTTPS ищите проблему, пространство защиты которой имеет метод аутентификации NSURLAuthenticationMethodServerTrust. Для тех проблем разрешите их, как описано ниже. Для других проблем те, что Вы не заботитесь о, вызывают блок обработчика завершения с NSURLSessionAuthChallengePerformDefaultHandling расположение и учетные данные NULL.

При контакте с NSURLAuthenticationMethodServerTrust запрос аутентификации, можно получить доверительный объект от пространства защиты проблемы путем вызова -serverTrust метод. После использования доверительного объекта сделать Ваш собственный сервер HTTPS доверяет оценке, необходимо разрешить проблему одним из двух способов:

• Если Вы хотите отклонить соединение, вызовите блок обработчика завершения с NSURLSessionAuthChallengeCancelAuthenticationChallenge расположение и учетные данные NULL.

• Если Вы хотите позволить соединение, создайте учетные данные из своего доверительного объекта (использование +[NSURLCredential credentialForTrust:]) и вызовите блок обработчика завершения с теми учетными данными и NSURLSessionAuthChallengeUseCredential расположение.

NSURLConnection

NSURLConnection позволяет Вам настраивать оценку доверия сервера HTTPS почти таким же способом как NSURLSession. Существует два существенных различий:

• Вы реализуете различный метод делегата (в этом случае -connection:willSendRequestForAuthenticationChallenge:).

• При разрешении проблемы необходимо получить отправителя от проблемы (через -sender метод), и затем вызывают надлежащий метод на том отправителе:

  • для проблем, о которых Вы не заботитесь, вызвать -performDefaultHandlingForAuthenticationChallenge:

  • если Вы хотите отклонить соединение, вызвать -cancelAuthenticationChallenge:

  • если Вы хотите позволить соединение, вызвать -useCredential:forAuthenticationChallenge:, передача в учетных данных, создаваемых с доверительным объектом, как описано в NSURLSession

CFHTTPStream

Можно настроить оценку доверия сервера HTTPS для CFHTTPStream таким же образом, Вы делаете для CFSocketStream (см. следующий раздел). Существует, однако, один серьезный глюк: к тому времени, когда Вы имеете возможность приводить доверительный объект в порядок применить Вашу пользовательскую доверительную оценку, CFHTTPStream уже отправил Ваш Запрос HTTP в сервер. Таким образом, если Запрос HTTP является потенциально конфиденциальным, этот метод не является надлежащим. В этом случае необходимо или повысить уровень, и использовать NSURLSession, или вниз уровень, и использовать CFSocketStream непосредственно.

CFSocketStream

Для настройки сервера TLS доверяют оценке для CFSocketStream, необходимо сделать следующее:

1. используйте kCFStreamSSLValidatesCertificateChain запись kCFStreamPropertySSLSettings свойство для отключения сервера доверяет оценке полностью

2. как только поток соединился, но прежде чем Вы будете отправлять любые данные или будете доверять любым данным, Вы получаете, получаете доверительный объект от потока через kCFStreamPropertySSLPeerTrust свойство

3. используйте, которые доверяют объект реализовать безотносительно пользовательской оценки доверия сервера, которой Вы желаете

4. или продолжите соединение или закройте его, в зависимости от своей оценки доверия сервера

Основной глюк здесь имеет отношение к шагу 2: когда соединяется поток? Оказывается, что доверительный объект не доступен в то время, когда Вы получаете поток открыто завершенное событие. Чтобы гарантировать, что доверительный объект доступен, необходимо ожидать, имеет пространство, доступное событие или имеет байты доступное событие. Посмотрите Таблицу 2 для подробных данных.

Безопасный транспорт

Безопасный Транспорт является самым низким уровнем реализация TLS и на OS X и на iOS и, как Вы могли бы ожидать, это имеет хорошую поддержку пользовательской оценки доверия сервера TLS. Процедура следующие:

1. прежде, чем запустить соединение, вызвать SSLSetSessionOption установить kSSLSessionOptionBreakOnServerAuth

2. при необходимости, как обсуждено ниже, вызов SSLSetEnableCertVerify для отключения сервера по умолчанию доверяют оценке

3. выполните Безопасное Транспортное квитирование согласно обычному

4. когда SSLHandshake возвраты errSSLServerAuthCompleted, вызвать SSLCopyPeerTrust получить доверительный объект для соединения

5. используйте, которые доверяют объект реализовать безотносительно пользовательской оценки доверия сервера, которой Вы желаете

6. или продолжайте Безопасное Транспортное квитирование или закройте соединение

Отказы имени сервера

Если сервер доверяет сбоям оценки, потому что имя DNS сервера не соответствует имя DNS в сертификате, можно работать вокруг отказа путем переопределения имени DNS в доверительном объекте. Чтобы сделать это, вызвать SecPolicyCreateSSL создать новый объект политики с корректным именем сервера и затем вызвать SecTrustSetPolicies применять его к доверительному объекту.

Недостающие промежуточные сертификаты

Существует много способов, которыми можно разрешить отказ оценки доверия сервера, вызванный недостающим промежуточным сертификатом:

• Лучший подход, как всегда, для фиксации сервера. TLS требует, чтобы сервер предоставил клиенту все продвижение сертификатов от сертификата сервера до доверяемого сертификата привязки, включая любые промежуточные сертификаты (см. Раздел 7.4.2 из RFC 5246). Во многих случаях отсутствие промежуточного сертификата является просто незначительным контролем, который может быстро исправить администратор сервера.

• На OS X, если Ваша программа (или пользователь) добавляет промежуточный сертификат какой-либо цепочке для ключей в списке поиска цепочки для ключей, доверительный объект будет использовать его автоматически.

• На iOS, если Ваше приложение добавляет промежуточный сертификат своей цепочке для ключей, доверительный объект будет использовать его автоматически.

• Если все остальное перестало работать, Ваша программа может получить промежуточный сертификат (свяжите его программой или загрузите его с Интернета), и затем создайте новый доверительный объект, включающий объединение сертификатов от существующего доверительного объекта и Вашего дополнительного промежуточного сертификата. См. Перечисление 5 для примера этого.

Доверие одному определенному сертификату

В некоторых случаях полезно обработать сертификат как простой маркер идентификационных данных. Например, в одноранговой программе, оценка доверия X.509 бессмысленна, потому что нет никакой центральной власти к свидетельствам о выпуске. Однако можно все еще использовать TLS для безопасной передачи в той архитектуре. Процедура следующие:

1. получите копию сертификата удаленного узла через доверяемый канал Вашей собственной разработки; у Вас мог быть удаленный пользователь, посылают Вам по электронной почте их сертификат, помещают его на карту с интерфейсом USB, или безотносительно

2. доберитесь сертификат сервера от доверительного объекта (передайте индекс 0 к SecTrustGetCertificateAtIndex)

3. получите данные для того сертификата сервера (SecCertificateCopyData)

4. сравните это с данными сертификата, Вы вошли в шаг 1; если они соответствуют, Вы говорите с корректной коллегой

Пользовательский центр сертификации

Если сертификат Вашего сервера выпущен центром сертификации, которому не доверяет система по умолчанию, можно разрешить получающийся отказ оценки доверия сервера включением корневого сертификата центра сертификации в программе. Процедура следующие:

1. включайте копию корневого сертификата центра сертификации в Вашей программе

2. как только Вы имеете доверительный объект, создаете объект сертификата из данных сертификата (SecCertificateCreateWithData) и затем набор, что сертификат как доверяемая привязка для доверительного объекта (SecTrustSetAnchorCertificates)

3. SecTrustSetAnchorCertificates устанавливает флаг, препятствующий доверительному объекту доверять любым другим привязкам; если Вы также хотите доверять системным привязкам по умолчанию, вызвать SecTrustSetAnchorCertificatesOnly очистить тот флаг

4. оцените доверительный объект согласно обычному

Самоподписанные сертификаты

Контакт с самоподписанными сертификатами проблематичен, потому что существует множество различных причин, почему люди используют самоподписанный сертификат. Этот раздел покрывает наиболее распространенные случаи.

Доверительные исключения

Объем этого technote предполагает, что Вы пытаетесь разрешить, что сервер доверяет отказу оценки определенный сервер. Но что происходит, если Вы создаете приложение общего назначения, то, которое может соединиться с большим разнообразием серверов? Каноническим примером этого является веб-браузер, но там многие другие (почтовые программы, RSS-ридеры, и т.д.). В этом случае Вы не можете применить определенное решение; Вам нужно решение, работающее в целом.

Лучший подход общего назначения ничего не должен делать. Оценка доверия сервера по умолчанию имеет два критических преимущества:

• просто реализовать

• это безопасно

Последняя точка критически важна: если будет отказ оценки доверия сервера, и Вы предоставляете пользователю способ обойти безопасность, то пользователь будет почти всегда выбирать любую опцию, работающую, независимо от того насколько небезопасный это. С точки зрения безопасности лучше просто привести к сбою, и затем иметь пользовательское давление администратор сервера в фиксацию их сервера.

Если Вы принимаете решение проигнорировать это уведомление (и Вы не будете одними; много популярных приложений общего назначения дарят пользователю вопросы о безопасности, несмотря на то, что у них нет навыков для ответа обоснованно), можно все еще предпринять шаги для минимизации риска.

Общая стратегия здесь:

1. попытайтесь соединиться с сервером

2. если это перестало работать с отказом оценки доверия сервера, сообщите пользователю о проблеме (см. Сертификаты Отображения и Отображение Доверительных Результатов для подробных данных),

3. если пользователь решает соединиться так или иначе, помните, что решение и продолжает соединение

4. позже, если Вы встречаетесь с тем же отказом оценки доверия сервера, игнорируете проблему и подключение так или иначе

Хитрая часть является шагом 4. Как можно сказать, что это - тот же отказ? Если Вы понимаете это превратно, Вы рискуете ставить под угрозу безопасность пользователя выше и вне того, на что они согласились. Рассмотрите следующую последовательность:

1. пользователь соединяется с сервером с сертификатом с истекшим сроком

2. Ваша программа обнаруживает это и просит, чтобы пользователь подтвердил, что они действительно хотят соединиться

3. пользователь соглашается, таким образом, Ваша программа помнит что решение и подключения к серверу

4. позже пользователь перемещается во враждебную сеть, та, включающая активного атакующего, реализующего сервер самозванца; они идут для соединения с сервером снова

5. Ваша программа соединяется с сервером самозванца; это обнаруживает отказ оценки доверия сервера, который хорош, но это видит, что пользователь согласился соединиться с сервером несмотря на такие проблемы и подключениями так или иначе

Проблема здесь состоит в том, что Ваша программа теперь соединилась с сервером самозванца, даже при том, что пользователь только согласился проигнорировать сертификат с истекшим сроком.

Можно решить эту проблему с помощью доверительных исключений. Когда пользователь соглашается соединиться с сервером, Ваша программа может попросить у доверительного объекта доверительного исключения (SecTrustCopyExceptions). Это записывает информацию, необходимую для обхождения текущего доверительного отказа оценки. В будущем, когда Ваша программа видит доверительный отказ оценки для того же сервера, она может применить исключение к доверительному объекту (SecTrustSetExceptions). Если это разрешает отказ оценки доверия сервера, он может безопасно продолжить соединение. В противном случае это должно попросить, чтобы пользователь согласился на дополнительное доверительное исключение.

SecTrustEvaluate может блокировать

Существует две ситуации где SecTrustEvaluate возможно, должен получить доступ к сети для завершения ее задания:

• при загрузке промежуточных сертификатов

• при определении, был ли сертификат отменен (через OCSP или CRL)

Эти сетевые операции имеют относительно короткие тайм-ауты, но они все еще делают SecTrustEvaluate неподходящий для использования на основном потоке, особенно на iOS. Если необходимо вызвать SecTrustEvaluate от основного потока у Вас есть три опции:

• можно использовать SecTrustEvaluateAsync (представленный в OS X 10.7 и iOS 7.0)

• можно использовать SecTrustSetNetworkFetchAllowed отключить доступ к сети для Вашего доверительного объекта (представленный в OS X 10.9 и iOS 7.0)

• можно использовать примитивный параллелизм (например, GCD, NSOperation или поток) для выполнения SecTrustEvaluate на вторичном потоке

Исследование трудно к отладке доверяет отказам оценки

Иногда трудно разработать точно, почему доверительная оценка перестала работать. Ваш первый шаг должен всегда быть должен работать через точки, описанные в Общих отказах. Если Вы все еще не можете выяснить проблему, существует еще несколько приемов, которые можно попробовать:

• распечатайте результат SecTrustCopyResult

• распечатайте результат SecTrustCopyProperties

• исследуйте доверительные данные исключения (как возвращено SecTrustCopyExceptions)

Первым двум точкам не нужно никакое дальнейшее объяснение. Последняя точка немного хитра. Если Вы посмотрите в данных, то Вы будете видеть, что это - фактически двоичный список свойств. Если Вы сохраняете данные к файлу с .plist расширение и затем открывает его с XCode (или Ваш любимый редактор списка свойств), можно найти полезные подсказки относительно того, почему доверительная оценка перестала работать.

Отображение сертификатов

При некоторых обстоятельствах может быть полезно вывести на экран сертификаты пользователю. Например, опытный пользователь мог бы хотеть вручную подтвердить идентификационные данные сервера, с которым связывается Ваше приложение. OS X имеет высокоуровневый APIs для этого:

• SFCertificateView является подклассом NSView, выводящим на экран сертификат

• SFCertificatePanel является панелью, выводящей на экран один или несколько сертификатов; это может использоваться независимо или в качестве листа

В целом необходимо использовать этот высокоуровневый APIs, но, если Вы хотите вывести на экран свой собственный пользовательский интерфейс, можно использовать низкоуровневый APIs (в частности, SecCertificateCopyValues) извлечь подробные данные из сертификата и создать Ваш собственный UI из этого.

iOS не имеет высокоуровневого API для отображения сертификатов. Если Вы хотите сделать это, необходимо будет создать собственный пользовательский интерфейс. Выполнение, которое нетривиально, потому что iOS только ограничил APIs для того, чтобы получить информацию из сертификата (r. 11004183); фактически, единственная вещь, которую можно сделать, получают видимое пользователем имя для сертификата путем вызова SecCertificateCopySubjectSummary. Кроме того, Вам будет нужен Ваш собственный код для парсинга сертификата.

Отображение доверительных результатов

Уведомление, данное всюду по этому документу, состоит в том, что Вы не должны задавать пользовательские вопросы безопасности, на которые они не квалифицированы для ответа. При игнорировании того уведомления тогда, Вы, вероятно, захотите способ вывести на экран результаты неработающего, доверяют оценку пользователю. OS X имеет высокоуровневый API для этого, SFCertificateTrustPanel.

На iOS нет никакого эквивалентного высокоуровневого API, но обе платформы позволяют Вам получать подробную информацию о доверительных отказах оценки. Можно вызвать SecTrustCopyResult, который возвращает информацию о полной доверительной оценке, и SecTrustCopyProperties, который возвращает информацию о каждом сертификате в продвижении пути от сертификата сервера до доверяемой привязки. Можно использовать эту информацию для заполнения собственных доверительных результатов UI.