Как приложения для Facebook, Snapchat или Gmail для iOS предотвращают дешифрование Fiddler их трафика https?
Я пытался использовать Fiddler для захвата трафика некоторых приложений iOS, например: Facebook, Snapchat, Gmail и Instagram.
Instagram не использует https, поэтому я могу получить весь трафик и посмотреть файлы cookie, которые я отправил, но Fiddler не может расшифровать другие три приложения. Это показывает только что-то вроде этого:
Обнаружено совместимое с SSLv3 рукопожатие ClientHello. Fiddler извлек параметры ниже. Версия: 3.3 (TLS/1.2) Случайная: 54 3F 49 C4 20 08 09 BC. A8 84 24 92 08 BF B4 38 39 C9 BB 1C B2 7B 95 6A 39 34 E7 AC FE 0F 62 67 SessionID: пусто Расширения: граф имени сервера.facebook.com elliptic_curves
Может ли кто-нибудь помочь мне понять, как они это делают, чтобы я мог использовать ту же технологию для защиты своего приложения.
2 ответа
Fiddler может расшифровывать трафик HTTPS, используя собственный сертификат. Однако, когда Facebook/Snapchat/Gmail обнаруживает, что сертификат не является доверенным системой (а в некоторых случаях он будет более строгим и ограничит сертификаты в доверенном, так что доверенный сертификат третьей стороны может быть отклонен), он откажется подключиться с сертификатом.
Fiddler может генерировать сертификаты для iOS для принятия и установки в систему, но сначала вам необходимо выполнить следующие инструкции:
- Установите CertMaker
- Сгенерируйте сертификат из Fiddler, он должен быть на вашем рабочем столе.
- Посетите сертификат в браузере Safari (только Safari, другие не будут работать)
- Установить сертификат
Исходя из этого, вы сможете отслеживать трафик этих приложений.
Поэтому, чтобы ответить на вопрос еще раз, дело не в том, что они предотвращают, а в приложениях SSL, как правило, отказывают в ответах от сервера, если сервер предоставляет ненадежный сертификат. Что делает Fiddler, так это подделывает часть сертификата, чтобы при обмене данными через SSL Fiddler мог использовать свой сертификат для расшифровки вашего трафика.
Чтобы ответить на вторую часть вашего вопроса, пожалуйста, проверьте этот вопрос для деталей. По сути, вы можете заставить пользователя использовать определенную сертификацию и, таким образом, запретить пользователю использовать установленные сертификаты.
Тем не менее, они все еще могут обойти это - просто более хитрым способом, но руководствуясь, это на стороне клиента, все идет.
Ваш вопрос вращается вокруг предотвращения атак HTTPS человек посередине (MITM) против приложений iOS. Использование Fiddler или других HTTPS-прокси является формой наивной атаки MITM, которая, к сожалению, часто работает.
HTTP построен поверх безопасного транспортного протокола, называемого TLS (а до этого - SSL). Соединение шифруется с использованием открытых и закрытых ключей между доверенными сторонами. И именно здесь вещи имеют тенденцию идти не так, как надо. Концепция доверия имеет решающее значение для безопасности TLS и SSL до него. Сервер, к которому подключается ваше приложение, предоставляет криптографические учетные данные, которые необходимо оценить для установления доверия.
Думайте об этом как паспорт или водительские права. В большинстве случаев лицензия проверяется. Тогда вы получите один с именем McLovin. Если вы на самом деле не смотрите на имя, дату рождения, номер, фотографию, голограмму и т. Д., Вы можете просто слепо поверить, что Макловин - это то, кем они себя называют. И тогда у тебя проблемы.
Не верь Макловину.
Большинство приложений доверяют McLovin:(
Чтобы защитить ваше приложение от подобных атак, вы должны реализовать более строгий набор оценочных и доверительных оценок. У Apple есть техническая записка Technote 2232: оценка доверия HTTPS, которая достаточно подробно описывает это.
Хорошее начало - внедрение SSL-пиннинга. Прикрепление проверяет учетные данные удаленного хоста по известному значению - полностью или частично по этому сертификату. Приложение iOS имеет некоторую копию этого сертификата, и при подключении к этому хосту проверяет учетные данные, которые хост предоставляет по этому "заведомо исправному" сертификату. Некоторые приложения просто проверяют метаинформацию, другие пытаются проверить контрольную сумму сертификата (AFNetworking делает это), а другие выполняют оценку полного доверия, используя известный действующий сертификат на основе учетных данных. Apple подробно описывает этот процесс на сессии WWDC 2014 " Создание приложений для предприятия и образования". Если удаленный хост не использует ожидаемые учетные данные, соединение прерывается. Злоумышленник не может перехватить трафик. Если сертификат вашего сервера часто меняется, это может быть проблемой - что является одной из нескольких причин, по которой предпочтительнее проверять открытый ключ сервера, а не метаинформацию или хеш. К сожалению, некоторые администраторы сервера часто меняют открытые ключи. Некоторые думают, что это более безопасно. Это не.
Теперь, очевидно, для этого требуется, чтобы приложение iOS имело копию "хорошего" сертификата или его часть. Вы можете включить сертификат в свое приложение или реализовать собственный метод обмена ключами. Безопасный обмен ключами уже давно является предметом криптографических исследований, и его не стоит воспринимать легкомысленно. Включение сертификата в ваше приложение является решением, используемым большинством людей. Вы можете решить, что важно защитить этот сертификат от кого-то, кто мог взломать или взломать устройство. У вас есть несколько вариантов для этого. Очевидно, вы можете включить его в качестве ресурса и зашифровать его. Вы также можете включить его непосредственно в двоичный файл приложения, что может быть намного более сложным для злоумышленника. Это можно сделать с помощью xxd инструмент с Xcode, как этап сборки скрипта или как правило сборки. Очевидно, вы можете реализовать дополнительную защиту в дополнение к этому.
Если устройство было взломано или приложение было подделано, возможно, учетные данные "заведомо исправны" были изменены. Это где песочница приложения iOS может работать в ваших интересах. Вы можете обнаружить многие из этих сценариев, выполнив проверку квитанции для своего приложения. Предполагается, что ваше приложение распространяется через канал Apple, такой как iOS App Store, когда оно установлено, оно содержит квитанцию. Это можно проверить и использовать для защиты от несанкционированного доступа для многих распространенных сценариев.
Это все методы, которые могут быть реализованы в клиенте для защиты связи по HTTPS от MITM-атак. Сервер также может предоставлять клиенту множество других возможностей, и сервер должен регулярно проверяться на наличие уязвимостей. Используйте только известные надежные криптографические алгоритмы, будьте в курсе текущих публичных уязвимостей и т. Д.
Конечно, если ваше приложение может подключаться к случайным HTTPS-службам, которые вы не можете контролировать, например, к веб-браузеру, ваши возможности более ограничены. В этих случаях лучшее, что вы можете сделать, когда учетные данные удаленного хоста находятся под сомнением, это дать пользователю возможность доверять или не доверять учетным данным. На iOS нет пользовательского интерфейса для этого, предоставляемого системными инфраструктурами, это было бы то, что ваше приложение должно было бы реализовать.
Это только один маленький аспект защиты приложения для iOS, но ваш вопрос был конкретным о человеке в середине атаки.