Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Пока нет SSL... 14.05.06 19:45 Число просмотров: 2006
Автор: void <Grebnev Valery> Статус: Elderman
|
Прошу помочь немного подсказать, как залатать уязвимости протокола что ниже. SSL пока не сделан в тестовой версии. Сделаю, если дело дойдёт до продакшн.
Задача:
У меня есть приложение, состоящее из БД (неважно какая) + server, который слушает Интернет (кастом протокол) + клиент, который должен просить server обратиться к БД и выполнить некоторую работу. БД - в локалке. Server там же, но слушает на внешнем интерфейсе. Клиент - может быть в Африке.
Пока всё это хозяйство тестируется (несекурные информационные бизнес процессы).
Как лучше построить проверку подлинности клиента, если, данные, передаваемые клиентом серверу несекретные, но надо быть уверенным, что именно наш клиент коннектится к серверу, и посылает всяческие команды? Если дело дойдёт до продакшен, то заменю то, что ниже на SSL. Пока нет SSL, я склепал простой протокол для аутентификации клиента? О чём и речь ниже.
Если кто-то захочет помочь и высказаться, то:
I). О протоколе:
Используется TCP. После аутентификации происходит передача одной команды серверу и соединение закрывается. Если надо выполнить другую команду, то клиент должен начать всё сначала, выполнить "серверный пакет" в пределах одного TCP соединения (в терминах TCP). Ожидается, что в день клиент будет посылать один-два "серверных пакета" (здесь "пакет" = аутентификация + команда).
Поскольку протокол мессадж-ориентированный, то он сделан прехедед. Протокол имеет два лэйр. Каждый лайр прехедед. В заголовках пакетов передаются команды, длины данных, офсеты, контрольные суммы. Кроме того, учитывается последовательность пакетов.
II). О «не нашем человеке» по середине. Он умеет:
1) создавать "сырые" пакеты, иногда предугадывая seq # TCP, пересчитывая конторольные суммы, и т .д. Таким образом он может "влезать" в соединения, подменяя пакеты клиента или сервера искажёнными данными. Может посылать повторные пакеты – копии пакетов от настоящего клиента.
2) может находится на маршрутиризаторе, как встроенное враждебными силами ПО. Получив IP пакет, он может его отправить далее искажённым серверу и клиенту.
3) знает спецификацию данного кастом протокола.
III). Спецификация:
Сервер может определить из БД сохранённый hash (userpasswod) hPwd для клиента username. Клиент его вычисляет hPwd.
1) КЛИЕНТ посылает:
- username (как есть);
- challenge_1 (случайная последовательность байт)
- переходит к п.3, см. ниже.
Клиент хочет первым проверить подлинность сервера, чтоб сервер ответил на clallenge_1 значением hash_1 = hash ( clallenge_1 + hPwd ). Если клиент не получит такого результата сразу после этого пакета, то соединение будет им завершено.
2) СЕРВЕР получив данные username и challenge_1 выполняет следующее:
- вычисляет "ответ" hash_1 = hash( challenge_1 + hPwd ) на challenge_1 клиента;
- создаёт для клиента свой challenge_2 (случайная последовательность байт);
- посылает клиенту ответ на его challenge_1 в виде hash_1, и при этом посылает свой challenge_2;
Т.е. сервер делает две вещи. Он отвечает клиенту на clallenge_1 значением hash_1. Одновременно он просит клиента, в свою очередь, подтвердить подлинность ответом на challenge_2.
Сервер хочет, чтоб клиент ответил ему на clallenge_2 значением hash_2 = hash ( clallenge_2 + hPwd ). Если он не получит такого результата в следующем от клиента пакете, то соединение будет завершено сервером.
3) КЛИЕНТ проверяет подлинность сервера. Он сверяет полученный от сервера hash_1 со значением, рассчитываемым по challenge_1 и userpassword. Если ожидания клиента по п.1. не выполнены, т.е. если hash_1 != hash (challenge_1 + hPwd), то это не "наш" сервер. Тогда заканчиваем. Иначе клиент готовит “полезную команду”, п.4.
4) Клиент готовит и отправляет пакет серверу:
- вычисляет hash_2 = hash (challenge_2 + hPwd) (это удостоверение подлинности клиента для сервера, здесь challenge_2 – тот чалендж, что был получен от сервера);
- включает в пакет несекретные коды команд серверу, который сервер будет выполнять (полезные команды).
- вычисляет контрольную сумму, которую включает в заголовок пакета. Контрольная сумма рассчитывается по значению последовательности байт всего пакета (заголовков и команд) + hash_1 + hPwd, которые потом отбрасываются перед отправкой.
5) СЕРВЕР сравнивает полученный hash_2 с вычисляемым значением hash_2_srv = hash( challenge_2 + hPwd ) . Это будет служить проверкой подлинности клиента. Если hash_2_srv == hash_2, то сервер, считает, что это "наш" клиент. Иначе сервер закрывает соединение. Далее от проверяет контрольную сумму, добавляя к полученному пакету сохраненное с начала соединения значение hash_1, и hPwd. Если CRC OK, выполяется команда клиента. CRC должна гарантировать целостность данных.
Спасибо.
|
- Пока нет SSL... - void 14.05.06 19:45 [2006]
|
|
|
подробно о проекте
Анализ криптографических сетевых...
