Разметка сообщений в TCP-связи

Question

Я новичок в сетях и, в частности, TCP (я немного обманывал UDP, но это все). Я разрабатываю простой протокол, основанный на обмене сообщениями между двумя конечными точками. Эти сообщения должны быть сертифицированы, поэтому я реализовал криптографический уровень, который позаботится об этом. Однако, хотя UDP имеет звуковое определение пакета, который составляет минимальную единицу, которая может быть передана за один раз, протокол TCP (насколько я понимаю) полностью ориентирован на поток.

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

Скажите, что мне нужно передать сообщение длиной 1234567 байт. Прежде всего, я связываю 4 байта с целым числом, представляющим размер сообщения. Хорошо. Затем я отправляю сообщение. Это сообщение делится на несколько пакетов, которые получают отдельно. Теперь злоумышленник просто отправляет в дополнительный пакет, подделывая его так, как если бы он был частью разговора. Это может быть только один байт: это полностью разрушает любой механизм синхронизации, который я реализовал! Сообщение имеет ложный байт в середине, и он не будет успешно декодироваться. Кроме того, последний байт первого сообщения нарушает выравнивание второго сообщения и т. Д.: Соединение разрушается и с простой, простой атакой! Насколько вероятна и возможна эта атака?

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

Answer 1

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

Преодоление такой проблемы с инжектией связано с обеспечением потока. Создайте зашифрованный поток и отправьте через него свои пакеты.

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

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

Насколько вероятна и возможна эта атака?

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

В принципе, это не возможно для злоумышленника C, совершающего против конечных точек A и B, которые находятся вдали от C в сети. Поддельный исходный IP-адрес будет отклонен задолго до того, как C сможет достичь своего пункта назначения. Это более правдоподобно как внутреннее задание (которое включает вредоносное ПО): C близко к A и B.

Answer 2

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

И эти TCP-пакеты могут быть разделены еще больше на IP-фрагменты во время их пути через сеть (которые могут быть отключены флагом IP-адреса «Не фрагментировать»), но этот флаг может привести к тому, что ваши пакеты не будут доставлено вообще).

Я думаю, что ваша проблема не о введения пакетов в протокол потока, но о крепящих его.

IPSec может быть очень полезным в вашем сценарии, поскольку он работает на сетевом уровне.

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

(Почти) все делается автоматически ОС - поэтому вам не нужно беспокоиться об этом (и делать ошибки).

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

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

Другой альтернативой является использование SSL/TLS поверх сеанса TCP, которое менее надежное (поскольку оно закрывает целостное соединение при ошибке целостности).