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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вариант с VPN рассматривали? 15.05.06 09:59  Число просмотров: 2272
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка>
Я конечно не совсем в тему т.к. ты просил протокол прокомментрировать, но все же)
Может быть, совместно с SSL (ну, или совсем без SSL) лучше использовать VPN?
<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-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach