NaiveProxy in sing-box konfigurieren: eine sichere Alternative zu VLESS

# NaiveProxy: Eine sichere Alternative zu VLESS basierend auf Chromium

Angesichts aggressiver Blockadeversuche bietet das NaiveProxy-Protokoll einen einzigartigen Ansatz zur Tarnung des Traffics – unter Nutzung des originalen Netzwerkstacks von Chromium. Wir führen Sie durch die Einrichtung von Client und Server mit sing-box und Caddy und umgehen gängige Fallstricke.

Grundlagen der Traffic-Tarnung: Warum NaiveProxy uTLS übertrumpft?

Standard-Proxy-Protokolle tarnen sich als HTTPS-Traffic, doch das anfängliche ClientHello-Paket bleibt angreifbar. Es sendet die TLS-Version, die Cipher-Liste und den Domain-Namen im Klartext. Go-basierte Implementierungen (einschließlich Xray und sing-box) weisen einen charakteristischen ClientHello-Fingerprint auf, der der Programmiersprache zu eigen ist und sie auch mit uTLS identifizierbar macht. Die uTLS-Bibliothek ahmt das Browser-Verhalten nur in diesem ersten Paket nach und versagt bei der Nachbildung feiner Netzwerkstack-Nuancen wie dem Datenübertragungsrhythmus, Framelängen und HTTP/2-Idiosynkrasien. NaiveProxy geht diesem Problem direkt an, indem es ein Chromium-Fragment einbettet, das eine pixelgenaue Emulation des Browser-Traffics liefert.

NaiveProxy-Architektur: Vom Chromium zum Proxy

Der Protokoll-Erfinder klzgrad hat den Quellcode von Chromium auf nur 0,3 % seiner Funktionalität reduziert und nur das Nötige für die Netzwerkkommunikation behalten. Wichtige Merkmale:

• Nutzt den nativen HTTP/2-Stack von Chromium für Multiplexing
• Perfekte Übereinstimmung von ClientHello und nachfolgenden Paketen mit echtem Browser-Traffic
• Verzichtet auf eigene Chiffren zugunsten standardisierter TLS-Mechanismen

Wichtig: Es ist vollständig kompatibel mit standardmäßigen HTTP/2-Proxys in beide Richtungen. Naive-Clients funktionieren mit jedem HTTP/2-Proxy, und Naive-Server akzeptieren Verbindungen von Standard-Clients. Die echte Tarnung entsteht jedoch nur mit dem Chromium-Netzwerkstack – wie in sing-box. Andere Clients (z. B. Go-basierte) können sich zwar mit einem Naive-Server verbinden, bieten aber keine volle Anonymität.

Padding: Drei Schutzschichten gegen Traffic-Analyse

Das Protokoll setzt mehrstufiges Padding ein, um Längenanalysen von Paketen zu erschweren:

• DATA-Frames: Die ersten 8 Frames jedes Streams ergänzen einen Header (2 Bytes für Datenlänge + 1 Byte für Padding-Länge), gefolgt von Originaldaten und Padding-Bytes.
• CONNECT-Anfragen: Header mit zufälliger Länge blähen Framelängen beliebig auf.
• END_STREAM: Zusätzliche Frames vor jedem RST_STREAM.

Tests deckten einen kritischen Fehler in sing-box auf: Statt den Buffer beim Hinzufügen von Padding zu löschen, wurden Daten aus vorherigen Anfragen mitgesendet. Dadurch sickerten sensible Infos (wie Domain-Namen und Header) durch. Behoben in Versionen 1.13.1+ nach dem Zusammenführen zweier PRs, die ein erzwungenes Buffer-Löschen durchsetzen.

Client-Einrichtung: sing-box Outbound

Erfordert sing-box 1.13+. Client-Konfiguration:

{
  "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"
  }
}

Wichtige Parameter:

• insecure_concurrency: Auf 1 belassen. Höhere Werte erleichtern die Traffic-Analyse.
• udp_over_tcp: Für UDP-Unterstützung aktivieren.
• server_name: Domain, die in Caddy eingerichtet ist. Muss mit dem server_name im TLS-Block übereinstimmen.

Caddy als TLS-Terminator: Konfiguration und Fallback

Caddy übernimmt TLS-Verbindungen und leitet Traffic an den Proxy oder eine Attrappe weiter. Konfiguration (/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
        }
    }
}

Wichtige Punkte:

• Der Proxy-Authorization-Header enthält base64-kodiert username:password (erzeugen mit echo -n "username:password" | base64).
• Das Verzeichnis /srv/naive-fallback serviert eine statische Attrappenseite, um Scans abzuwehren.
• auto_https disable_redirects überspringt HTTP→HTTPS-Weiterleitungen, da Port 443 rein HTTPS ist.

Server-Seite: sing-box Inbound und Caddy-Integration

Server-sing-box-Konfiguration (/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"
    }
  ]
}

Wichtig:

• Der Server lauscht nur auf localhost:1080, da Caddy externe Verbindungen handhabt.
• warn-Log-Level minimiert Festplatten-I/O.
• Passwörter müssen exakt mit Client- und Caddy-Einstellungen übereinstimmen.

Wichtige Erkenntnisse

• Vollständige Tarnung erfordert Chromium-Stack: Nur Implementierungen mit dem originalen Netzwerkcode (wie sing-box) passen perfekt zum Browser-Traffic.
• Concurrency = Risiko: insecure_concurrency über 1 erhöht die Angreifbarkeit durch Längenanalysen.
• Komponenten aktuell halten: sing-box 1.13.1+ behebt Padding-Datenlecks.
• Attrappenseite unverzichtbar: Statische Seite in Caddy tarnt den Proxy vor Scans.
• Nichts ist narrensicher: Wie die Geschichte von Reality zeigt, können selbst clevere Lösungen durch neue Fingerprints (z. B. Verbindungsanzahlen) blockiert werden.

— Editorial Team