Как обновить сертификаты android

Как обновить закрепленные ssl-сертификаты android

Я использую SSL-закрепление в нашем приложении для Android. Я закрепил на клиенте 2 сертификата (текущий и резервный), встроив их в приложение.

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

Одно из возможных решений, которое я вижу, — уведомление приложения. Я могу транслировать уведомление с новыми сертификатами и сохранять их в клиенте. Есть ли проблема в этом подходе или есть лучший подход?

1 ответ

ПУБЛИЧНЫЙ КЛЮЧ

Я использую SSL-закрепление в нашем приложении для Android. Я закрепил на клиенте 2 сертификата (текущий и резервный), встроив их в приложение.

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

Для работы в сети клиент Android использует библиотеку OKHttp. Если наш цифровой сертификат подписан центром сертификации, распознаваемым Android, для проверки сертификата можно использовать диспетчер доверия по умолчанию. Чтобы закрепить соединение, достаточно добавить имя хоста и хэш открытого ключа сертификата в client builder (). См. Пример этого рецепта OKHttp. Все сертификаты с одинаковым именем хоста и открытым ключом будут соответствовать хэш-функции, поэтому можно использовать такие методы, как ротация сертификатов, без необходимости обновления клиента. Множественное имя хоста — кортежи с открытым ключом также могут быть добавлены в построитель клиента ().

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

Вы всегда должны хранить резервные закрытые ключи в отдельных местах, чтобы в случае взлома одного из них вы не скомпрометировали все сразу, потому что в этом случае выпуск резервного PIN-кода с мобильным приложением бесполезен.

НЕ ДЕЛАЙТЕ ЭТОГО

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

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

Так что мой совет — не идти по этому пути, потому что вы выстрелите себе в ногу с большей легкостью, чем вы можете подумать.

Одно из возможных решений, которое я вижу, — уведомление приложения. Я могу транслировать уведомление с новыми сертификатами и сохранять их в клиенте. Есть ли проблема в этом подходе или есть лучший подход?

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

Открепление выполняется путем перехвата или перехвата вызовов функций в приложении во время его выполнения. После перехвата структура перехвата может изменить значения, передаваемые в функцию или от нее. Когда вы используете библиотеку HTTP для реализации закрепления, функции, вызываемые библиотекой, хорошо известны, поэтому люди написали модули, которые специально подключают эти функции проверки, чтобы они всегда проходили независимо от фактических сертификатов, используемых в рукопожатии TLS. Аналогичные подходы существуют и для iOS.

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

ВОЗМОЖНЫЙ ЛУЧШИЙ ПОДХОД

Но вы также просили лучшего подхода:

Есть ли проблема в этом подходе или есть лучший подход?

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

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

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

Xposed — это фреймворк для модулей, который может изменять поведение системы и приложений, не касаясь каких-либо APK. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (при условии, что исходный код не был изменен слишком сильно). Это также легко отменить.

Прежде чем мы углубимся в методику аттестации мобильных приложений, я хотел бы сначала развеять обычное заблуждение среди разработчиков относительно КТО и ЧТО вызывает сервер API.

Разница между ВОЗ и ЧТО имеет доступ к серверу API

Чтобы лучше понять различия между ВОЗ и ЧТО , обращающимися к серверу API, давайте используем следующую картинку:

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

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

Я надеюсь, что к настоящему моменту вы уже можете иметь представление о том, почему ВОЗ и ЧТО не совпадают, но если нет, то это станет ясно через мгновение.

WHO является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.

Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), протокол OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.

OpenID Connect 1.0 — это простой идентификационный уровень поверх протокола OAuth 2.0. Это позволяет клиентам проверять идентичность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.

Хотя аутентификация пользователя может сообщить серверу API, что ВОЗ использует API, она не может гарантировать, что запросы исходили из ЧТО , как вы ожидаете, исходной версии мобильного приложения.

Теперь нам нужен способ определить, что ЧТО вызывает сервер API, и здесь все становится сложнее, чем может показаться большинству разработчиков. ЧТО делает запрос к серверу API. Действительно ли это подлинный экземпляр мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, работающий вручную с сервером API с помощью такого инструмента, как Postman?

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

Приведенная выше статья была взята из статьи, которую я написал, озаглавленной ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? , и которую вы можете прочитать полностью здесь, это первая статья в серии статей о ключах API.

Аттестация мобильного приложения

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

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

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

Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.

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

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

Служба аттестации мобильных приложений уже существует как решение SAAS по адресу Approov (я работаю здесь), предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API, чтобы проверить токен JWT, выпущенный облачной службой. Эта проверка необходима для того, чтобы сервер API мог решить, какие запросы обслуживать, а какие отклонять.

ЗАКЛЮЧЕНИЕ

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

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

ВЫ ХОТИТЕ ПОЛУЧИТЬ ДОПОЛНИТЕЛЬНУЮ МИЛУ?

OWASP Mobile Security Project — это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки защищенных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.

Источник

Расслабьтесь. Владельцы старых Android-смартфонов не лишатся доступа к миллионам сайтов

Короткий период программной поддержки никогда особенно не страшил пользователей Android. Большинству из них было достаточно того, чтобы смартфон по-прежнему работает даже спустя два года после выхода, позволяет скачивать любые приложения из Google Play, а при необходимости не чинит препятствий для перепрошивки. Поэтому новость о том, что в 2021 году пользователи Android 7.1.1 и более ранних версий ОС лишатся доступа к более чем 200 миллионам сайтов из-за прекращения поддержки системного сертификата безопасности, прошла почти незамеченной. Но это и к лучшему.

Прекращение поддержки сертификата DST Root X3 на Android 7.1.1 отменяется

Прекращение поддержки сертификата безопасности могло привести к тому, что пользователям смартфонов на Android 7.1.1 и ниже был бы закрыт доступ к миллионам сайтов, которые используют его для защиты.

Если вы не понимаете, о чём идёт речь, вот вам небольшой экскурс. Около месяца назад стало известно, что компания Let’s Encrypt, разработчик сертификата безопасности DST Root X3, собирается прекратить его поддержку. Это специальный компонент, который отвечает за защиту пользователей при посещении сайтов в интернете, блокируя фишинговые и уведомляя об отсутствии протокола шифрования и, следовательно, опасности ввода персональных данных, которые могут быть либо перехвачены, либо прочитаны владельцем ресурса.

Сертификаты безопасности на Android

DST Root X3 — сертификат безопасности, вшитый в старые смартфоны на Android

Сертификат DST Root X3, поддержка которого должна была прекратиться в 2021 году, являлся для всех смартфонов с Android 7.1.1 и ниже системным. То есть зашитым в операционную систему по умолчанию без возможности самостоятельной замены. Единственный вариант заменить его – выпустить обновление с необходимыми изменениями. Но поскольку производители процессоров поддерживают их не дольше трёх лет, у владельцев потенциально затронутых устройств не было никакой надежды на апдейт.

К счастью для владельцев старых устройств, Let’s Encrypt продлила соглашение с IdenTrust, поставщиком цифровых подписей для сертификатов безопасности. Это значит, что действие сертификата DST Root X3 будет продлено, а пользователи смогут и дальше пользоваться сайтами в интернете без ограничений. Получается, что им больше не нужно ждать ни обновлений с обновлённым сертификатом безопасности, ни перепрошивать свои аппараты самостоятельно на кастомные прошивки, ни использовать альтернативные браузеры со встроенными сертификатами.

Не открывается сайт на Android. Что делать

Firefox — едва ли не единственный браузер со встроенными сертификатами безопасности

Впрочем, даже если бы поддержка сертификата DST Root X3 действительно прекратилась, большой беды всё равно бы не произошло. Несмотря на то что сертификаты являются встроенным системным компонентом Android, существуют браузеры, у которых есть собственный набор сертификатов. То есть даже если бы DST Root X3 лишился поддержки, пользователи Android всё равно смогли бы продолжать пользоваться интернетом как ни в чём не бывало. Главное установить подходящий браузер. В нашем случае это Mozilla Firefox – наиболее популярный и авторитетный веб-обозреватель, имеющий версии и для ПК, и для мобильных платформ.

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

Источник