#proxifyre — Public Fediverse posts

Старый добрый ламповый SOCKS5. Почему спустя почти 30 лет ему всё-таки понадобился TLS

Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5. Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу. Его до сих пор используют OpenSSH для динамического проброса портов, корпоративные прокси, системы автоматизации, инструменты тестирования, VPN-клиенты и просто пользователи, которым нужно направить трафик через удалённый сервер. Наверное, именно поэтому у меня всегда было к нему особое отношение. В SOCKS5 нет ничего лишнего. Это простой посредник, который помогает приложению установить соединение с нужным адресом через удалённый сервер. Он не пытается заменить VPN или стать универсальным сетевым протоколом. SOCKS5 честно выполняет одну задачу и делает это уже почти тридцать лет. Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.

https://habr.com/ru/articles/1061886/

#SOCKS5 #TLS #ProxiFyre #Alighieri #проксисервер #сетевая_безопасность #Windows #Linux #Rust #шифрование_трафика

Старый добрый ламповый SOCKS5. Почему спустя почти 30 лет ему всё-таки понадобился TLS

Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5. Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу. Его до сих пор используют OpenSSH для динамического проброса портов, корпоративные прокси, системы автоматизации, инструменты тестирования, VPN-клиенты и просто пользователи, которым нужно направить трафик через удалённый сервер. Наверное, именно поэтому у меня всегда было к нему особое отношение. В SOCKS5 нет ничего лишнего. Это простой посредник, который помогает приложению установить соединение с нужным адресом через удалённый сервер. Он не пытается заменить VPN или стать универсальным сетевым протоколом. SOCKS5 честно выполняет одну задачу и делает это уже почти тридцать лет. Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.

https://habr.com/ru/articles/1061886/

#SOCKS5 #TLS #ProxiFyre #Alighieri #проксисервер #сетевая_безопасность #Windows #Linux #Rust #шифрование_трафика

Старый добрый ламповый SOCKS5. Почему спустя почти 30 лет ему всё-таки понадобился TLS

Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5. Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу. Его до сих пор используют OpenSSH для динамического проброса портов, корпоративные прокси, системы автоматизации, инструменты тестирования, VPN-клиенты и просто пользователи, которым нужно направить трафик через удалённый сервер. Наверное, именно поэтому у меня всегда было к нему особое отношение. В SOCKS5 нет ничего лишнего. Это простой посредник, который помогает приложению установить соединение с нужным адресом через удалённый сервер. Он не пытается заменить VPN или стать универсальным сетевым протоколом. SOCKS5 честно выполняет одну задачу и делает это уже почти тридцать лет. Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.

https://habr.com/ru/articles/1061886/

#SOCKS5 #TLS #ProxiFyre #Alighieri #проксисервер #сетевая_безопасность #Windows #Linux #Rust #шифрование_трафика

Утечка хендлов в IP Helper API: как мы нашли и обошли ещё один баг Windows

После статьи о баге в CancelIoEx решил рассказать ещё об одном дефекте в системных компонентах Windows — на этот раз в IP Helper (часть Windows API, отвечающая за работу с сетевой статистикой и таблицами соединений). Этот API, среди прочего, даёт возможность сопоставлять перехваченные на уровне сети пакеты с локальными процессами. Казалось бы, проверенный механизм, который работает «под капотом» множества утилит и сетевых фильтров. Но в ходе тестирования WireSock Secure Connect в режиме split tunneling по процессам мы наткнулись на утечку, способную за считанные минуты выбить лимит хендлов в системе. Поводом для расследования стало сообщение в нашей группе поддержки WireSock в Telegram: один из пользователей заметил аномально быстрый рост числа открытых дескрипторов процессов. Проблема стабильно воспроизводилась под нагрузкой и исчезала, если использовать фильтрацию по IP-адресам. Это стало первой зацепкой, которая в итоге вывела нас на баг в реализации IP Helper. Отдельное спасибо пользователю @dno5iq , который обнаружил проблему, выполнил реверсинг GetOwnerModuleFromPidAndInfo и помог подтвердить наличие дефекта в её реализации.

https://habr.com/ru/articles/935610/

#windows_api #wiresock #vpn #winapi #reverse_engineering #системное_программирование #proxifyre #ip_helper #split_tunneling #handle_leak