в некотором проекте я реализовал RMI, транспортная часть которого использует libsodium.
для обмена ключами используется функции из раздела Diffie-Hellman из libsodium.
для шифрования/дешифрования используются функции AEAD crypto_secretbox_easy() и crypto_secretbox_open_easy()отсюда.
все работает как надо, за исключением того момента, что иногда в теле пакетов приходит мусор, типа того, что я привел в своей соседней теме
и тут меня смущает то, что функция crypto_secretbox_open_easy() успешно расшифровывает этот "плохой" пакет, значит, этот пакет был "испорчен" до применения к нему crypto_secretbox_easy(), которая, собственно и шифрует этот пакет и добавляет к нему тэг аутентификации(на противоположной стороне).
такие пакеты я ловил всего два раза. это очень редко, потому что этот код работает уже около полугода.
еще странность в том, что у пира приславшего этот пакет невозможно получить IP адрес, что похоже на SYN-flood атаку.
по поводу "подделки" пакетов перед шифрованием, я думаю, это можно сделать путем подмены msvcrt`шной функции memcpy(). но как с этим бороться? написать свою, хоть и не самую быструю реализацию этой функции(с инлайном етц..)?
Здравствуйте, niXman, Вы писали:
X>такие пакеты я ловил всего два раза. это очень редко, потому что этот код работает уже около полугода. X>еще странность в том, что у пира приславшего этот пакет невозможно получить IP адрес, что похоже на SYN-flood атаку.
Ты что-то глобально путаешь. При SYN flood вообще соединение не устанавливается. А если прошёл TCP handshake (TCP ведь?), то адрес другой стороны известен. Даже если его эмулирует ближайший раутер.
Невозможно получить IP — может быть следствием того, что отправитель прислал RST. Тогда сам виноват, что не получил адрес ещё в accept(), а ждал возможности сделать getpeername() когда-нибудь потом.
А вот атака с подделкой sequence numbers — тут вполне возможна. Тогда ты видишь её состоявшийся вариант. Но скорее таки локальный взлом клиента.
X>по поводу "подделки" пакетов перед шифрованием, я думаю, это можно сделать путем подмены msvcrt`шной функции memcpy(). но как с этим бороться? написать свою, хоть и не самую быструю реализацию этой функции(с инлайном етц..)?
И как ты собрался лечить этим удалённого клиента?
X>глобальный вопрос: как защититься?
Например, message sequence numbers внутри потока (и тогда они тоже шифруются). После этого успешно расшифровать поддельный TCP уже не сможешь; а если смог — то ремотная программа взломана и вопрос именно в этом.
Здравствуйте, netch80, Вы писали:
N>Ты что-то глобально путаешь. При SYN flood вообще соединение не устанавливается. А если прошёл TCP handshake (TCP ведь?), то адрес другой стороны известен. Даже если его эмулирует ближайший раутер.
похоже, ты прав...
N>Невозможно получить IP — может быть следствием того, что отправитель прислал RST. Тогда сам виноват, что не получил адрес ещё в accept(), а ждал возможности сделать getpeername() когда-нибудь потом.
кстати да, вариант...
N>А вот атака с подделкой sequence numbers — тут вполне возможна.
о чем речь?
N>И как ты собрался лечить этим удалённого клиента?
клиенты в этом проекте умеют автоапдейт, иначе они отключаются сервером сразу после проверки версии.
N>Например, message sequence numbers внутри потока (и тогда они тоже шифруются). После этого успешно расшифровать поддельный TCP уже не сможешь; а если смог — то ремотная программа взломана и вопрос именно в этом.
поясни плиз, не въезжаю...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
еще вариант: в клиенте используется dll`ка libsodium. враг же мог изменить в исходниках libsodium фукнцию crypto_secretbox_easy(), в ней патчить пакет, и собрать из этих исходников dll`Ку... линковка клиента со статической версией libsodium, поможет?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
N>>А вот атака с подделкой sequence numbers — тут вполне возможна. X>о чем речь?
У Алисы текущий seq в сторону Боба, например, 123000, Боб имеет такой же приёмный.
Маллет посылает пакет с src ip Алисы и таким же seq 123000 размером 30 байт.
Боб принимает пакет, кладёт 30 байт в сокетный буфер, отдаёт Алисе TCP ACK с seq=123030.
Алиса видит seq больше того, что она посылала, кричит "Грабят!" и посылает RST в сторону Боба.
N>>Например, message sequence numbers внутри потока (и тогда они тоже шифруются). После этого успешно расшифровать поддельный TCP уже не сможешь; а если смог — то ремотная программа взломана и вопрос именно в этом. X>поясни плиз, не въезжаю...
Нумеруешь посылки — 1,2,3... — и номер внутри шифрованной части, чтобы тот, кто не знает ключа, не смог воспроизвести ровно следующий номер.
Тогда, если он воспроизвёл, но прислал чушь — значит, взломано (или просто баг) не на сети посредине, а у клиента.
Здравствуйте, netch80, Вы писали:
N>Нумеруешь посылки — 1,2,3... — и номер внутри шифрованной части, чтобы тот, кто не знает ключа, не смог воспроизвести ровно следующий номер. N>Тогда, если он воспроизвёл, но прислал чушь — значит, взломано (или просто баг) не на сети посредине, а у клиента.
Здравствуйте, netch80, Вы писали:
N>Нумеруешь посылки — 1,2,3... — и номер внутри шифрованной части, чтобы тот, кто не знает ключа, не смог воспроизвести ровно следующий номер. N>Тогда, если он воспроизвёл, но прислал чушь — значит, взломано (или просто баг) не на сети посредине, а у клиента.
не понимаю зачем это нужно... в соседней теме и привел тело пакета. в этом теле есть валидный YAS заголовок, и ровно в том месте, где и должен быть. но в теле пакета мусор.
это же получается ровно то же самое, что и с нумерованием. пакет пропатчили перед щифрованием... или я что-то упускаю?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
если совсем сжато, то
на передающей и принимающей стороне используется большой 64 битный индекс
этот 64 индекс используется в векторе для aes криптографии
по каналу данных передается только меньшая 32 часть индекса
алго формирования 64 битного индекса на принимающей стороне есть в ссылке, в rfc, и самой либе
я вам больше скажу
у меня была ситуация с одним немецким интернет провайдером, который суров ко всяким торрентам итд, видимо всякие IDS фильтров наставлено до черта
так вот, при большой загрузке канала у клиента, данные по tcp в сокете после read приходили неверными, реконнект tcp сессии занимает много времени, а данные бежали релтайм
времени не было разбираться, на то сдвигаются ли они, т.е. какие то выпадание данных или выборочно портятся
немецкий пров косился, мол у нас все нормально это с вашей стороны
Всяко бывает, но у niXman с целостностью того, что приходит из сокета всё ок. crypto_secretbox_open_easy() прицепляет некий дайджест к каждому криптованному кусочку и проверяет его после декриптовки.
да это понятно
я всего лишь поделился опытом
хотя для меня было удивительным, по правилам read должен был вернуть мне какую то ошибку
а не отдавать испорченные данные
