#29077: uTLS for meek-client camouflage ------------------------------+------------------------------ Reporter: dcf | Owner: dcf Type: enhancement | Status: needs_review Priority: Medium | Milestone: Component: Obfuscation/meek | Version: Severity: Normal | Resolution: Keywords: moat utls | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: ------------------------------+------------------------------
Comment (by dcf): * https://gitweb.torproject.org/pluggable- transports/meek.git/log/?h=utls_2&id=e4bc7b1c3aae41252f64b3affc8c08e525831e08 * https://gitweb.torproject.org/pluggable- transports/meek.git/diff/?h=utls_2&id=e4bc7b1c3aae41252f64b3affc8c08e525831e08&id2=cb2d7d1a6f0c8ada45d22f49ed0524bbc689b1b1 Here's a merge candidate for the utls_2 branch. Changes since comment:12: * Support for socks5, http, and https proxies. (The same proxy types net/http supports.) * `utls=none` and `utls=HelloGolang` mean "no uTLS". * Copying default `http.Transport` timeouts and other settings. * Rudimentary integration tests for the http and https proxies. Replying to [comment:13 yawning]: > Note that I treat not specifying the argument as "use a sensible default", and have `none` special cased as "use the built in TLS stack", under the rationale that once the code is solid the only reason to not use utls is if something breaks, and "Add `utls=none`" is a easier interim workaround to convey to the unwashed masses than "Edit an existing argument". This sounds like a good design. I think for at least the next release I'll leave no `utls` meaning native TLS, and then a future release can compatibly upgrade it to mean some sensible uTLS configuration by default. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29077#comment:15> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs