Комментарии 85
Где были с этой статьей пару месяцев назад, очень бы помогло.
А в чем преимущество данного способа перед сокс5 прокси поднимаемое средствами "голого" ssh за 5 секунд?
Как минимум отпадает нужда в ерунде типа доменных имен.
SSH сегодня работает, а завтра обновят DPI и уже не будет работать, или оставят 33.6 Kbps на соединение. Тот же l2tp, sstp уже некоторые операторы или блокируют или ограничивают. А HTTPS пока ещё свободен.
SSTP можно выявлять средствами обычного микротика. Достаточно проверять наличие sni заголовка в clienthello пакете. Если его нет, перед нами скорее всего sstp
Те кто поставили минусы, поднимете sstp с самопопидсанными сертификатом без домена и посмотрите трафик через wireshark (как мне кажется 95% sstp настроено именно так )
Или перед нами старый браузер/не очень старая Java. Ну или примерно любая заточенная под безопасность штуковина, которая решила куда-то сходить (считай всё, что касается банков, не посылает SNI - и сами банки приходят без SNI на хост).
Да и SSTP-клиентов уже сильно больше одного, некоторые SNI шлют.
Так sstp - тоже https.
У некоторых провайдеров с таким socks5 proxy какая то фигня творится — скорость не выше 2 мегабит и все тут.
Сокс блокировали, только https можно было использовать.
MITM-атаки при этом возможны?
Если нет свободного доменного имени, то можно воспользоваться сервисом https://sslip.io/ , который автоматически формирует домен по ip адресу, например, у вас есть сервер с айпишником 1.2.3.4 , тогда можете считать, что у вас уже есть домены 1.2.3.4.ssip.io , www.1.2.3.4.ssip.io , www.1-2-3-4.sslip.io и www-1-2-3-4.sslip.io .
Здравствуйте! Я пробовал такое же с nip.io и скажу вам, что плохо получается. Рейтлимиты (https://letsencrypt.org/docs/rate-limits/) выпуска сертификатов общие на весь sslip.io и nip.io. Чтобы такого не было, владельцы этих доменов должны были добавиться в public suffix list и тогда рейтлимиты на каждый поддомен считались бы отдельно, но они этого не сделали.
На nip.io я по итогу получал вот такую ошибку:
Sep 09 20:23:35 clockinstall dumbproxy[3371]: HTTPSRV : 2022/09/09 20:23:35 server.go:3228: http: TLS handshake error from 46.250.24.40:45570: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for: nip.io: see https://letsencrypt.org/docs/rate-limits/
Если кто нибудь напишет вариант подключения для iOS и Safari под MacOS, буду премного благодарен. Про PAC файлы в курсе, но хотелось бы что-то с более удобным включением/выключением и желательно с возможностью составлять списки сайтов для проксирования.
Нет, Вы не правы, потому что в SNI передаётся домен запрашиваемого сертификата прокси, а не самого запроса. Фильтр настраивается на выдачу 407 на секретный домен в запросе, который может и не существовать.
Учите матчасть.
Если вы через HTTPS-прокси запрашиваете HTTPS-сайт, что там будет два разных TLS-хэндшейка, один между браузером и прокси, и второй между браузером и уже конечным сайтом. Снаружи просматривается SNI первого, внешнего TLS-соединения. Но дело не в них.
Скажем, если я поднял прокси на mycoolproxy.myvps.net и включил опцию прятать 407, то на все запросы без авторизации прокси будет отвечать 400. Браузеру будет невдомёк, что нужно запросить у пользователя логин и пароль и отправить его заголовком авторизации. Для этого опция поддерживает секретный "домен", который если запросить через прокси, то прокси ответит 407 и тогда триггернётся авторизация в браузере и он будет уже дальше благополучно всегда слать заголовок Proxy-Authorization. Скажем, если я настроил там какой-то несуществующий домен afdgfesrgsdfgdfsgsdf.com и запрошу его через браузер, это приведёт авторизацию в браузере в порядке.
Если нужно, я могу поднять один такой сервер и скинуть кренделя в личку, чтобы можно было потыкать.
Кстати, получается, что у меня сделано то же самое, что probe_resistance в плагине forwardproxy для Caddy: https://github.com/caddyserver/forwardproxy
dumbproxy умеет в chains ?
Аналогичную задачу можно решить поставив Nginx + Let's Encrypt перед HTTP-proxy.
Nginx слушает внешний порт по HTTPS и пересылает все на поднятый на localhost Squid уже в дешифрованном виде. Squid авторизует и делает все, для чего он обычно предназначен.
Такой вариант несколько лет вместе со Squid использую в задаче удаленного доступа к подписным ресурсам организации по IP, проблем не было.
для nginx есть модуль, который поддерживает connect метод
А можно чуть подробнее?
Не слышал, чтобы Nginx использовали в качестве прокси, так как умеет только в реверс-прокси. Дак таки можно и проксей?
Реверс или не реверс зависит просто от того куда коннектится сам прокси, правильно? точнее можно ли ему динамически сказать куда. В этом плане nginx очень гибкий, можно в proxy_pass указать куда коннектиться и в Host заголовке подправить, если что.
В стандартной установке nginx уже может работать как прокси, но только через URL. Но для https по-нормальному нужен CONNECT метод. Вот тут то модуль этот и помогает: https://github.com/chobits/ngx_http_proxy_connect_module
Что-то мне представляется не все таким простым.
Надо же не просто узнать куда за страницей сходить (это да), надо авторизовать (возможно из ldap или еще откуда), поднять на проксе сессию, закрыть сессию по таймауту, ACL многим хочется.
Вроде все по отдельности можно сделать, но хотелось бы увидеть конфиг Nginx, как это может выглядеть. Нет случаем такого?
Я сам не пользовался, просто рассматривал в какой-то момент варианты. Но в общем nginx достаточно гибкий, просто конфигурация там не очень всегда интуитивная или легко читаемая.
Ну вот это проверить надо. Я в свое время не смог завести, чтобы именно в браузере работало. Здесь вон люди тоже с трудностями встречаются.
За 10 минут можно в докере поднять V2Ray / vmess, безо всяких доменных имён и возни с сертификатами. Эту связку даже китайцы заблокировать не могут.
А скиньте ссылочку, пожалуйста.
Да, это как раз моя статья. Этот метод полностью перестанет работать в 28 ноября, потому что Heroku закрывает бесплатные продукты.
Надо заметить, что упомянутую возню с доменами и сертификатами берёт на себя PaaS - а так они всё равно требуются. В статье выше описано как всё проделать за минуты, при том без завязки на какой-то конкретный PaaS.
Есть ли инструкция на этот счет?
В букмарки
При https-proxy схеме голым остаётся процесс пересылки сертификатов и SNI, по этим данным провайдеры уже давно фильтруют твитеры и линкедины всякие.
А разве у описаной схеме не получается https over https?
Получается. Но если прокся в России стоит, то уже ее соединение под блокировку попадёт.
А кто в здравом уме прокси для хождения в Интернет будет держать в РФ?
Если живёшь за границей, то бывает нужно и такое:
Европа блокирует некоторые российские сайты.
Некоторые российские сайты закрылись от заграницы из-за DDOS'а.
Пиратствовать тоже лучше не напрямую из той страны, где живёшь.
Спасибо. А как добавить поддержку IPv6?
Здравствуйте. В описании к steady-tun написано, Supports TLS SNI (server name indication) spoof. Как это сделать?
hidden_domain возможно использовать только с браузером? Я так понимаю, пустить телеграм или другую программу через прокси с таким флагом не получится?
Здравствуйте! Опция -tls-servername задаёт то, что будет отправлено в SNI.
Это я уже пробовал. Получаю ошибку: Upstream connection error: x509: certificate is valid for мой домен.com, not имя домена в tls-servername
так а сертификат тоже должен соответствовать, иначе смысл теряется - в Client Hello поменяли, а в Server Hello будет как есть. как вы хотите, чтобы было по итогу?
Понятно. Я просто ожидал, что это как в shsdowsocks + cloak. Задаёшь на сервере и клиенте любой домен, который не фильтруют.
hidden_domain возможно использовать только с браузером? Я так понимаю, пустить телеграм или другую программу через прокси с таким флагом не получится?
Получится, так как другие проги априори отправляют логин и пароль, если заданы - им не нужно триггерить 407 ответ, чтобы понять, что "пора".
Надо наверное сделать чтобы, коннектиться можно было на один домен, отправлять в SNI другой, а ожидать в сертификате третий. Добавлю себе заметку, чтобы сделать.
А где на клиенте указывается логин-пароль, который вписывается в конфиг?
На андроиде ни одно приложение для VPN не безопасно. Причина в том, что у андроида есть одна неприятная фича. Это именно фича, а не баг, так что жаловаться некуда. Помощи от Гугла не ждите. Фича заключается в том, что для освобождения памяти система останавливает приложения. Это не отключается и не настраивается. Приложения для VPN тоже попадают под раздачу. Так что в процессе просмотра сайта есть риск увидеть ошибку тика "контент недоступен в вашей стране", говорящую, что ваш трафик уже несколько секунд идет на прямую, и ваш айпи засвечен. Так-то вот
В андроиде есть встроенный VPN, который не является приложением. Вот его система без вашей команды не остановит. К сожалению, среди поддерживаемых им протоколов нет SSL/TLS
Еще можно соединяться по встроенному в систему протоколу — его уже ничего из памяти не выгрузит
А вот на айфоне — система может вышибить из памяти любую прогу и настроить это абсолютно невозможно.
Прогу - возможно, но если это грамотно написанный VPN клиент, который еще и регистрируется в системе - то с чего?
Еще раз, VPN клиент это условно интерфейс и сетевая библиотека. Интерфейс может и выгружается (он фактически всегда в памяти и не нужен), сетевая библиотека остается.
Посмотри Настройки - Основные - VPN - там перечислены все VPNы, даже с нестандартными протоколами. Ни разу не слышал и не видел, чтобы именно VPN выдавливался и трафик начинал идти через оператора.
оратор выше прав. все эти настройки, которые вы привели, помогают лишь отчасти. в андроиде вот эта как раз "фича" зашита изначально в самые корни ОС и решить проблему выгрузки из памяти с гарантией и на 100% нереально. некоторые приложения по тем или иным причинам с теми или иными ухищрениями более устойчивы к выгрузки из памяти, некоторые выгружаются по первому чиху. и объëм оперативки тут не причëм и проблемы не решает.
На андроиде галочки в настройках VPN Постоянная VPN (не отключатся от VPN)/Блокировать соединение без VPN разве не для решения этой проблемы придуманы?
А можно поменять порт на другой?
При выполнении вашей инструкции с другим портом, выдает ошибку
HTTPSRV : 2022/09/11 16:36:12 server.go:3228: http: TLS handshake error from urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
Пришлось поменять на стандартный 443, тогда все ок.
Если нет, то что можно сделать, если 443 порт занимает nginx?
Можно поменять на другой, за это отвечает опция -bind-address. По умолчанию выпуск серта идёт через валидацию домена по "tls-alpn-01", для чего нужно отвечать на порту 443. Если это не возможно, то можно валидироваться по "http-01" и тогда нужно, отвечая на запросы на порту 80. Для этого укажите опцию -autocert-http :80, и тогда демон будет слушать ещё порт 80 для ответа на челленджи на нём. Если и это не подходит и этот порт тоже занят, тогда выпускайте сертификаты как-то по-своему и указывайте путь к fullchain через опции -cert и -key.
Проблема в том, что провайдер отлично видит SNI. По сути смысла в проксях сейчас не много.
из текста не понял, letsencrypt даст сертификат на поддомен freemyip.com ?
Спасибо за интересный материал!
В целом будет на другом порту, но сертификат автоматически выпустить не получится - придётся как-то иначе придумывать.
Наверное через DNS-01 челлендж разве что провалидировать домен и выпустить серт.
А мне видимо не повезло (( Не запускается.
На последнем шаге в статье - проверка. Висит и нет ответа.
curl: (28) SSL connection timeout либо
curl: (28) Operation timed out after 300000 milliseconds with 0 out of 0 bytes received
Все этапы вроде по статье сделал. На впске с Убунту запускал. До этого крутится 3proxy, через него все открывается на клиенте. Но в начале сентября началась эта беда с Гуглом (lh6.googleusercontent.com и т.д.) и пару инстаграмных серверов.
Остановил 3proxy, думал ваш способ проверить.
Можно и нужно ли как то сделать защиту от bruteforse? Имею ввиду перебор пароля прокси
Публикации
Безопасный HTTPS-прокси менее чем за 10 минут