Как реализовать защиту от проксификации трафика приложения?

Question

[Akumu]

Есть некая программа, осуществляющая обмен данными с удаленным сервером.
Необходим действенный метод определения факта прохода трафика через сторонний сервер (HTTP/SOCKS прокси), когда приложение насильно заставляют это делать (пр. программа Proxifier).

Суть задачи в пресечении попыток перенаправления трафика для его дальнейшего анализа/модификации.

Answer 1

[Влад Животнев]

Поможет только обфускация протокола + https. Как у скайпа, например.
Сам https легко прослушивается, если его пустить через squid+sslbump.
Возможно, на некоторое время прослушку можно отсрочить тем, что использовать зашитые в клиент сертификаты и устанавливать соединение по SSL только с этими сертификатами - тогда пока не перекомпилят приложение с новыми сертификатами или не разберутся, как в сквиде использовать клиентский сертификат (а его ещё достать нужно) - то не смогут послушать трафик. Тут уже встаёт вопрос о необходимости прослушки (ценность информации) и упортости того, кто будет этим заниматься. Скрипт-киддисы такое не обойдут, но любой криптоманьяк - на раз.

Answer 2

[Степан]

Проснифить приложение смогут как вы не старайтесь. Решение это разве https + свой шифратор пакетов.

Comments

[Akumu]

Ну мне по крайней мере определять факт проксификации трафика. Шифрование присутствует, но это не мешает отправлять один и тот же пакет повторно, а это временами проблема.

[Пума Тайланд]

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

Answer 3

[Rowdy Ro]

SSL решит ваши проблемы. Хотя MITM все равно возможен.

Если у вас шифрование самописное тогда делайте так(грубо):
Удаленный сервер на каждый запрос возвращает в ответ случайную строчку (либо просто sequence number).
Добавляйте эту строчку в ваши следующие данные для отправки - шифруйте, отдавайте серверу - он расшифровывает, проверяет случайную строчку на равенство. Тем самым пока MITM не узнает ключ он не сможет повторно передать пакет.

Answer 4

[valplo]

Порт-скан клиента на предмет открытого прокси. Это, конечо, неправильно, но других вариантов я не вижу.