--- date: 2026-07-25 tags: - протоколы - shadowsocks - обход-блокировок - криптография aliases: - Shadowsocks - SS - Shadowsocks 2022 - SIP022 link: https://shadowsocks.org/doc/sip022.html --- # 🧦 Shadowsocks: как устроен самый старый живой прокси обхода > [!info] О чём заметка > Разбор протокола **Shadowsocks** — родоначальника современных прокси для обхода цензуры: как он устроен, почему старые шифры небезопасны, что изменила редакция **Shadowsocks 2022 (SIP022)** и в каком виде протокол имеет смысл использовать сегодня. Общая карта протоколов и того, какое ядро что поддерживает, — в [[protocols/00-overview|обзоре протоколов]]. ## TL;DR - Shadowsocks — **простой шифрованный прокси**: клиент шифрует адрес назначения и данные общим паролем и отправляет серверу. Ни рукопожатия, ни сертификатов, ни маскировки под сайт в базовом виде нет. - Именно простота дала протоколу и популярность, и главную слабость: **у трафика нет никакого «легального» вида** — он выглядит как поток случайных байтов, а это само по себе аномалия для DPI. - Исторические шифры (**stream ciphers**) сломаны: в феврале 2020 года была опубликована атака, превращающая сервер в оракул расшифровки — записанный трафик можно расшифровать целиком, не зная пароля. Использовать их нельзя. - **AEAD-редакция 2017 года** закрыла ту атаку, но оставила проблемы с защитой от повторов и слабый вывод ключа из пароля. - **Shadowsocks 2022 (SIP022)** — актуальная редакция: BLAKE3 вместо HKDF-SHA1, обязательный полноценный ключ вместо пароля, полная защита от повторов (включая UDP), сессионный UDP-релей и заголовки идентичности для многопользовательских серверов. - Сегодня Shadowsocks редко применяют «голым»: его заворачивают в [[protocols/shadowtls|ShadowTLS]], обфускаторы или транспорт, а от подписки к подписке всё чаще встречается [[xray/vless|VLESS]] с [[xray/reality|REALITY]]. ## Идея протокола Shadowsocks появился в 2012 году как ответ на простую задачу: провести TCP-соединение через сервер за границей так, чтобы наблюдатель не понял, куда именно вы идёте. Автор под ником clowwindy сознательно отказался от сложности: **никакого рукопожатия, никаких сертификатов, никакого согласования параметров**. Работает это так. Клиент и сервер знают общий секрет. Клиент открывает TCP-соединение к серверу и первым же делом отправляет зашифрованный заголовок с адресом назначения (домен или IP + порт), а следом — зашифрованные данные. Сервер расшифровывает, подключается куда сказано и гоняет байты в обе стороны. Проще говоря: Shadowsocks — это SOCKS5-прокси, у которого всё, включая адрес назначения, зашифровано общим паролем. Всё остальное — транспорт, маскировка, мультиплексирование — в базовом протоколе отсутствует. У такого минимализма есть прямое следствие для обнаружения. Соединение не начинается ни с TLS-рукопожатия, ни с HTTP-запроса — оно начинается со случайно выглядящих байтов и продолжается ими же. В сети, где почти весь трафик распознаваем, «поток без опознавательных знаков» становится отдельной категорией, которую можно отбирать и проверять активным зондированием. Работа исследователей [«How China Detects and Blocks Shadowsocks»](https://gfw.report/publications/imc20/data/paper/shadowsocks.pdf) (IMC 2020) описывает именно такую схему: пассивный отбор кандидатов по статистике и последующая активная проверка сервера. ## Три поколения шифрования Понимать разницу поколений важно практически: в конфигах и подписках до сих пор встречаются все три, а безопасны из них не все. | Поколение | Примеры методов | Состояние | |---|---|---| | **Stream ciphers** (до 2017) | `aes-256-cfb`, `rc4-md5`, `chacha20` | **Сломаны.** Не использовать | | **AEAD** (2017) | `aes-256-gcm`, `chacha20-ietf-poly1305` | Работоспособны, но с известными недостатками | | **Shadowsocks 2022** (SIP022) | `2022-blake3-aes-128-gcm`, `2022-blake3-aes-256-gcm`, `2022-blake3-chacha20-poly1305` | Актуальная редакция | **Почему потоковые шифры нельзя использовать.** В феврале 2020 года исследователь Zhejiang Peng опубликовал атаку, в которой сервер Shadowsocks выступает **оракулом расшифровки**: злоумышленник, не знающий пароля, модифицирует записанные шифротексты, отправляет их серверу и по реакции восстанавливает открытый текст записанных ранее соединений. Атака работает потому, что потоковые шифры не проверяют целостность сообщения — сервер честно расшифровывает то, что ему подсунули. На AEAD-шифры она не переносится: там подделанное сообщение отбраковывается по тегу аутентификации. Проще говоря: если в вашем конфиге стоит метод вида `aes-256-cfb` или `rc4-md5`, ваш трафик может расшифровать посторонний, никакого пароля для этого не требуется. Это не гипотетический риск и не «устаревшая практика» — это работающая атака. **Что не так с AEAD-редакцией 2017 года.** Она чинит целостность, но оставляет: вывод ключа из пользовательского пароля через HKDF-SHA1 (то есть силу ключа определяет качество пароля), неполную защиту от повторов на TCP (фильтр с растущей со временем долей ложных срабатываний) и её полное отсутствие на UDP. ## Что изменила редакция 2022 (SIP022) **Shadowsocks 2022** — спецификация, переработавшая криптографическую часть. Ключевые изменения по [официальному описанию](https://shadowsocks.org/doc/sip022.html) и [тексту спецификации](https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md): - **BLAKE3 вместо HKDF-SHA1** для вывода ключей — современная и быстрая функция. - **Криптографический ключ вместо пароля.** В конфиге теперь не «придуманная строка», а сгенерированный случайный ключ в base64. Это убирает целый класс проблем «пароль `12345678` защищает канал». - **Полная защита от повторов**, в том числе для UDP: у каждого запроса и ответа есть отдельный заголовочный блок с меткой, повторно отправленный пакет отбраковывается. - **Сессионный UDP-релей** — заметно лучше работает с UDP-приложениями (игры, голос), чем прежняя схема «каждый пакет сам по себе». - **Extensible Identity Headers** — заголовки идентичности, позволяющие одному серверу обслуживать много пользователей с разными ключами (то, ради чего раньше поднимали отдельный порт на каждого). - **Больший размер полезной нагрузки** — до 65 535 байт вместо 16 383. Обязательными к реализации объявлены `2022-blake3-aes-128-gcm` и `2022-blake3-aes-256-gcm`; варианты на ChaCha предусмотрены для процессоров без аппаратного AES. > [!warning] Редакция 2022 не делает трафик незаметным > SIP022 решает задачи криптографии и защиты от повторов — но **не задачу маскировки**. Трафик по-прежнему выглядит как поток случайных байтов без опознавательных признаков, и пассивная классификация «это не похоже ни на что легальное» работает против него ровно так же. Если в вашей сети Shadowsocks блокируют по этому признаку, менять шифр бесполезно — нужна обёртка (см. следующий раздел). ## Как Shadowsocks выживает сегодня Раз сам протокол вида не имеет, ему этот вид добавляют снаружи. Практикуются три подхода. **Обёртка настоящим TLS.** [[protocols/shadowtls|ShadowTLS]] проводит честное TLS-рукопожатие с настоящим сторонним сайтом, а внутрь уже кладёт Shadowsocks. Для наблюдателя соединение выглядит как визит на популярный ресурс. Родственный подход — `restls`; в свежих версиях [[Clash/06-features-protocols|mihomo]] для Shadowsocks появилась и обфускация `jls`. **Плагины обфускации.** Исторический вариант (`simple-obfs`, `v2ray-plugin`): дописать протоколу видимость HTTP или WebSocket. Против современных DPI, которые смотрят не только на первые байты, но и на статистику потока, это слабая защита — приём стоит считать устаревшим, хотя в старых конфигах он встречается. **Смена протокола.** Самый частый путь на практике: подписки переезжают на [[xray/vless|VLESS]] с [[xray/reality|REALITY]] или на QUIC-протоколы вроде [[Hysteria/00-overview|Hysteria 2]] и [[protocols/tuic|TUIC]], где маскировка встроена в дизайн, а не пристроена сбоку. ## Практические выводы - Если в конфиге метод из колонки stream ciphers — **меняйте немедленно**, это не вопрос гигиены, а вопрос конфиденциальности уже переданного трафика. - Из живых вариантов предпочитайте методы `2022-blake3-*`; они поддерживаются актуальными ядрами — [[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]]. - Ключ для SIP022 **генерируйте, а не придумывайте**: спецификация рассчитана на случайный ключ нужной длины, и «удобный пароль» здесь ломает модель безопасности. - Голый Shadowsocks в сетях с активным DPI держится плохо. Планируйте обёртку сразу или выбирайте протокол с встроенной маскировкой. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта: что решает каждый протокол и какое ядро его поддерживает. - [[protocols/shadowtls|ShadowTLS]] — обёртка, которая прячет Shadowsocks за рукопожатием настоящего сайта. - [[protocols/vmess|VMess]] и [[protocols/trojan|Trojan]] — два других протокола-ветерана и их слабые места. - [[xray/vless|Протокол VLESS]] — то, на что чаще всего мигрируют с Shadowsocks. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — как эти методы называются в YAML-конфиге. - 🔗 [SIP022 AEAD-2022 Ciphers](https://shadowsocks.org/doc/sip022.html) — официальное описание актуальной редакции. - 🔗 [How China Detects and Blocks Shadowsocks (IMC 2020)](https://gfw.report/publications/imc20/data/paper/shadowsocks.pdf) — исследование схемы обнаружения. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/shadowsocks.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).