Configuration de NaiveProxy dans sing-box : une alternative sécurisée à VLESS

NaiveProxy : Une alternative sécurisée à VLESS basée sur Chromium

Face aux efforts agressifs de blocage, le protocole NaiveProxy propose une approche unique de camouflage du trafic — en exploitant la pile réseau originale de Chromium. Nous allons parcourir la configuration du client et du serveur avec sing-box et Caddy, en évitant les pièges courants.

Bases du camouflage de trafic : Pourquoi NaiveProxy surpasse uTLS ?

Les protocoles proxy standards se déguisent en trafic HTTPS, mais le paquet ClientHello initial reste vulnérable. Il envoie la version TLS, la liste des chiffrements et le domaine en clair. Les implémentations basées sur Go (y compris Xray et sing-box) présentent une empreinte ClientHello caractéristique unique au langage, les rendant identifiables même avec uTLS. La bibliothèque uTLS ne mime le comportement des navigateurs que dans ce premier paquet, sans reproduire les subtilités de la pile réseau comme le rythme de transmission des données, les longueurs de trames et les particularités HTTP/2. NaiveProxy s'attaque directement à ce problème en intégrant un fragment de Chromium qui offre une émulation parfaite du trafic de navigateur.

Architecture de NaiveProxy : De Chromium au proxy

Le créateur du protocole, klzgrad, a réduit le code source de Chromium à seulement 0,3 % de ses fonctionnalités, en ne conservant que ce qui est nécessaire pour le réseau. Fonctionnalités clés :

• Utilise la pile HTTP/2 native de Chromium pour le multiplexage
• Correspondance parfaite du ClientHello et des paquets suivants avec le trafic réel d'un navigateur
• Abandonne les chiffrements personnalisés au profit des mécanismes TLS standards

Important : Il est entièrement compatible avec les proxies HTTP/2 standards dans les deux sens. Les clients Naive fonctionnent avec n'importe quel proxy HTTP/2, et les serveurs Naive acceptent les connexions de clients standards. Mais le vrai camouflage n'intervient qu'avec la pile réseau de Chromium — comme dans sing-box. D'autres clients (par ex. ceux basés sur Go) peuvent se connecter à un serveur Naive mais ne fourniront pas une anonymat complet.

Remplissage : Trois couches de protection contre l'analyse de trafic

Le protocole utilise un remplissage multi-niveaux pour contrer l'analyse de la longueur des paquets :

• Trames DATA : Les 8 premières trames de chaque flux ajoutent un en-tête (2 octets pour la longueur des données + 1 octet pour la longueur du remplissage), suivi des données originales et des octets de remplissage.
• Requêtes CONNECT : Des en-têtes de longueur aléatoire gonflent arbitrairement la taille des trames.
• END_STREAM : Des trames supplémentaires avant chaque RST_STREAM.

Des tests ont révélé un défaut critique dans sing-box : Au lieu de vider le tampon lors de l'ajout du remplissage, il envoyait les données résiduelles des requêtes précédentes. Cela fuitait des infos sensibles (comme les noms de domaine et les en-têtes). Corrigé dans les versions 1.13.1+ après fusion de deux PR qui forcent le vidage du tampon.

Configuration client : Sortie sing-box

Nécessite sing-box 1.13+. Configuration client :

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

Paramètres clés :

• insecure_concurrency : Restez à 1. Des valeurs plus élevées rendent le trafic plus facile à analyser.
• udp_over_tcp : Activez pour le support UDP.
• server_name : Domaine configuré dans Caddy. Doit correspondre au server_name de la section TLS.

Caddy comme terminateur TLS : Configuration et solution de repli

Caddy gère les connexions TLS et route le trafic vers le proxy ou un leurre. Configuration (/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
        }
    }
}

Points clés :

• L'en-tête Proxy-Authorization contient username:password encodé en base64 (générez avec echo -n "username:password" | base64).
• Le répertoire /srv/naive-fallback sert un site statique de leurre pour repousser les scans.
• auto_https disable_redirects évite les redirections HTTP→HTTPS car le port 443 est exclusivement HTTPS.

Côté serveur : Entrée sing-box et intégration Caddy

Configuration sing-box serveur (/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"
    }
  ]
}

Important :

• Le serveur écoute uniquement sur localhost:1080, car Caddy gère les connexions externes.
• Niveau de journal warn pour minimiser les E/S disque.
• Les mots de passe doivent correspondre exactement à ceux du client et de Caddy.

Points clés

• Camouflage complet nécessite la pile Chromium : Seules les implémentations utilisant le code réseau original (comme sing-box) correspondent parfaitement au trafic navigateur.
• Concurrence = risque : insecure_concurrency supérieur à 1 augmente la vulnérabilité à l'analyse de longueur de paquets.
• Maintenez les composants à jour : Utilisez sing-box 1.13.1+ pour corriger les fuites de données de remplissage.
• Site de leurre indispensable : Site statique dans Caddy cache le proxy des scans.
• La réalité n'est pas infaillible : Comme l'histoire de Reality le montre, même les solutions ingénieuses peuvent être bloquées par de nouvelles empreintes (par ex. nombre de connexions).

— Editorial Team