Как перехватить и перенаправить трафик на любом порту?

Question

[xsash]

Есть 2 программы, клиент и сервер.
Общаются они на нестандартном порту, но через https. В клиенте можно указать ip:port сервера

Нет ли "простого" способа поднять некий сервис, который бы слушал XXX порт, подменял бы серт с логированием трафика и перенаправлял бы на ip:YYY. т.е. атака MITM

Comments

[xsash]

В итоге остановился на sslsplit

Answer 1

[rPman]

Нет, в этом и есть весь смысл использования https, незаметно атаку MITM провести не получится.

Чтобы атака в принципе могла быть произведена необходимо как то заставить клиента игнорировать контроль сертификата https или подсунуть свой корневой (кстати это имеет смысл только если сервис использует контроль сертификата от ос а не свой собственный). Так же она возможна при наличии сертификата используемого сервиса (он есть у владельца сервера) атака возможна
Тут достаточно поднять прокси-сервис, подписывая его запросы на промежуточном сервере.

Comments

[xsash]

Мне и не нужно "незаметно", мне как и нужно оттестировать, что сработает контроль и прочее.
Просто хотелось бы обойтись минимальным набором софта, чтобы не поднимать отдельный гейт

[rPman]

какие проблемы, я же написал, если какая то из сторон участников процесса (либо сервер либо клиент) вам подконтролен, то mitm возможна

[xsash]

rPman, с выбором софта для атаки

Answer 2

[Руслан]

iptables умеет такое настройте NAT masquerade

Answer 3

[CityCat4]

Простого способа нет. Единственная ее реалзиация - это так как сделано в squid. И главное - чтобы у клиента (инициатора соединения) стоял в доверенных сертификат СA, который выпустит сертификат для сервера-перехватчика.
Очень упрощенная обычная сессия:
Клиент: Привет, я Вася Писькин, умею так и так шифровать
Сервер: Привет, я vk.com, умею так и так шифровать
Клиент: ОК, согласен на ..., мой сертификат
Сервер: Мой сертификат
(далее проверка на клиенте того, что это на самом деле сертификат vk.com, проверка валидности сертификата, генерация сеансового ключа)
[зашифрованный сеанс]

Сессия через mitm (squid в данном случае):
Клиент: Привет, я Вася Писькин, умею так и так шифровать
Прокси: Привет, я vk.com, умею так и так шифровать
Клиент: ОК, согласен на ..., мой сертификат
(прокси быстренько генерит сертификат на себя на имя vk.com)
Прокси: Мой сертификат
(далее проверка на клиенте того, что это на самом деле сертификат vk.com, проверка валидности сертификата, генерация сеансового ключа. Заполучив сеансовый ключ, прокси обращается к настоящему vk.com, устанавливает с ним соединение и ведет обмен между Васей и vk.com как если бы его не было. Но поскольку ему доступен сеансовый ключ - он находится внутри соединения и может его мониторить и разорвать при необходимости.
Возникает конечно вопрос - почему Вася верит такому явному фейку, как сертификат от CA "Большой Брат", прикидывающийся vk.com? А все дело в шляпе том, что сертификат CA, выпустившего сертификат для прокси, ДОЛЖЕН находиться у Васи в доверенных - если этого нет, браузер Васи в ответ на сертификат прокси скажет "Ты кто такой? Давай, до свидания")