Konfiguracja NaiveProxy w sing-box: bezpieczna alternatywa VLESS

# NaiveProxy: bezpieczna alternatywa VLESS oparta na Chromium

W warunkach aktywnych blokad protokół NaiveProxy oferuje unikalne podejście do maskowania ruchu — poprzez wykorzystanie oryginalnego stosu sieciowego Chromium. Rozłożymy na czynniki pierwsze, jak skonfigurować klienta i serwer z sing-box i Caddy, unikając pułapek.

Podstawy maskowania: dlaczego NaiveProxy jest lepszy od uTLS?

Standardowe protokoły proxy maskują się pod ruch HTTPS, ale pierwszy pakiet ClientHello pozostaje podatny. W nim przekazywana jest wersja TLS, lista szyfrów i domena w formie jawnej. Implementacje w Go (w tym Xray i sing-box) mają charakterystyczny dla języka wzorzec ClientHello, co pozwala je identyfikować nawet przy użyciu uTLS. Biblioteka uTLS imituje zachowanie przeglądarki tylko na poziomie pierwszego pakietu, ale nie odtwarza niuansów stosu sieciowego: rytm transmisji danych, długości ramek, specyfiki HTTP/2. NaiveProxy rozwiązuje ten problem radykalnie — poprzez integrację fragmentu Chromium, zapewniającą pełne dopasowanie do ruchu przeglądarki.

Architektura NaiveProxy: od Chromium do proxy

Autor protokołu klzgrad zmodyfikował kod źródłowy Chromium, zachowując zaledwie 0,3% funkcjonalności niezbędnej do interakcji sieciowej. Kluczowe cechy:

• Wykorzystanie oryginalnego stosu HTTP/2 Chromium do multipleksowania
• Pełna identyczność ClientHello i kolejnych pakietów z ruchem przeglądarki
• Rezygnacja z niestandardowych szyfrów na rzecz mechanizmów TLS

Ważne: kompatybilność ze standardowymi proxy HTTP/2 działa w obie strony. Klienci NaiveProxy współpracują z dowolnymi proxy HTTP/2, a serwery NaiveProxy akceptują połączenia od standardowych klientów. Pełne maskowanie osiąga się jednak tylko przy użyciu stosu sieciowego Chromium — jak w implementacji sing-box. Inne klienty (np. oparte na Go) mogą być kompatybilne z serwerem NaiveProxy, ale nie zapewniają pełnej anonimizacji.

Padding: trzy poziomy ochrony przed analizą ruchu

Protokół wprowadza wielopoziomowy padding, by utrudnić analizę po długości pakietów:

• Ramki DATA: W pierwszych 8 ramkach każdego strumienia dodawany jest nagłówek (2 bajty długości danych + 1 bajt długości paddingu), po którym następują oryginalne dane i bajty paddingu.
• Zapytania CONNECT: Losowe nagłówki o dowolnej długości zwiększają rozmiar ramek.
• END_STREAM: Dodatkowe ramki przed każdym RST_STREAM.

Podczas testów odkryto krytyczną wadę w implementacji sing-box: zamiast zerowania bufora przy dodawaniu paddingu wysyłane były resztkowe dane z poprzednich zapytań. Prowadziło to do wycieku poufnych informacji (np. nazw domen i nagłówków). Problem usunięto w wersjach 1.13.1+ po przyjęciu dwóch PR, dodających wymuszone zerowanie buforów.

Konfiguracja klienta: outbound sing-box

Wymagany sing-box 1.13+. Konfiguracja klienta:

{
  "type": "naive",
  "tag": "Proxy1",
  "server": "1.2.3.4",
  "server_port": 443,
  "username": "username",
  "password": "password",
  "insecure_concurrency": 1,
  "udp_over_tcp": {
    "enabled": true
  },
  "quic": false,
  "tls": {
    "enabled": true,
    "server_name": "s1.example.com"
  }
}

Kluczowe parametry:

• insecure_concurrency: Zalecana wartość 1. Zwiększenie liczby połączeń ułatwia analizę ruchu.
• udp_over_tcp: Konieczne włączenie dla obsługi ruchu UDP.
• server_name: Domena skonfigurowana w Caddy. Musi zgadzać się z server_name w sekcji TLS.

Caddy jako terminator TLS: konfiguracja i fallback

Caddy obsługuje połączenia TLS i dzieli ruch na proxy oraz stronę zastępczą. Konfiguracja (/etc/caddy/Caddyfile):

{
    email [email protected]
    auto_https disable_redirects
}

:443, https://s1.example.com {
    tls {
        issuer acme {
            disable_http_challenge
        }
    }

    route {
        @naive {
            method CONNECT
            header Proxy-Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
        }

        handle @naive {
            reverse_proxy h2c://127.0.0.1:1080 {
                header_up Proxy-Authorization {header.Proxy-Authorization}
            }
        }

        handle {
            root * /srv/naive-fallback
            file_server
        }
    }
}

Cechy:

• Nagłówek Proxy-Authorization zawiera kodowanie base64 username:password (generowane przez echo -n "username:password" | base64).
• Katalog /srv/naive-fallback zawiera statyczną stronę zastępczą chroniącą przed skanowaniem.
• Parametr auto_https disable_redirects wyłącza przekierowanie HTTP→HTTPS, ponieważ port 443 obsługuje tylko HTTPS.

Serwer: inbound sing-box i integracja z Caddy

Konfiguracja serwera sing-box (/etc/sing-box/config.json):

{
  "log": {
    "level": "warn",
    "output": "/var/log/sing-box/sing-box.log"
  },
  "inbounds": [
    {
      "type": "naive",
      "tag": "naive-in",
      "network": "tcp",
      "listen": "127.0.0.1",
      "listen_port": 1080,
      "users": [
        {
          "username": "username",
          "password": "password"
        }
      ]
    }
  ],
  "outbounds": [
    {
      "type": "direct"
    }
  ]
}

Ważne:

• Serwer nasłuchuje tylko localhost:1080, ponieważ połączenia zewnętrzne obsługuje Caddy.
• Poziom logowania warn minimalizuje obciążenie dysku.
• Hasła muszą dokładnie zgadzać się z ustawieniami Caddy i klienta.

Co ważne

• Pełne maskowanie wymaga stosu Chromium: Tylko implementacje oparte na oryginalnym kodzie sieciowym (jak w sing-box) zapewniają pełne dopasowanie do ruchu przeglądarki.
• Konkurencyjność = ryzyko: Parametr insecure_concurrency powyżej 1 zwiększa podatność na analizę ruchu po długości pakietów.
• Aktualizuj komponenty: Używaj sing-box 1.13.1+ dla usunięcia wycieku danych przez padding.
• Strona zastępcza obowiązkowa: Statyczna strona w Caddy zapobiega wykryciu proxy podczas skanowania.
• Reality nie jest cudownym lekiem: Jak pokazała historia z Reality, nawet przemyślane rozwiązania mogą być blokowane po nowych cechach (np. po liczbie połączeń).

— Editorial Team