If you have the technical knowledge, you can just read the protocols, find out if they make sense, and then implement them yourself. Most of them are quite straight forward so it's not possible to hide a backdoor like Dual_EC_DRBG in the protocol.
If you are not so technical then you have to decide who to trust. For example, you may trust that open source software has been vetted enough and build one from source. Or trust that the built artefacts downloaded from github is good enough. Or trust that the software downloaded from a website not marked as fraud by Google Chrome is good enough. Etc.
In any case, the more technical knowledge you have, the more confidence you can have by doing due diligence yourself.
WebRTC is not blocked. I do see some protocols trying to masquerade as WebRTC, but for some reason it is not popular.
A primitive way to bypass the censor is just to connect to your VPS with RDP or Chrome Remote Desktop (which is WebRTC underlying) and then browse the Internet there. But it needs a very powerful server and is quite slow.
Let's say the upstream server is apple.com. The TLS handshake is always performed by the real apple.com servers, and the ShadowTLS server is only a middle man forwarding raw TCP contents.
If both sides are ShadowTLS (client & server) holding the same key, they will stealthily switch to a different encryption protocol after the handshake, disregarding the TLS key exchange. The TLS handshake is a facade to fool the deep packet inspection of the censor.
In all other cases, such as the censor actively probing the ShadowTLS server, the server will keep forwarding the encrypted traffic to apple.com without anyway to decrypt it (it's not a MitM proxy). To the active prober, it is just apple.com all the way.
No, it’s illegal to bring starlink devices here, and I heard that Elon Musk chooses to block China from accessing starlink too, to appease the Chinese authorities.
If you need to bypass censorship, you'll need a tool specifically designed for anti-censorship, rather than any one repurposed for that.
Since China has the most advanced network censorship, the Chinese have also invented the most advanced anti-censorship tools.
The first generation is shadowsocks. It basically encrypts the traffic from the beginning without any handshakes, so DPI cannot find out its nature. This is very simple and fast and should suffice in most places.
The second generation is the Trojan protocol. The lack of a handshake in shadowsocks is also a distinguishing feature that may alert the censor and the censor can decide to block shadowsocks traffic based on suspicions alone. Trojan instead tries to blend in the vast amount of HTTPS traffic over the Internet by pretending to be a normal Web server protected by HTTPS.
After Trojan, a plethora of protocol based on TLS camouflaging have been invented.
1. Add padding to avoid the TLS-in-TLS traffic characteristics in the original Trojan protocol. Protocols: XTLS-VLESS-VISION.
2. Use QUIC instead of TCP+TLS for better performance (very visible if your latency to your tunnel server is high). Protocols: Hysteria2 and TUIC.
3. Multiplex multiple proxy sessions in one TCP connection. Protocols: h2mux, smux, yamux.
4. Steal other websites' certificates. Protocols: ShadowTLS, ShadowQUIC, XTLS-REALITY.
Oh, and there is masking UDP traffic as ICMP traffic or TCP traffic to bypass ISP's QoS if you are proxying traffic through QUIC. Example: phantun.
Others have mentioned protocol ossification which is indeed the primary reason. A secondary reason is that QUIC fuses TLS so its latency is further reduced by one RTT. For high latency networks, the difference is palpable.