Комментарии 20
Очень объемно и интересно — положил в закладки и избранное(внимательно читать буду дома).
пс:
Вопрос для меня весьма актуален: как раз сейчас стоит задача пробросить https траффик прозрачно через squid.
пс:
Вопрос для меня весьма актуален: как раз сейчас стоит задача пробросить https траффик прозрачно через squid.
На сколько я помню, в ранних версия у SQUID была возможность проксировать HTTPS, которую закрыли позже из-за возможной атаки man-in-middle.
Вы имеете ввиду способ описанный на opennet-е?
через генерацию ключей на самом proxy-сервере
с последующим указанием их suid-у
через генерацию ключей на самом 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
Пример работы с ядром интересный, правда на практике лучше просто маршрутизировать трафик куда надо, минуя squid. Все равно он (squid) с HTTPS соединениями ничего полезного, например фильтрации и кэширования, сделать не сможет.
Может подскажите про фильтрацию https: какие-нибудь интересные материалы?
Полностью поддерживаю. Я вообще не любитель прокси серверов, особенно когда их использует в не нужных местах. Но бывают случаи, когда это может оказаться полезным. У меня на работе действует прокси с ntlm авторизацией и, чтобы избавится от него, появилась идея организовать свой прозрачный прокси перед ним. Но в итоге прокинул openvpn через этот прокси до домашнего маршрутизатора, а идея с прозрачным прокси для HTTPS вылилась в учебную статью для написания модулей :)
НЛО прилетело и опубликовало эту надпись здесь
Как обучалка написанию модулей для линукса — неплохо. Подробно и интересно написано.
Но практическая ценность сомнительна.
1) В линуксе для getsockopt существует опция SO_ORIGINAL_DST которая как раз позволяет получить первоначальный адрес сервера до перенаправления.
2) Для IPv6 -j REDIRECT не работает, т.к. REDIRECT это NAT который для IPv6 не реализован (хотя и существуют пока незавершенные проекты по устранению этого недочета).
Так вот из-за этого для перехвата IPv6 вместо REDIRECT используют таргет TPROXY который вобщем-то по сути тоже перехватывает соединение, но не через NAT а просто внаглую безо всяких преобразований адресов направляет в локальный слушающий сокет (специальным образом открытый с использованием опции IP_TRANSPARENT).
И поэтому получение первоначального конечного адреса для схемы с TPROXY тривиально — просто получить локальный адрес сокета.
Да и ничего не мешает использовать TPROXY для IPv4.
Т.е. как минимум две штатные для линукса схемы позволяют организовать прозрачное проксирование без написания своих модулей ядра. И squid например поддерживает обе.
Но практическая ценность сомнительна.
1) В линуксе для getsockopt существует опция SO_ORIGINAL_DST которая как раз позволяет получить первоначальный адрес сервера до перенаправления.
2) Для IPv6 -j REDIRECT не работает, т.к. REDIRECT это NAT который для IPv6 не реализован (хотя и существуют пока незавершенные проекты по устранению этого недочета).
Так вот из-за этого для перехвата IPv6 вместо REDIRECT используют таргет TPROXY который вобщем-то по сути тоже перехватывает соединение, но не через NAT а просто внаглую безо всяких преобразований адресов направляет в локальный слушающий сокет (специальным образом открытый с использованием опции IP_TRANSPARENT).
И поэтому получение первоначального конечного адреса для схемы с TPROXY тривиально — просто получить локальный адрес сокета.
Да и ничего не мешает использовать TPROXY для IPv4.
Т.е. как минимум две штатные для линукса схемы позволяют организовать прозрачное проксирование без написания своих модулей ядра. И squid например поддерживает обе.
Нереализованность NAT в IPv6 не есть недочёт, просто он в большинстве случаев либо не нужен, либо вреден.
Ну так то ж в большинстве случаев.
А вот для оставшегося меньшинства — недочет.
А вот для оставшегося меньшинства — недочет.
Ну, под меньшинством, в общем-то, я подразумеваю port redirect, который иногда бывает полезен. Всё остальное (anarsoul, привет!), как правило, приводит к плохим последствиям.
Учимся прогить это всё конечно хорошо…
Но, опачки лезем ни куда-нибудь а в доку по Squid… Profit.
Пример статьи на тему, описано всё примитивным языком, а в дополнении с оф докой — подробнее уже некуда.
Но, опачки лезем ни куда-нибудь а в доку по Squid… Profit.
Пример статьи на тему, описано всё примитивным языком, а в дополнении с оф докой — подробнее уже некуда.
вы собствено всю малину и обосрали =)
В приведенной статье не много не то, там осуществляется атака человек по середине. В результате браузер будет получать сертификат не гугла, а прокси сервера. Что выглядело бы весьма подозрительно, как для браузера, так и для пользователя :)
Если это корпоративный пользователь, то ставите ему предварительно этот сертификат и предупреждений быть не должно, т.к. прокси инициирует соединение не от имени удаленного ssl сервера, а от своего, т.о. его сертификат является валидным.
Я об этом и говорю :) Но не всем это может понравится. Нет ни какой уверенности, что прокси-сервер проверяет полученный сертификат от гугла, т.е. что после прокси-сервера ни кто не реализовал еще раз атаку человек по середине. И к тому же я бы лично не хотел, чтобы даже мой работодатель мог просматривать мои личные данные, когда я захожу в свой счет в сбербанке или там альфа-банке. И вдобавок, если вы идете на какой либо ресурс, который требует ваш личный сертификат, чтобы удостовериться что вы это вы, то здесь опять ожидает провал :) Я не говорю, что предложенная Вами статья не имеет право на существование, я просто обратил внимание, что там не много не то и пропадает весь смысл HTTPS соединения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Учимся писать модуль ядра (Netfilter) или Прозрачный прокси для HTTPS