[tor-bugs] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Feb 2 09:08:11 UTC 2019
#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
More information about the tor-bugs
mailing list