Dropping a few more words with regard to alternatives: ``` # Alternatives
## Prefix-based SNI with entropy Potentially, one could also introduce additional entropy by letting clients send a SNI of the format `<FINGERPRINT><RANDOM>.home.arpa`, with `<RANDOM>` being a random length suffix of hexadecimal characters. The advantage this offers is to introduce slightly more obfuscation by making it harder to detect the likelihood of Tor traffic by the based on the TLS handshake alone, though it will of course not protect against and a person really interested in whether you are using Tor or not. Besides, it requires the reverse proxy to support regex/prefix based SNI matching, which certain reverse proxies may not support, for a good reason. ## Traditional NAT One may also configure the IPv4 frontend server to simply not do any Tor TLS forwarding based on the SNI and just designate a dedicated port from which traditional NAT/PAT with some IPv4/IPv6 glue will be performed. Advantages of this include, that it does need any change in the current implementation. Disadvantages include, that it would require larger complexity for the frontend server, which is usually designed to be low-complexity. On Linux for example, it would involve enabling routing logic through various sysctl's. Not only does this increase the attack surface because more complex kernel code is loaded during runtime, but it also greatly increases the complexity of firewall rules, as NAT is more advanced than traditional input/output based allow/blocklists. ``` _______________________________________________ tor-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
