Блог

Главная - Вопросы по программированию - CRL и OCSP поведение iOS / Security.Платформа?

CRL и OCSP поведение iOS / Security.Платформа?

#security #ios #x509certificate #certificate-revocation #ocsp

#Безопасность #iOS #x509сертифицирует #отзыв сертификата #ocsp

Вопрос:

Я пытаюсь выяснить, какова политика iOS при проверке сертификатов с использованием Security.Структура, касающаяся отзыва сертификатов. Я не могу найти информацию об этом в документах для iOS. В контексте проекта iPad, над которым я работаю в данный момент, есть причина потребовать проверки статуса отзыва для некоторых сертификатов. У кого-нибудь есть идеи о том, как принудительно проверять CRL / OCSP во время проверки сертификата с помощью Security.Платформа? Или мне нужно «вернуться» к OpenSSL для достижения этой цели?

Похоже, что также в Mac OS X 10.6 проверки CRL / OCSP выполняются необязательно и должны быть включены вручную через Keychain Access.

Martijn

Ответ №1:

У меня есть ответ на этот вопрос от ребят из Apple, я опубликовал полный ответ здесь:

Подробности о механизмах отзыва сертификатов SSL / TLS в iOS

Подводя итог, есть несколько вещей, которые следует учитывать при реализации OCSP в iOS:

  • В данный момент невозможно настроить политику OCSP
  • это работает только для сертификатов EV
  • высокоуровневые компоненты, такие как NSURLConnection или UIWebView, используют политику безопасности TLS, которая использует OCSP
  • SecTrustEvaluate — это блокирующая сетевая операция
  • это работает как «лучшая попытка» — если не удается связаться с сервером OCSP, оценка доверия не завершится ошибкой

Комментарии:

1. Спасибо, что откопали это. Жаль, что это только для сертификатов EV. У многих известных сайтов (Gmail, Facebook и т.д.) Нет EVS. В любом случае, подобные «незакрепленные концы» заставляют меня сомневаться в ценности PKI и текущей ситуации с полуцентрализованным цифровым «доверием»…

2. Абсолютно согласен — также вызывает беспокойство тот факт, что вся система работает «наилучшим образом» (и, следовательно, оценка не завершается сбоем, когда невозможно достичь серверов OCSP)…

Ответ №2:

Я только что сделал это на iOS в GCDAsyncSocket.

Для заданного доверия SecTrustRef; сделайте это

 SecPolicyRef policy = SecPolicyCreateRevocation(kSecRevocationOCSPMethod)
SecTrustSetPolicies(trust, policy);
SecTrustResultType trustResultType = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, amp;trustResultType);
if (status == errSecSuccess amp;amp; trustResultType == kSecTrustResultProceed)
{
   //good!
}
else
{
   //not good
}

// отредактируйте, чтобы проверить trustResultType

Комментарии:

1. Не является ли этот код ошибочным? SecTrustResultType Следует проверить, чтобы быть kSecTrustResultProceed или kSecTrustResultUnspecified , если я не ошибаюсь. В настоящее время вы просто проверяете, не выдал ли SecTrustEvaluate ошибку

2. @Lukas Вы правы, что я должен проверять trustResultType. Но проверять это следует только в том случае, если статус хороший. Когда я тестировал код с плохими сертификатами или атаками MitM, статус всегда был плохим. Я обновлю пример. Спасибо

Ответ №3:

Мне удалось включить проверку CRL на SecTrustRef объект в iOS 10:

 SecTrustRef trust = ...; // from TLS challenge
CFArrayRef oldPolicies;
SecTrustCopyPolicies(trust, amp;oldPolicies);
SecPolicyRef revocationPolicy = SecPolicyCreateRevocation(kSecRevocationCRLMethod);
NSArray *newPolicies = [(__bridge NSArray *)oldPolicies arrayByAddingObject(__bridge id)revocationPolicy];
CFRelease(oldPolicies);
SecTrustSetPolicies(trust, (__bridge CFArrayRef)newPolicies);
SecTrustSetNetworkFetchAllowed(trust, true);

// Check the trust object
SecTrustResult result = kSecTrustResultInvalid;
SecTrustEvaluate(trust, amp;result);
// cert revoked -> kSecTrustResultRecoverableTrustFailure

Вызов SecTrustSetNetworkFetchAllowed был ключевым. Вместо этого SecTrustEvaluate возвращается kSecTrustResultUnspecified без этого вызова.