информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медЗа кого нас держат?Атака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Согласен. 10.06.06 04:38  Число просмотров: 2107
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
<programming>
Пока нет SSL... 14.05.06 19:45  
Автор: 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 должна гарантировать целостность данных.


Спасибо.
В принципе можно немного упростить: 07.06.06 11:06  
Автор: IgorR <Igor Razin> Статус: Member
<"чистая" ссылка>
В принципе можно немного упростить:

4) Клиент готовит и отправляет пакет серверу:
- вычисляет hash_2 = hash ( команды + challenge_2 + hPwd )
- отправляет серверу команды + hash_2

Проверка на сервере понятна.
Первый раз так и делал. Может так и надо делать. Сервер... 09.06.06 04:20  
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 09.06.06 06:36  Количество правок: 1
<"чистая" ссылка>
> В принципе можно немного упростить:
>
> 4) Клиент готовит и отправляет пакет серверу:
> - вычисляет hash_2 = hash ( команды + challenge_2 + hPwd )
> - отправляет серверу команды + hash_2
>
> Проверка на сервере понятна.

Первый раз так и делал. Может так и надо делать. Сервер ведёт учёт последовательности сообщений от клиента, но тем не менее, включение в завершающий пакет hash_1 ( что был в самом начале хендшейка ) немного ослабит man in the middle - "заканчивает тот клиент, который был в начале".
(хотя, конечно, это от малолетних хацкеров)

Спасибо за мнение.
ИМХО особого рояля не сыграет, ведь man-у известен этот... 09.06.06 11:08  
Автор: IgorR <Igor Razin> Статус: Member
<"чистая" ссылка>
> включение в завершающий пакет hash_1 ( что был в
> самом начале хендшейка ) немного ослабит man in the middle

ИМХО особого рояля не сыграет, ведь man-у известен этот самый hash_1, и единственной секретной компонентой опять таки остается hPwd.
Согласен. 10.06.06 04:38  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Ну подскажите ж бегинеру ;) Хоть бы ради фана ;)) 07.06.06 05:13  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Вариант с VPN рассматривали? 15.05.06 09:59  
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка>
Я конечно не совсем в тему т.к. ты просил протокол прокомментрировать, но все же)
Может быть, совместно с SSL (ну, или совсем без SSL) лучше использовать VPN?
Как раз в тему. Т.к. проект, как я сказал не впродакшт... 16.05.06 03:11  
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 16.05.06 03:13  Количество правок: 1
<"чистая" ссылка>
> Я конечно не совсем в тему т.к. ты просил протокол
> прокомментрировать, но все же)
> Может быть, совместно с SSL (ну, или совсем без SSL) лучше
> использовать VPN?
Как раз в тему. Т.к. проект, как я сказал не впродакшт. Можно и VPN. Тогда вообще этот сервис не нужен, т.к. можно использовать то клиентское ПО, что уже есть. Но это не мне решать. Как батьки в конце концов решат, так и будет.

ПС. Забыл сказать. Спасибо ;)
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach