Как безопасно общаться с сервером?

Question

Я строю решение, состоящее из приложения и сервера. Сервер предоставляет некоторые методы (json), и приложение использует их. Моя цель - сделать эти методы API недоступными для других клиентов. Каков наилучший способ сделать это? Стоит ли смотреть на сертификаты (подписывать каждый исходящий запрос)? Если да, с чего начать и как это повлияет на производительность? Какие есть альтернативы?

Answer 1

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

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

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

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

Будет хит производительности. Сколько попаданий зависит от количества запросов от приложения. Класс iPhone NSURLConnection обеспечивает поддержку клиентских сертификатов SSL, и клиентские сертификаты могут быть установлены в телефоне по электронной почте или через веб-запрос с проверкой подлинности. Управление инфраструктурой для поддержки клиентских сертификатов потребует больше усилий, чем кодирование ее в приложение.

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

Answer 2

Рассмотрим аутентифицированный HTTP.

Для более дешевой альтернативы есть общая схема секрета / хэша. Клиент и сервер имеют общую секретную строку текста. По запросу клиент хэширует (используя MD5, или SHA1, или что-то еще SHA - вы выбираете) поля запроса и секрет. Хэш-значение прикрепляется к запросу, скажем, как другое поле POST.

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

Для дополнительной безопасности вы можете зашифровать хеш открытым ключом RSA. Клиент имеет открытый ключ, сервер хранит закрытый ключ. Сервер расшифровывает хеш с помощью закрытого ключа, затем тоже самое. Я сделал это с клиентом C ++ WinMobile и сервисом на основе PHP - работает как шарм. Впрочем, опыта работы с крипто на iPhone нет.

ОБНОВЛЕНИЕ: теперь, когда я думаю об этом, если предположить, что злоумышленник имеет полный контроль над клиентом ( гм взломанный iPhone и отладчик), проблема, как сформулировано выше, не решаема в теория. В конце концов, злоумышленник может использовать ваши биты для доступа к сервису. Обратный инжиниринг исполняемого файла, найти соответствующие функции и вызвать их с нужными данными. Создайте глобальное состояние, если это необходимо. Кроме того, они могут автоматизировать ваш пользовательский интерфейс, стиль скребка экрана. Таково печальное положение дел.

Answer 3

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

Оригинальный ответ:

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

Чтобы расширить это: предположим, что ваш вызов API имеет аргументы foo, bar и qux. Я бы добавил аргумент signature, значение которого может быть таким простым, как сортировка других аргументов по имени, конкатенация их с их значениями, добавление секрета и хеширование лота. Затем на стороне сервера я бы сделал то же самое (за исключением аргумента signature) и проверил бы, совпадает ли хэш с тем, который был указан в запросе.