|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
12.09.2014, 20:31 | #1 |
Форумчанин
Регистрация: 29.04.2008
Сообщений: 100
|
Шифрование соединения
Добрый вечер. Пишу клиент-серверное приложение. Понадобилось сделать шифрование передаваемых по сети данных (tcp). Опишу подробнее: по сети передается байтовый поток в формате (длина)(данные), дело в том, что канал связи подвержен атаке "человек посередине", то есть при передаче данные могут быть измены. Можно ли зашифровать соединение до передачи каких либо данных (например публичного ключа от сервера клиенту), чтобы при получении сервером измененных каким либо образом данных можно было выявить нарушителя и оборвать соединение.
|
12.09.2014, 20:48 | #2 |
Участник клуба
Регистрация: 12.09.2012
Сообщений: 1,030
|
Какой ещё "человек посередине"? В нормальном соединение по сетям Интернет, серединой является сервер провайдера.
Шифруй байты и передавай. При приеме на своей стороне произведи декодировку. Алгоритм шифрования можешь взять любой или придумать свой. А если ещё это сделать всё по умнее, то хакер трижды голову сломает перед тем, как узнает что ты там послал. Конечно, размеры передаваемых данных будут в несколько раз больше, но зато данные будут надежно защищены.
Что нужно программисту: Компьютер, Среда программирование, Воображение, Прямые руки, Мозги, Знания этой среды программирования.
Программист-это профессия, а программирование-это моё хобби. |
12.09.2014, 21:05 | #3 |
Форумчанин
Регистрация: 29.04.2008
Сообщений: 100
|
Защищены от подмены они не будут? А алгоритмы шифрования требуют либо пары (открытый/закрытый ключ) либо общего массива байт, являющегося ключом.
В первом случае сервер должен выдать сертификат со своим публичные ключом для каждой сессии. После чего клиент шифрует по этому ключу свой публичный ключ и передает его серверу (почти Диффи-Хеллман). Этот ключ не всегда имеет фиксированную длину, по этому его необходимо либо дополнить до той длинны которую ожидает сервер (а что если послать меньше?), либо дописывать длину "пакета" (которою можно поменять при передаче) Второй способ заключается в том, что у клиента и сервера уже есть общий секретный пароль (общий для всех сессий) и который не генерируется, а жестко зашит в клиенте( тут минусы думаю очевидны). При использовании электронной подписи, необходимо подписывать информацию от клиента до сервера, а следовательно в таком случае закрытым ключом обладает клиент, а не сервер, что тоже не есть хорошо. Последний раз редактировалось hiho; 12.09.2014 в 21:07. |
12.09.2014, 21:54 | #4 | |||
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Цитата:
Цитата:
Провайдер это только начало пути. Цитата:
Насколько важны данные? Может просто SSL хватит для установления безопасного канала?
I'm learning to live...
|
|||
12.09.2014, 22:08 | #5 | |
Форумчанин
Регистрация: 29.04.2008
Сообщений: 100
|
Цитата:
Данные отвечают за авторизацию и систему оплаты, так что лучше исключить подмену и просмотр. SSL вроде работает как раз на обмене ключами? Разве нет? Общая проблема заключается в том, чтобы отличить подмененные данные от настоящих, чтобы злоумышленник не мог повесить сервер передав не ту длину передаваемых данных (например несколько мегабайт на пакет, что при тысячах соединений весьма значительно) или как либо изменив данные. Идея с ЭЦП наиболее привлекательна, да и реализация ECDSA у меня есть, но я не знаю как подписывать трафик от клиента к серверу (а желательно наоборот) без предварительного обмена ключами и/или без хранения "вшитых" авторизационных данных Последний раз редактировалось hiho; 12.09.2014 в 22:16. |
|
12.09.2014, 22:42 | #6 | |||
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Цитата:
Цитата:
Цитата:
Другое дело если он его достанет либо от передающей либо от принимающей стороны, но это не так уж и просто для большинства какеров. Короче из мухи слона лучше не городить, а то слон в трафик н влезет, ибио будет багами давить.
I'm learning to live...
|
|||
12.09.2014, 22:53 | #7 | |
Старожил
Регистрация: 30.12.2009
Сообщений: 11,426
|
Передавать контрольную сумму пакета, сумму данных внутри самого пакета. А сервер по получении это проверяет. Подменить и пересчитать конечно можно, вопрос в том, всякий ли это сделает?
Цитата:
Скажите ещё что клиенты сами себе эти ключи генерят. При регистрации, клиент получает ключ, на сервере резервируется информация о ключе, его серверная пара, контрольная сумма, размер в байтах. Если ключ внезапно начал отличаться, то клиент идет в лес. Все. |
|
13.09.2014, 08:31 | #8 | |
Форумчанин
Регистрация: 29.04.2008
Сообщений: 100
|
Цитата:
Что же касательно хешей данных, то пока именно их и использую, к сожалению, нашлись люди, кто смог это дело раскрутить, именно поэтому и возникла потребность в более надежной защите. А в чем заключается безопасность при отправлении сервером клиенту ключа, по которому он будет шифровать, ведь перехватить и зашифровать свой измененный пакет не составит труда. Может я просто идею не понял? К тому же я не утверждал, что клиенты сами генерят себе ключи, я подразумевал что-то типо алгоритма Диффи-Хеллмана, где каждый из узлов генерирует свои ключи и после обмена получает общий по которому и будет шифровать. Последний раз редактировалось hiho; 13.09.2014 в 08:35. |
|
13.09.2014, 10:22 | #9 | ||
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Цитата:
Цитата:
Короче - ключей два. Тебе пожалуй не помешает почитать теорию про ЭЦП, там в общем рассказано как такие вещи осуществляются.
I'm learning to live...
|
||
13.09.2014, 10:51 | #10 |
Форумчанин
Регистрация: 29.04.2008
Сообщений: 100
|
Так в ЭПЦ подпись осуществляется как раз таки закрытым ключом, а проверка подписи - открытым. То есть чтобы сервер смог проверить подпись, у него должен быть открытый ключ, который сообщает ему клиент. Ну по крайней мере именно так я писал, когда реализовывать подпись файлов на электрических кривых.
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Таймаут соединения. | deromik | C# (си шарп) | 0 | 19.06.2013 17:39 |
скорость соединения ! | Morgusha | JavaScript, Ajax | 18 | 04.02.2013 18:20 |
Ошибка соединения | kilogram | PHP | 4 | 22.06.2012 16:57 |
ID соединения в TServerSocket | Crystallon | Работа с сетью в Delphi | 7 | 02.06.2011 13:02 |
C#: Создание соединения с БД | Veiron | Общие вопросы .NET | 3 | 03.06.2009 23:56 |