24 октября 2026 года вышел 3proxy 1.0.2: встроенный DNS-прокси dnspr теперь проверяет источник и содержимое ответов, отсекая ответы с неверным адресом отправителя, идентификатором или вопросом. Разработчики также устранили зависание обработки неполной TLS-записи и снизили расход памяти HTTP-прокси: в приведённом ими сценарии с 2000 туннелей CONNECT потребление сократилось с 339 до 213 МБ.
DNS-прокси dnspr больше не принимает ответ от постороннего отправителя
В прежних версиях dnspr мог передать клиенту первый пакет, поступивший на сокет, через который отправлялся запрос к DNS-серверу. Программа при этом не проверяла, совпадают ли адрес отправителя, идентификатор DNS-запроса и сам вопрос. Если в сокет попадал поддельный ответ, клиент рисковал получить неверный адрес запрошенного домена.
В 1.0.2 исходящий DNS-запрос получает случайный идентификатор. dnspr принимает ответ только от того DNS-сервера, к которому обратился, и сверяет идентификатор вместе с вопросом. Так устраняется конкретный способ подмены ответа, описанный в примечаниях к релизу. В описании релиза нет сведений о подтверждённых атаках с использованием этой ошибки или отдельного идентификатора CVE.
Для понимания масштаба проблемы полезно знать, где используется dnspr. По официальной документации, он может пересылать запросы к DNS-серверам, указанным через nserver, и работать с кэшем nscache и статическими записями nsrecord. Поэтому некорректный ответ затрагивал именно клиентов, которые использовали такой DNS-прокси для определения адресов сайтов и сервисов.
Неполные TLS-записи больше не заставляют поток занимать весь CPU
Ещё одна ошибка проявлялась, когда клиент отправлял только часть TLS-записи и затем прекращал передачу. Обрабатывающий поток мог бесконечно работать, загружая одно процессорное ядро, а ожидание данных не завершалось по тайм-ауту. В 3proxy 1.0.2 это поведение исправлено.
Релиз меняет и обработку корректного TLS-трафика. С OpenSSL 1.1.0 и новее программа заранее считывает TLS-записи; по измерениям разработчиков, на их расшифрование уходит на 9–14% меньше процессорного времени. Это показатель конкретной операции, а не обещание такого же ускорения любого прокси-соединения.
HTTP-прокси теперь освобождает буфер запроса размером 64 КБ на время передачи данных через туннель CONNECT и ожидания следующего запроса в постоянном соединении. В опубликованном сравнении 2000 туннелей занимают 213 МБ вместо 339 МБ — разница составляет 126 МБ. Прежде буферы сохранялись и во время работы туннелей, которым они не требовались.
На Linux снова доступен собранный по умолчанию механизм splice(), но задействуется он для служб с опцией -s. Разработчики предусмотрели варианты -s1 для передачи от сервера, -s2 для передачи от клиента и -s3 для обоих направлений. Обычная -s выбирает случаи, где механизм выгоден для длинных потоков и больших объёмов данных.
Исправления SOCKS, обрывов соединений и работы в Linux и Windows
В SOCKS CONNECT и BIND при отсутствии -Ne программа возвращала клиенту адрес его подключения к прокси вместо адреса сокета, созданного для связи с назначением. Для BIND это было критично: клиент получал неверный порт, поэтому другая сторона не могла установить ожидаемое соединение. По сведениям разработчиков, ошибка существовала с версии 0.9.6.
Также исправлена обработка half-close — ситуации, когда одна сторона закрыла только отправку данных, сохранив возможность принимать ответ. Раньше из-за этого ответ мог обрываться, иногда с потерей мегабайтов данных; похожая проблема возникала при загрузке данных после закрытия отправки сервером. В Windows доработали завершение соединений, чтобы избежать утечки сокета и потери последних байтов ответа.
Для Linux устранены ошибки работы с Unix-сокетами: прокси мог передать лишь начало ответа, абстрактный сокет получал некорректное имя, а при перечитывании конфигурации удалялся файл слушающего сокета. Отдельно исправили ситуацию, когда сигнал SIGPIPE мог завершить процесс 3proxy. У HTTP-прокси устранено ненужное переподключение к серверу при смене метода запроса, например с GET на POST при обращении к тому же хосту.
Совместимость конфигураций после перехода на 3proxy 1.0.2
Обновление содержит изменения, которые влияют на привычное поведение служб. Параметр TCP_NODELAY теперь включён по умолчанию для соединений прокси с клиентом и сервером; в настройках предусмотрено его отключение через -ocTCP_NODELAY=0 и -osTCP_NODELAY=0. Параметры сокетов принимают значения в форме NAME=VALUE, а некорректные имена и значения считаются ошибкой конфигурации.
Поддержка адресов ftp:// в HTTP-прокси теперь требует отдельной опции -Xftp и сборки с FTP=true. Исправлена передача журналов в syslog и определение локального времени при использовании chroot. Разработчики устранили несколько источников утечек памяти, в том числе после неудачной перезагрузки конфигурации и ошибочного TLS-рукопожатия. Для связки wolfSSL с режимом WOLFSSL_QT, встречающейся в wolfSSL 5.9.1 из Ubuntu 26.04, исправили выпуск подменных сертификатов TLS.
Версия 1.0.2 опубликована для Windows, Linux в пакетах DEB и RPM, а также для отдельных платформ OpenWrt 24.10. Контрольные суммы и подписи сборок доступны на официальной странице релиза.
В релизе 3proxy 1.0.2 сошлись безопасность DNS и экономия ресурсов
По сравнению с 1.0.1 новая версия закрывает отдельную проблему проверки DNS-ответов, устраняет зависание при получении неполной TLS-записи и меняет расход ресурсов при большом числе HTTP-туннелей. Дополнительно исправлены сценарии с SOCKS BIND, частичным закрытием соединений и Unix-сокетами. Цифры экономии памяти и процессорного времени пока представлены как результаты измерений разработчиков; независимых сравнений в опубликованных материалах релиза нет.
