Add Support for Custom SNI and Address Fields for Subscription Addition

[ytpk]

Description:

Hello,

I would like to request the addition of "SNI" (Server Name Indication) and "Address" fields to the subscription addition interface, alongside the existing profile link and remark fields. This enhancement aims to assist users in heavily censored regions, such as Turkmenistan, to access the internet freely by utilizing domain fronting techniques.

Background:

In Turkmenistan, internet censorship blocks access to certain server names and DNS resolutions, making it difficult for users to retrieve subscription profiles and bypass filters. By allowing users to specify custom SNI and address fields, we can leverage domain fronting to mask requests through non-banned services like Google or Fastly.

For example, if a subscription is uploaded to Google Drive (drive.google.com), it might be blocked by server name. However, Google supports domain fronting, allowing us to access the content using a different server name. Here's an example of how this can be achieved using curl:

curl -H "Host: drive.google.com" \
     --resolve "google.com:443:[Google IP]" \
     --insecure -v https://google.com/uc?export=download&id=blahblahblah

In this example:

• We connect to google.com but specify drive.google.com in the Host header.
• We use a resolved IP address, possibly obtained from google.tm, which is not blocked and can be retrieved via DHCP DNS.

Proposal:

• Add "SNI" Field: Allows users to specify the server name sent during the TLS handshake.
• Add "Address" Field: Enables users to define an alternative IP address or domain to connect to when fetching subscriptions.

Benefits:

• Bypass Censorship: Helps users in censored regions access the internet and retrieve subscription profiles despite DNS and server name blocks.

• Support for Thousands of Users: This feature could assist thousands, if not hundreds of thousands, of users facing strict internet censorship.

• Security Concerns: While there might be concerns regarding insecure connections or SNI fronting, these methods are crucial in regions with limited alternatives.

• DNS Blocks: Since DNS resolution is also blocked, techniques like TLS fragmentation without SNI substitution are ineffective.

• Alternative Solution: If implementing SNI substitution isn't feasible, consider adding TLS fragmentation with the option to force the use of an IP address from another domain as the address.

Conclusion:

Understanding the potential reservations about implementing such features, I believe this enhancement is vital for users in regions with heavy internet censorship. It provides a practical solution to bypass filters and access essential online resources.

Thank you for considering this request. Your support can make a significant difference for users in need.

[GooRingX]

1. Regarding [Add "SNI" Field], you can currently ask your VPN service provider to modify it, or you can manually edit the node in karing to implement it.
2. Regarding [Add "Address" Field], you can implement custom domain name resolution in dns-Static IP

[ytpk]

2. Regarding [Add "Address" Field], you can implement custom domain name resolution in dns-Static IP

While it's possible to implement custom domain name resolution using DNS and static IPs, relying solely on IP addresses presents significant challenges in Turkmenistan:

Cyclical IP Blocking: IP addresses are banned cyclically in Turkmenistan, leading to instability. Even large providers like Google have subnets that may not remain consistently accessible over time.

Domain vs. IP Address: Allowing the use of a domain name as the address, rather than just a static IP, would provide a more resilient solution. Domains are less likely to be blocked en masse compared to IP ranges, and they can offer more stable connectivity.

Mitigating DNS and SNI Blocking: By using domain fronting and techniques like TLS ClientHello fragmentation, we can circumvent DNS interception and SNI-based blocking. These methods have proven effective even in heavily censored environments, such as China, and can offer a more sustainable solution.

1. Regarding [Add "SNI" Field], you can currently ask your VPN service provider to modify it, or you can manually edit the node in karing to implement it.

Persistent Access: Domain fronting allows users to continue accessing services even if certain domains are blocked, provided the hosting supports fronting. This method reduces the need for frequent domain changes, which can be cumbersome and may not always be feasible for all users.

Hosting Support: When the hosting provider supports domain fronting, it enables users to mask their requests through non-banned domains without altering the base URL. This is particularly important in regions like Turkmenistan, where domains are often blocked unpredictably.

The cat-and-mouse game with a totalitarian country shouldn't reach the point of absurdity—constantly buying new domains or blocking hosting services that enable operations in totalitarian countries. For example, GitHub is currently blocked in our country, and Cloudflare is under the proxy of the GFW, preventing the use of even functional domains. Based on this, can solve the problem fundamentally by adding the ability to fragment the TLS ClientHello, specify a dynamic domain as the address, and change the SNI in the subscription link.

thank you in advance for taking even more time to my messages and not closing the topic from the end user, I still hope that you will consider adding something like this

drive.google.com
the domain given earlier is not available for fronting, but it is specified for an example
if I need to provide something for testing, I can do it in private messages, I do not trust public places, at least until it becomes possible to hide sni