Учимся писать модуль ядра (Netfilter) или Прозрачный прокси для HTTPS

[@oldbay]

Очень объемно и интересно — положил в закладки и избранное(внимательно читать буду дома).
пс:
Вопрос для меня весьма актуален: как раз сейчас стоит задача пробросить https траффик прозрачно через squid.

[@Neuronix]

На сколько я помню, в ранних версия у SQUID была возможность проксировать HTTPS, которую закрыли позже из-за возможной атаки man-in-middle.

[@oldbay]

Вы имеете ввиду способ описанный на opennet-е?
через генерацию ключей на самом proxy-сервере
openssl genrsa -out /etc/squid/ssl/squid.key
openssl req -new -key /etc/squid/ssl/squid.key -out /etc/squid/ssl/squid.csr
openssl x509 -req -days 3650 -in /etc/squid/ssl/squid.csr -signkey /etc/squid/ssl/squid.key -out /etc/squid/ssl/squid.pem


с последующим указанием их suid-у

https_port 192.168.0.254:3129 transparent key=/etc/squid/ssl/squid.key cert=/etc/squid/ssl/squid.pem


[@lightoze]

Пример работы с ядром интересный, правда на практике лучше просто маршрутизировать трафик куда надо, минуя squid. Все равно он (squid) с HTTPS соединениями ничего полезного, например фильтрации и кэширования, сделать не сможет.

[@romy4]

Может подскажите про фильтрацию https: какие-нибудь интересные материалы?

[@lightoze]

Речь как раз о том что нечего его гнать через прокси, все равно толку не будет :)

[@kmeaw]

Через прокси его удобно гнать в том случае, если подсчёт трафика ведётся анализом access-лога squid.

[@sindo]

Полностью поддерживаю. Я вообще не любитель прокси серверов, особенно когда их использует в не нужных местах. Но бывают случаи, когда это может оказаться полезным. У меня на работе действует прокси с ntlm авторизацией и, чтобы избавится от него, появилась идея организовать свой прозрачный прокси перед ним. Но в итоге прокинул openvpn через этот прокси до домашнего маршрутизатора, а идея с прозрачным прокси для HTTPS вылилась в учебную статью для написания модулей :)

[@amosk]

Как обучалка написанию модулей для линукса — неплохо. Подробно и интересно написано.

Но практическая ценность сомнительна.
1) В линуксе для getsockopt существует опция SO_ORIGINAL_DST которая как раз позволяет получить первоначальный адрес сервера до перенаправления.
2) Для IPv6 -j REDIRECT не работает, т.к. REDIRECT это NAT который для IPv6 не реализован (хотя и существуют пока незавершенные проекты по устранению этого недочета).
Так вот из-за этого для перехвата IPv6 вместо REDIRECT используют таргет TPROXY который вобщем-то по сути тоже перехватывает соединение, но не через NAT а просто внаглую безо всяких преобразований адресов направляет в локальный слушающий сокет (специальным образом открытый с использованием опции IP_TRANSPARENT).
И поэтому получение первоначального конечного адреса для схемы с TPROXY тривиально — просто получить локальный адрес сокета.
Да и ничего не мешает использовать TPROXY для IPv4.

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

[@andrewsh]

Нереализованность NAT в IPv6 не есть недочёт, просто он в большинстве случаев либо не нужен, либо вреден.

[@amosk]

Ну так то ж в большинстве случаев.
А вот для оставшегося меньшинства — недочет.

[@andrewsh]

Ну, под меньшинством, в общем-то, я подразумеваю port redirect, который иногда бывает полезен. Всё остальное (anarsoul, привет!), как правило, приводит к плохим последствиям.

[@amosk]

Есть куча возможностей которые могут привести к плохим последствиям.
Но это не значит что у нас не должно быть выбора.

[@Alukardd]

Учимся прогить это всё конечно хорошо…
Но, опачки лезем ни куда-нибудь а в доку по Squid… Profit.
Пример статьи на тему, описано всё примитивным языком, а в дополнении с оф докой — подробнее уже некуда.

[@megadoizer]

вы собствено всю малину и обосрали =)

[@Alukardd]

Надо же открыть глаза публике — что squid мощная штука и ограничили его разработчики намеренно — MITM их не прельщает ;-)

[@sindo]

В приведенной статье не много не то, там осуществляется атака человек по середине. В результате браузер будет получать сертификат не гугла, а прокси сервера. Что выглядело бы весьма подозрительно, как для браузера, так и для пользователя :)

[@Alukardd]

Если это корпоративный пользователь, то ставите ему предварительно этот сертификат и предупреждений быть не должно, т.к. прокси инициирует соединение не от имени удаленного ssl сервера, а от своего, т.о. его сертификат является валидным.

[@sindo]

Я об этом и говорю :) Но не всем это может понравится. Нет ни какой уверенности, что прокси-сервер проверяет полученный сертификат от гугла, т.е. что после прокси-сервера ни кто не реализовал еще раз атаку человек по середине. И к тому же я бы лично не хотел, чтобы даже мой работодатель мог просматривать мои личные данные, когда я захожу в свой счет в сбербанке или там альфа-банке. И вдобавок, если вы идете на какой либо ресурс, который требует ваш личный сертификат, чтобы удостовериться что вы это вы, то здесь опять ожидает провал :) Я не говорю, что предложенная Вами статья не имеет право на существование, я просто обратил внимание, что там не много не то и пропадает весь смысл HTTPS соединения.