Шифрование соединения

[hiho]

Добрый вечер. Пишу клиент-серверное приложение. Понадобилось сделать шифрование передаваемых по сети данных (tcp). Опишу подробнее: по сети передается байтовый поток в формате (длина)(данные), дело в том, что канал связи подвержен атаке "человек посередине", то есть при передаче данные могут быть измены. Можно ли зашифровать соединение до передачи каких либо данных (например публичного ключа от сервера клиенту), чтобы при получении сервером измененных каким либо образом данных можно было выявить нарушителя и оборвать соединение.

[саша40]

Какой ещё "человек посередине"? В нормальном соединение по сетям Интернет, серединой является сервер провайдера.
Шифруй байты и передавай. При приеме на своей стороне произведи декодировку. Алгоритм шифрования можешь взять любой или придумать свой. А если ещё это сделать всё по умнее, то хакер трижды голову сломает перед тем, как узнает что ты там послал. Конечно, размеры передаваемых данных будут в несколько раз больше, но зато данные будут надежно защищены.

[hiho]

Защищены от подмены они не будут? А алгоритмы шифрования требуют либо пары (открытый/закрытый ключ) либо общего массива байт, являющегося ключом.
В первом случае сервер должен выдать сертификат со своим публичные ключом для каждой сессии. После чего клиент шифрует по этому ключу свой публичный ключ и передает его серверу (почти Диффи-Хеллман). Этот ключ не всегда имеет фиксированную длину, по этому его необходимо либо дополнить до той длинны которую ожидает сервер (а что если послать меньше?), либо дописывать длину "пакета" (которою можно поменять при передаче)
Второй способ заключается в том, что у клиента и сервера уже есть общий секретный пароль (общий для всех сессий) и который не генерируется, а жестко зашит в клиенте( тут минусы думаю очевидны).

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

[Stilet]

Какой ещё "человек посередине"?

Хакер, севший на линию.

В нормальном соединение по сетям Интернет, серединой является сервер провайдера.

А вот и нет )
Провайдер это только начало пути.

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

А что за проблема отдать сертификат и ключ ЭЦП принимающей стороне?
Насколько важны данные? Может просто SSL хватит для установления безопасного канала?

[hiho]

Сообщение от Stilet

А что за проблема отдать сертификат и ключ ЭЦП принимающей стороне?
Насколько важны данные? Может просто SSL хватит для установления безопасного канала?

Проблема может возникнуть не при отдаче сертификата, а при отправке клиентом своего ключа, зашифрованного с помощью сертификата, а точнее проблема в его длине, сервер же не знает сколько байт ему принимать, как я и писал выше.
Данные отвечают за авторизацию и систему оплаты, так что лучше исключить подмену и просмотр. SSL вроде работает как раз на обмене ключами? Разве нет?

Общая проблема заключается в том, чтобы отличить подмененные данные от настоящих, чтобы злоумышленник не мог повесить сервер передав не ту длину передаваемых данных (например несколько мегабайт на пакет, что при тысячах соединений весьма значительно) или как либо изменив данные. Идея с ЭЦП наиболее привлекательна, да и реализация ECDSA у меня есть, но я не знаю как подписывать трафик от клиента к серверу (а желательно наоборот) без предварительного обмена ключами и/или без хранения "вшитых" авторизационных данных

[Stilet]

сервер же не знает сколько байт ему принимать

Да что это за сервер такой? Самописный? А как он тогда вообще работает если не знает что ему передали?

Данные отвечают за авторизацию и систему оплаты

Ну не вопрос. Многие центры сертификации предлагают как раз на такой случай ПО и сертификаты для подписания и шифрования. И как правило 90% валютным операциям этого хватает.

я не знаю как подписывать трафик от клиента к серверу

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

[Человек_Борща]

Передавать контрольную сумму пакета, сумму данных внутри самого пакета. А сервер по получении это проверяет. Подменить и пересчитать конечно можно, вопрос в том, всякий ли это сделает?

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

Шта?

Скажите ещё что клиенты сами себе эти ключи генерят.

При регистрации, клиент получает ключ, на сервере резервируется информация о ключе, его серверная пара, контрольная сумма, размер в байтах.

Если ключ внезапно начал отличаться, то клиент идет в лес. Все.

[hiho]

Сообщение от Stilet

Да что это за сервер такой? Самописный? А как он тогда вообще работает если не знает что ему передали?

Наверное, я не правильно выразился, при передачи данных по tcp данные могут фрагментироваться, для того, чтобы различать склеенные и разбитые пакеты, я дополнительно передаю длину этого пакета. И при передаче ключей для SSL надо будет посылать данные в таком формате (13 00) ( ключ ), но при этой передаче, можно просто изменить длину и тогда сервер будет ожидать не 13 байт, а например 100. Сервер самописный, но разве при работе с tcp не у большинства такая схема доставки с передачей длины данных?

Что же касательно хешей данных, то пока именно их и использую, к сожалению, нашлись люди, кто смог это дело раскрутить, именно поэтому и возникла потребность в более надежной защите.
А в чем заключается безопасность при отправлении сервером клиенту ключа, по которому он будет шифровать, ведь перехватить и зашифровать свой измененный пакет не составит труда. Может я просто идею не понял?
К тому же я не утверждал, что клиенты сами генерят себе ключи, я подразумевал что-то типо алгоритма Диффи-Хеллмана, где каждый из узлов генерирует свои ключи и после обмена получает общий по которому и будет шифровать.

[Stilet]

И при передаче ключей для SSL надо будет посылать данные в таком формате (13 00) ( ключ ), но при этой передаче, можно просто изменить длину и тогда сервер будет ожидать не 13 байт, а например 100.

И пусть. Во-первых тогда зашифрованное не сойдется, а во-вторых если поступания пакета не будет дело решится таймаутом. Т.е. нужно просто указать серверу не ждать до востребования, а на протяжении некоего времени если данные не поступают разрывать соединение.

А в чем заключается безопасность при отправлении сервером клиенту ключа, по которому он будет шифровать, ведь перехватить и зашифровать свой измененный пакет не составит труда. Может я просто идею не понял?

Да. Не понял. По сети отправляется открытый ключ. Наличие этого ключа не позволяет расшифровать. У принимающей стороне как правило есть закрытый ключ. Скажем это флешка с файлам закрытого ключа, которая лежит у главбуха в сейфе. Ну или какой-нить аппаратный ключик.
Короче - ключей два. Тебе пожалуй не помешает почитать теорию про ЭЦП, там в общем рассказано как такие вещи осуществляются.

[hiho]

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