[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10671 [Pluggable transport]: Pluggable Transports: Improve method of transferring parameters to client-side transports
#10671: Pluggable Transports: Improve method of transferring parameters to client-
side transports
-------------------------------------+--------------------
Reporter: asn | Owner: asn
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Resolution: | Keywords:
Actual Points: | Parent ID: #10629
Points: |
-------------------------------------+--------------------
Comment (by yawning):
Replying to [comment:3 dcf]:
> e) We make `socks4a` one of the possible `CMETHOD` SOCKS types (along
with the existing `socks4` and `socks5`), and pass IPv6 addresses as if
they were host names. Benefits: works with IPv6 (like `socks5`) and has
unlimited credentials length (like `socks4`). Another benefit: would allow
Tor to pass host names to pluggable transports (currently it always pre-
resolves names that you put in a `Bridge` line).
As long as Tor ignores the DSTIP field in the PT->Tor socks response, then
this would work. I don't see Tor needing the remote IP for anything, but
I haven't given it massive amounts of thought (Maybe if we allow name
resolution it could do something with it?).
Personally I'm in favor of "a" since it will:
* Support binary data
* Be backwards compatible (The only failure case is PTs that require
extended config with an old Tor, but ALL currently deployed Tor binaries
can't use such PTs regardless of auth method anyway)
* Still allow password protecting the SOCKS endpoint (though only for
clients that support the extension auth method, so new PT + old Tor = no
passwords for you)
Something like:
{{{
METHOD - 0x80 (Reserved range is 0x80-0xFE)
Fields common to RFC 1929 have the same values/definitions.
+-----+------+----------+------+----------+--------+------------+
| VER | ULEN | UNAME | PLEN | PASSWD | EXTLEN | EXTDATA |
+-----+------+----------+------+----------+--------+------------+
| 1 | 1 | 1 to 255 | 1 | 1 to 255 | 2 | 0 to 65535 |
+-----+------+----------+------+----------+--------+------------+
VER: 0x01 (Also in RFC 1929, but this is our auth method version)
EXTLEN: Length of EXTDATA in network byte order (64k is enough for
anybody?)
EXTDATA: PT specific per-endpoint configuration data
}}}
Possible changes:
* Change EXTLEN/EXTDATA to Key/Value pairs (NR_EXTDATA, KLEN, KEY, VLEN,
VAL, ...)
* If it is conceivable that PTs will use more that 64k of per bridge
config information, then EXTLEN could be 4 bytes. I would hate to see the
bridgeline for such a transport though.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10671#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs