Proposal: Extending TLS settings with the newely discovered method of SNI Spoofing

There has been a new method discovered that can greatly help circumvent certain access-whitelisted environments, like current Iran's internet state. In Iran, currently few destinations are whitelisted, many of which are hosted behind cloudflare's CDN. So, some whitelisted IPs of cloudflare network can be accessed as long as the SNI used to connect to it is also whitelisted. The trick used to exploit this controlled conduit, is to send a completely valid client hello packet right after the tcp handshake, but with a certain important detail: the TCP header is modified so that a proper network stack would drop it, the change could be a very short TTL, or an invalid checksum, or a wrong sequence etc. The packet reaches the firewall, firewall whitelists the connection since the SNI is whitelisted, but the packet gets dropped by cloudflare's network as the TCP state is not valid. The connection is then used normally, TLS handshake to one's own domain is made, and then it can be used to tunnel traffic through websocket or httpUpgrade.
While some of the changes made to the TCP packet can easily be detected and blocked, i believe such a method can be promising due to the vast ways of manipulating the TCP header so that it makes it much more expensive for the firewall to block these methods. I also suspect that not all sequence manipulations can be easily detected at the firewall level since an invalid seq might simply indicate a dropped packet. I am willing to implement this and open a PR if you are interested in having this method added to sing-box.

Start by reviewing the existing TLS settings and the connection paths for client hello handling, WebSocket, and HTTP upgrade support. The issue does not name files or tests; first determine where TCP-header manipulation and SNI selection would belong, then confirm the intended behavior and test coverage with maintainers before implementation.