Альтернативные способы безопасной отправки данных через общедоступный интернет

Question

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

Наиболее очевидным вариантом было использование HTTPS / SSL, однако разработчик мобильных приложений неохотно делает это из-за дополнительного сетевого трафика (SSL Handshake) и дополнительной загрузки ЦП на телефоне.

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

Это даже правдоподобный вариант? Есть ли лучшие (или любые не-SSL) альтернативы?

Обратите внимание, что мобильное приложение предназначено как для Blackberry, так и для iPhone, а серверная часть - LAMP [php].

Answer 1

Ну,

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

Это действительно зависит от того, что вы пытаетесь сделать. Если вы сделаете это только один раз в запросах xx, это МОЖЕТ быть в порядке с точки зрения безопасности и лучше с точки зрения производительности. Или это может быть очень опасно. Скажем, я ловлю этот ключ API, подделываю или просто слегка изменяю запрос и отправляю его вам. Что тогда?

Я вижу смысл с накладными расходами (и вы это устраняете, если вы все-таки шифруете свои данные, правда?), Но если безопасность представляет для вас проблему, я бы не стал изобретать колесо здесь и использовать общепринятый и проверенный стандарт. SSL не решает все проблемы, но у вас есть потенциальная атака «человек посередине».

Итог: переопределение или тиражирование SSL будет трудным, длительным и дорогостоящим, не говоря уже о том, что вы, вероятно, не сделаете это с первой попытки. Не ходите туда, используйте SSL. Это именно то, что вам нужно

Редактировать: Эта ссылка может оказаться полезной для производительности SSL: Исследование производительности SSL на КПК . Среди них вы обнаружите, что самая дорогая операция, рукопожатие, обычно не выполняется каждый раз.

Answer 2

Был очень похожий вопрос , перенесенный на Security.SE несколько дней назад.

• Что заставляет вас думать, что издержки рукопожатия, которые вы получаете с SSL / TLS, будут больше, чем издержки вашего собственного протокола?
• Вы можете использовать PSK с TLS .
• Подходит ли ваша среда для использования предварительных общих ключей? (Я имею в виду, вы можете легко делиться своими ключами тайно в каждом экземпляре вашего мобильного приложения).

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

Answer 3

Похоже, вы пытаетесь реализовать шифрование с открытым / закрытым ключом.

Мое лучшее предложение - использовать SSL или хотя бы библиотеки OpenSSL .Реализовать его самостоятельно было бы намного сложнее, так как вам пришлось бы писать свои собственные методы для обработки ОЧЕНЬ большой целочисленной математики.