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!
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_spoofThis 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:
mitm_proxy.sni_spoof.Thank you for considering this suggestion!