Защита протокола связи с сервером

Присоединяюсь к вопросу.
Пока остановился на google protobuf в связке с http://www.ouah.org/ogay/idea_nxt/

Я про подмену клиента после его декомпиляции и разбора протокола.

Тебе что обеспечить нужно? Защиту от несанкционированного доступа или защиту информации в сообщении при передаче по среде передачи данных?

Звучит так: «Каждое сообщение, отправляемое на сервер, должно иметь подпись, которую нельзя было бы подделать без декомпиляции кода клиента.»

SSL?

Звучит так: «Каждое сообщение, отправляемое на сервер, должно иметь подпись, которую нельзя было бы подделать без декомпиляции кода клиента.»

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

установи безопасное соединение, фильтруй данные только от авторизованных клиентов, проверяй их корректность и т.д. Все это должно быть на сервере.

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

message+md5(message+salt+md5(password))

Сервер сможет пересчитать такой хэш (т.к. соль известна разработчику, а md5(password) будет храниться в базе данных пользователей).

Вместо md5 можно брать любой другой нравящийся тебе алгоритм хэширования.

которую нельзя было бы подделать без декомпиляции кода клиента.

Вроде должно выполняться, т.к. соль или алгоритм формирования соли можно будет получить только расковыряв клиент.

P.S. Примерно такой алгоритм был у ВК в версии 3.0 (см. как формируется sig http://vk.com/developers.php?oid=-1&p=Авторизация_Desktop-приложений )

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

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

Если ты не знаешь что тебе нужно, то тебе нужен TLS, а другое не нужно. Все равно ничего толкового не выйдет

Очевидно - никак, предложить нечего

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

message+md5(message+salt+md5(password))

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

Мне надо реализовать сервер, который бы адекватно реализовывал распознавание официальных клиентов, благодаря этой «фишке» в протоколе обмена.

Мне надо реализовать сервер, который бы адекватно реализовывал распознавание официальных клиентов, благодаря этой «фишке» в протоколе обмена.

Я думаю у тебя Microsoft и Adobe эту разработку потом с руками оторвут. Они до сих пор на своих WindowsUpdate'ах не могут отличить.