Если мобильное приложение прикрепляет сертификат корневого удостоверяющего центра сервера и проверяет его имя хоста, возможна ли атака через DNS-мен poisoning?

У меня есть несколько вопросов о пиннинге сертификатов.

Предположим, что мобильное приложение пинит только корневой ЦС, тогда злоумышленник должен иметь возможность каким-то образом перенаправить жертву на вредоносный сайт с тем же корневым ЦС. Я не прав?

• Что происходит, если приложение пинит корневой ЦС, но проверяет имя хоста сервера, к которому подключается приложение?
• Если злоумышленник владеет веб-сайтом под тем же корневым ЦС, может ли он отравить кэш DNS и позволить приложению подключиться к его веб-сайту или существуют ли механизмы безопасности, которые предотвращают такое поведение?

… злоумышленник должен иметь возможность каким-то образом перенаправить жертву на вредоносный сайт с тем же корневым ЦС.

Это будет возможно только если клиент слепо верит любому сертификату, подписанному этим ЦС. Этот уровень доверия, конечно, не должен быть установлен, если корневой ЦС может также выдавать сертификаты злоумышленнику, как это происходит с общими публичными ЦС. Вот почему TLS-клиент должен проверять, соответствует ли субъект сертификата ожиданиям, т.е. если указанный целевой домен или IP адрес покрывается сертификатом.

… пинит корневой ЦС, но проверяет имя хоста сервера, к которому подключается приложение

Это то, что должно делать правильно написанное приложение.

Если злоумышленник владеет веб-сайтом под тем же корневым ЦС, может ли он отравить кэш DNS и позволить приложению подключиться к его веб-сайту или существуют ли механизмы безопасности, которые предотвращают такое поведение?

Клиент должен проверять субъект сертификата с предназначенным именем хоста или IP. Хотя поиск DNS домена может привести к получению алиаса (CNAME), это не изменит предназначенное имя хоста, а лишь является внутренним шагом к получению IP-адреса. Это означает, что отравление DNS против клиента не может быть использовано для изменения предназначенного домена, и, следовательно, злоумышленнику нужно получить сертификат для предназначенного домена — что ЦС не должен выдавать, поскольку злоумышленник не может доказать, что ему он принадлежит.

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

Нет, при условии, что пиннинг реализован правильно

Пиннинг (по крайней мере, пиннинг, отличный от самого сертификата или публичного ключа[1]) должен быть в дополнение к стандартной проверке сертификатов. Стандартная проверка сертификатов (в частности, для TLS) состоит из следующих шагов:

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

Дополнительные шаги, которые следует предпринять, но которые некоторые клиенты пропускают (по более или менее уважительным причинам):

• Проверить, что использование сертификата корректно (существуют несколько уровней такой проверки, в зависимости от используемых расширений)
• Проверить, что сертификат не отозван (проверяя CRL ЦС или удаленный или прикрепленный OCSP)
• Проверить сертификат против журнала прозрачности сертификатов (CT), чтобы убедиться, что он был выдан тем, кем заявлен (и, ideally, чтобы не было другого сертификата, выданного кем-то другим для того же сайта, хотя на практике, я не думаю, что какие-либо клиенты предотвращают подключение в этом случае)

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

Пиннинг является дополнительным уровнем защиты. В отличие от любого из семи вышеупомянутых пунктов, это не то, что вы можете реально ожидать от клиентов реализовать повсеместно, потому что это требует знаний, которые не закодированы ни в корневом сертификате, ни в листовом сертификате, ни в доменном имени, ни в базовом протоколе TLS. Клиент должен знать, через какой-то дополнительный источник знаний, какой пин ожидать, на каком уровне. Однако на практике это распространено для приложений, которые общаются только с серверами своих разработчиков. Пиннинг ЦС (корневого или промежуточного) вместо самого сертификата (или даже публичного ключа) вполне популярен как компромисс между максимальной безопасностью и минимальным риском поломки[2]. Однако вы не просто проверяете, что листовой сертификат был выдан этим ЦС и считаете его действительным; совпадение с пинированным ЦС необходимо, но не достаточно для принятия листового (серверного) сертификата.

[1] Теоретически, пиннинг самого сертификата безопасен настолько, что вам не нужно проверять издателя, подпись или любые метаданные. Если сертификат (или по крайней мере его хэш-дайджест) совпадает с тем, что ожидает клиент, вы можете быть уверены, что он доверен! На практике, однако, это небезопасно; как минимум, вы также должны проверить, что сертификат не отозван, и в общем это очень плохая идея отключать какой-либо аспект проверки сертификата, если вы не уверены, что делаете это довольно хорошо.

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