Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
В принципе можно немного упростить: 07.06.06 11:06 Число просмотров: 2126
Автор: IgorR <Igor Razin> Статус: Member
|
В принципе можно немного упростить:
4) Клиент готовит и отправляет пакет серверу:
- вычисляет hash_2 = hash ( команды + challenge_2 + hPwd )
- отправляет серверу команды + hash_2
Проверка на сервере понятна.
|
|
<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. Тогда вообще этот сервис не нужен, т.к. можно использовать то клиентское ПО, что уже есть. Но это не мне решать. Как батьки в конце концов решат, так и будет.
ПС. Забыл сказать. Спасибо ;)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
