Skip to content

Feature Request: Proposal for New Outbound Types, sni_spoof and mitm_proxy #4109

@yusefpasha

Description

@yusefpasha

Hello Sing-Box Team,

I have a proposal to enhance Sing-box’s obfuscation capabilities by adding support for SNI Spoofing and MITM Domain Fronting. I am not sure how feasible this is within the current architecture, but I believe these features would greatly benefit users dealing with heavy DPI (Deep Packet Inspection).

Below are my suggestions for two new outbound types. If implemented, they would allow users to leverage existing routing rules and load-balancing logic seamlessly.

1. Outbound Type: sni_spoof

This type is designed for scenarios where the destination IP/Domain is fixed, but the TLS SNI field needs to be spoofed to bypass domain-based blocking or certificate mismatches. It requires minimal configuration as it doesn't need a complex middleman server logic, just a direct connection with an overridden SNI.

Proposed Config:

{
  "type": "sni_spoof",
  "tag": "my-sni-spoof-proxy",
  "server": "target-ip-address.com",      // Real Server IP/Domain
  "server_port": 443,
  "tls": {
    "enabled": true,
    "insecure": false
  },
  "sni_spoofing": {
    "fake_sni": "cdn.cloudflare.com"     // The SNI to inject in ClientHello
  }
}

2. Outbound Type: mitm_proxy (Domain Fronting)

This type supports proxies that perform MITM, such as those based on Google Apps Script (script.google.com) or custom Rust/Go relays. It handles the handshake with the front domain while forwarding traffic to the back-end destination using specific parameters like keys and deploy IDs common in serverless fronting services.

Proposed Config:

{
  "type": "mitm_proxy",
  "tag": "my-mitm-fronter",
  "server": "script.google.com",          // The Front Domain (Whitelisted)
  "server_port": 443,
  "tls": {
    "enabled": true,
    "server_name": "script.google.com"   // SNI matches the front domain
  },
  "mitm_config": {
    "method": "google_apps_script",       // e.g., 'custom', 'google_apps_script'
    "auth_key": "your_api_auth_key",      // Required for some services
    "deploy_id": "your_deploy_id",        // Required for serverless fronting
    "host_header": "real-destination.com" // The real Host/SNI to forward
  }
}

I’ve referenced projects that implement similar logic:

Thank you for considering this suggestion!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions