Как получить резервный пин-код для закрепления SSL фреймворка TrustKit под iOS?

В настоящее время я реализую инфраструктуру TrustKit в своем приложении для iOS, чтобы включить закрепление SPKI для соединений SSL. Я натыкаюсь на «резервный пин-код», который является обязательным для правильной конфигурации TrustKit. К сожалению, в документации по API только указано, что необходим резервный пин-код, но не сказано, каким он должен быть. Цепочка доверия выглядит так:

GeoTrust Global CA
| GeoTrust SSL CA - G3
   | myServer.com

Поэтому я закрепляю хэш SPKI для сертификата myServer.com в качестве основного вывода. Какой у меня резервный пин-код?

К сожалению, я не нашел много информации по этой теме. Один из немногих ресурсов, которые я нашел, — это эта статья Хьюберта Ле Ван Гонга из PayPal. Он говорит о запасных булавках:

«Независимо от количества значений булавки, резервный пин-код абсолютно необходим. Обратите внимание, что наличие резервного пин-кода является обязательным в HPKP (т. е. для веб-кейса), но не менее важно в мобильном приложении. В обоих случаях пара ключей, соответствующая резервному пин-коду, должна оставаться в автономном режиме до тех пор, пока не возникнет проблема с основным пин-кодом/ключом."

Я особенно не понимаю часть с «следует оставаться в автономном режиме».

По поводу вопроса что прикалывать:

Сертификат корневого ЦС, вероятно, лучше всего. Поэтому при закреплении нескольких значений (например, 2) промежуточный ЦС — корневой ЦС, на мой взгляд, является разумным подходом. Тем не менее, вполне нормально закрепить только один сертификат, если этот сертификат является корневым ЦС.

Из этого я понимаю, что мой резервный контакт может быть корневым ЦС (точнее, это хэш SPKI). Однако мне интересно, как промежуточный или даже корневой ЦС может быть хорошим выводом. Насколько я понимаю, это подтвердит закрепление для каждого сертификата, который имеет этот промежуточный/корневой ЦС в своей цепочке.

Что я здесь не так?


ios nsurlsession pinning
person Pvt. Joker    schedule 20.04.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Вот сообщение в блоге с разделом о резервной булавке: https://noncombatant.org/2015/05/01/about-http-public-key-pinning/

Конкретно:

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

Для вашего приложения вы должны закрепить корневой ЦС текущего сертификата сервера (Глобальный ЦС GeoTrust), а затем купить сертификат у другого ЦС и использовать этот другой ЦС в качестве резервного штифта. Закрепление листового сертификата (myServer.com) требует больше усилий, поскольку ключ этого сертификата будет меняться чаще, чем ключ корня.

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

person Nabla    schedule 20.04.2016

arrow_upward
3
arrow_downward

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

Что я здесь не так?

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

Закрепление сертификатов на листьях (максимальная безопасность)

У вас есть полный контроль и право собственности на все, и никакое внешнее влияние не может скомпрометировать ваш SSL, не ставя под угрозу вашу инфраструктуру. Кроме того, компрометация любого из ваших сертификатов не повлияет на остальные.

Недостатком здесь является то, что для выпуска, аудита, управления и развертывания более чем нескольких десятков сертификатов потребуется много конфиденциальной инфраструктуры. Рассмотрим издателя с 5000 SSL-сертификатов для различных журналов и новостей.

Привязка к промежуточному центру сертификации, которым вы владеете (очень высокий уровень безопасности)

Практически аналогичные преимущества закрепления на листовых сертификатах, за исключением того, что если ваш промежуточный сертификат скомпрометирован, все выданные сертификаты будут скомпрометированы. Это сбалансированный подход для закрепления огромного количества SSL-сертификатов.

Недостатком является то, что получить один из них невероятно дорого.

Закрепить на доверенном корневом ЦС (высокий уровень безопасности)

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

Здесь несколько минусов:

  1. Сотрудники ЦС — в редкие случаи Известно, что сотрудники центра сертификации совершают плохие поступки.
  2. Государственные субъекты. Мы понятия не имеем, смогли ли правительства заставить глобальные органы власти выпустить вредоносные сертификаты. Возможно, даже без их ведома посредством внелегального домашнего шпионажа.

В конце концов, наиболее распространенной стратегией является привязка к 2 или 3 доверенным центрам сертификации. Когда какой-либо ЦС скомпрометирован или сломан, у вас уже есть другие доверенные сертификаты, которые уже выпущены и готовы к работе.

person Adam Kaplan    schedule 07.01.2017
comment
Большое спасибо за этот подробный ответ! Теперь я действительно могу оценить, какой уровень безопасности необходим. - person Pvt. Joker; 09.01.2017